You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Emilian Bold <em...@apache.org> on 2017/04/19 06:53:08 UTC
Drag and drop install on macOS instead of the current installer package
Hello,
On macOS NetBeans is distributed as a wizard-like installer instead of
the more simple drag and drop image.
See for example how Firefox for Mac is installed
https://support.mozilla.org/t5/Install-and-Update/How-to-download-and-install-Firefox-on-Mac/ta-p/3453
What I like about the drag and drop approach is that you can install
the app anywhere as a normal user.
The only reference I could find about the reasoning is this wiki page
http://wiki.netbeans.org/NB6MacInstallers which mentions pack200 and
perhaps app server bundling(?).
Disk images may be compressed with zlib (UDZO format) or bzip2 (UDBZ
format) and HTTP itself has compression so I suspect bandwidth will
not be such an issue.
Also, only the NetBeans Java EE bundle has Glassfish/Tomcat
(https://netbeans.org/downloads/ ) while the rest will run as-is using
the Java on the PATH.
I suggest future Apache NetBeans builds for macOS be distributed as
plain drag and drop disk images.
PS: This is also relevant since right now it's not possible to build
the NetBeans installers outside the Oracle infra.
--emi
Re: Drag and drop install on macOS instead of the current installer package
Posted by Emilian Bold <em...@gmail.com>.
> You can't buddle Java because of License issues. We have had the same with Apache OpenOffice
Was this about the Oracle JRE or OpenJDK?
--emi
On Wed, Apr 19, 2017 at 2:23 PM, Raphael Bircher
<rb...@gmail.com> wrote:
> Hi all
>
> You can't buddle Java because of License issues. We have had the same with
> Apache OpenOffice
>
> Regards Raphael
>
>
> Am .04.2017, 12:39 Uhr, schrieb Emilian Bold <em...@gmail.com>:
>
>> Well the point was you don't really need to search for Java.
>>
>> Either we assume the user has it or we bundle a JRE.
>>
>> --emi
>>
>> Pe 19 apr. 2017, la 13:17, Neil C Smith <ne...@googlemail.com> a
>> scris:
>>
>>> Hi Emi,
>>>
>>>> On Wed, 19 Apr 2017 at 07:53 Emilian Bold <em...@apache.org> wrote:
>>>>
>>>> ... while the rest will run as-is using
>>>> the Java on the PATH.
>>>>
>>>
>>> Interesting topic! I think I mostly agree with you. While slightly
>>> different IIRC, it would be good to consider the needs of RCP
>>> applications
>>> here too. I experimented with building an OSX installer for Praxis LIVE
>>> at
>>> the last release, but the RCP installer build seems to have broken
>>> relative
>>> resource references.
>>>
>>> More relevantly, one thing I've noticed shipping as an .app is the
>>> problem
>>> if Java isn't on the path. The launcher just fails silently - few user
>>> bug
>>> reports there! If the IDE were to be shipped as an .app would it have
>>> the
>>> same issue? I assume the current installer handles this situation
>>> better?
>>> Aren't .app bundles generally intended to be self-contained, in which
>>> case
>>> should we consider shipping with JDK, and not relying on Java in the
>>> path?
>>>
>>> 2c,
>>>
>>> Best wishes,
>>>
>>> Neil
>>> --
>>> Neil C Smith
>>> Artist & Technologist
>>> www.neilcsmith.net
>>>
>>> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>
>
>
> --
> My introduction https://youtu.be/Ln4vly5sxYU
Re: Drag and drop install on macOS instead of the current installer
package
Posted by Raphael Bircher <rb...@gmail.com>.
Hi all
You can't buddle Java because of License issues. We have had the same with
Apache OpenOffice
Regards Raphael
Am .04.2017, 12:39 Uhr, schrieb Emilian Bold <em...@gmail.com>:
> Well the point was you don't really need to search for Java.
>
> Either we assume the user has it or we bundle a JRE.
>
> --emi
>
> Pe 19 apr. 2017, la 13:17, Neil C Smith <ne...@googlemail.com>
> a scris:
>
>> Hi Emi,
>>
>>> On Wed, 19 Apr 2017 at 07:53 Emilian Bold <em...@apache.org> wrote:
>>>
>>> ... while the rest will run as-is using
>>> the Java on the PATH.
>>>
>>
>> Interesting topic! I think I mostly agree with you. While slightly
>> different IIRC, it would be good to consider the needs of RCP
>> applications
>> here too. I experimented with building an OSX installer for Praxis
>> LIVE at
>> the last release, but the RCP installer build seems to have broken
>> relative
>> resource references.
>>
>> More relevantly, one thing I've noticed shipping as an .app is the
>> problem
>> if Java isn't on the path. The launcher just fails silently - few user
>> bug
>> reports there! If the IDE were to be shipped as an .app would it have
>> the
>> same issue? I assume the current installer handles this situation
>> better?
>> Aren't .app bundles generally intended to be self-contained, in which
>> case
>> should we consider shipping with JDK, and not relying on Java in the
>> path?
>>
>> 2c,
>>
>> Best wishes,
>>
>> Neil
>> --
>> Neil C Smith
>> Artist & Technologist
>> www.neilcsmith.net
>>
>> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
--
My introduction https://youtu.be/Ln4vly5sxYU
Re: Drag and drop install on macOS instead of the current installer package
Posted by Emilian Bold <em...@gmail.com>.
> Apologies if I side-tracked the discussion.
You provided valuable info for people not deploying on macOS.
> I wish my company had that kind of dough. :-)
A second hand Mac is $150 or less. Renting a Mac Mini for a build slave is
$59 / month or less.
It might be hard for an individual but a company should not be having
issues getting a Mac to build a product for their users / customers.
--emi
On Fri, Apr 21, 2017 at 8:02 PM, Peter Hansson <
peterhansson_se@yahoo.com.invalid> wrote:
>
> >> I don't see a huge problem in using native OS build slaves to get a
> >> particular installer.
>
> I wish my company had that kind of dough. :-)
>
> >> I don't believe there is a crossplatform way to sign
> >> Windows EXEs or change Windows EXE icons, etc.
> Wouldn't know about signing. I would think so.Changing resources inside an
> EXE (e.g. icons) is perfectlypossible to do from another platform due to
> the fact that thePE format (the official word for Windows executables) is
> fullydocumented and disclosed. There's a lack of tools though.
> >> But speaking of DMGs, I believe mkfs.hfsplus is able to make images, so
> >> there is code out there, just not pure Java.
> Yes, true. That's a Linux-only tool. They reverse engineered the
> DMG format.
> Apologies if I side-tracked the discussion. Best of luck with yourproject.
> Peter
>
>
>
>
>
>
>
>
>
> On Friday, April 21, 2017 5:58 PM, Emilian Bold <
> emilian.bold@gmail.com> wrote:
>
>
> @Peter: perhaps I should have mentioned that I already did a DMG, see
> https://nextbeans.com/downloads/retina/ and it's perfectly easy. Indeed,
> it
> helps that I'm working on a Mac and bypassed NBI entirely.
>
> I don't see a huge problem in using native OS build slaves to get a
> particular installer. I don't believe there is a crossplatform way to sign
> Windows EXEs or change Windows EXE icons, etc.
>
> But speaking of DMGs, I believe mkfs.hfsplus is able to make images, so
> there is code out there, just not pure Java.
>
>
> --emi
>
> On Fri, Apr 21, 2017 at 6:44 PM, Peter Hansson <
> peterhansson_se@yahoo.com.invalid> wrote:
>
> >
> >
> > Some additional notes on this.
> >
> > First of all: NBI doesn't out-of-the-box support bundling a JRE for the
> OS
> > X platform.
> > This is dead simple to fix. You can read more about it here:
> >
> > http://stackoverflow.com/a/30479473/1504556
> >
> > (don't expect the RFE to be picked up, I believe development in
> >
> > the NBI area is stalled which is why I'm sooo looking forward to
> >
> > the Apache setup)
> >
> > Then to your actual question: Why isn't drag'n & drop installation
> > supported ?
> >
> >
> > I think what you refer is a DMG file. Just like anything else concerning
> > Apple
> > this is completely secret. It is a proprietary format and I guess Apple
> > will come
> >
> > after you if you try to reverse engineer it. I'm pretty sure this is the
> > reason
> > why NBI isn't able to create a DMG file.
> >
> > Apple's strategy is clear: If you want to build a DMG for OS X you
> better
> > buy a copy of our OS. And if you want use our OS then you must
> > buy a copy of our hardware. (Apple doesn't allow you virtualize the OS).
> >
> > As it stands at the moment you'll need to actually be on a Mac OS X to
> > create
> >
> > a DMG file. NBI was cleverly designed to be platform agnostic, meaning
> you
> > can
> > build an installer package for Windows on say Linux. So you don't need
> > a build farm with each of your target platforms. This is actually what
> sets
> > NBI apart from the competition. But on OS X it means that the clever
> people
> > who designed NBI had to stop at ZIP files and App Bundles.
> >
> > So, how does netbeans.org manage to create a DMG installer for the
> >
> > IDE itself? Because they "cheat". They have an additional proprietary
> > process which is executed on some Mac OS X box they must have access to.
> > By proprietary I mean it is outside of what NBI is able to do and not
> >
> > documented. You can probably peak at what they do and then replicate
> >
> > their process.
> >
> >
> > Peter
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wednesday, April 19, 2017 7:55 PM, Emilian Bold <
> emilian.bold@gmail.com>
> > wrote:
> >
> >
> >
> > > The one difference I remember from that nb-javac conversation was that
> > the JRE / JDK itself can be considered as "platform
> > dependencies". Am I right to assume that still rules out the IDE
> binaries
> > shipping with the JDK, from an Apache perspective at least?
> >
> > I think there is something more refined here wrt the GPL and Apache.
> > nbjavac as a module dependency doesn't seem to me the same as JRE as a
> > runtime dependency we could bundle.
> >
> > Perhaps some mentor or legal can jump in?
> >
> > The Classpath exception is explicitly written for this situation.
> >
> > > If so, that might render this thread moot - an installer that can
> > download and install the JDK would probably be more user friendly then?
> >
> > Not to me. I already have the JDK installed and I don't want to type my
> > admin password for NetBeans. A drag and drop Mac image would be perfect.
> >
> > Somebody doing PHP or JavaScript will not have a JDK so
> > bundling/installing the JRE there makes sense.
> >
> > Platform apps might also prefer the drag and drop approach.
> >
> > --emi
> >
> > Pe 19 apr. 2017, la 20:21, Neil C Smith <ne...@googlemail.com>
> a
> > scris:
> >
> >
> > > I'm not sure this has any effect on Platform apps, just on distribution
> > of
> > > Apache NetBeans. The one difference I remember from that nb-javac
> > > conversation was that the JRE / JDK itself can be considered as
> "platform
> > > dependencies". Am I right to assume that still rules out the IDE
> > binaries
> > > shipping with the JDK, from an Apache perspective at least? If so,
> that
> > > might render this thread moot - an installer that can download and
> > install
> > > the JDK would probably be more user friendly then?
> >
>
>
>
>
Re: Drag and drop install on macOS instead of the current installer
package
Posted by Peter Hansson <pe...@yahoo.com.INVALID>.
>> I don't see a huge problem in using native OS build slaves to get a
>> particular installer.
I wish my company had that kind of dough. :-)
>> I don't believe there is a crossplatform way to sign
>> Windows EXEs or change Windows EXE icons, etc.
Wouldn't know about signing. I would think so.Changing resources inside an EXE (e.g. icons) is perfectlypossible to do from another platform due to the fact that thePE format (the official word for Windows executables) is fullydocumented and disclosed. There's a lack of tools though.
>> But speaking of DMGs, I believe mkfs.hfsplus is able to make images, so
>> there is code out there, just not pure Java.
Yes, true. That's a Linux-only tool. They reverse engineered the
DMG format.
Apologies if I side-tracked the discussion. Best of luck with yourproject.
Peter
On Friday, April 21, 2017 5:58 PM, Emilian Bold <em...@gmail.com> wrote:
@Peter: perhaps I should have mentioned that I already did a DMG, see
https://nextbeans.com/downloads/retina/ and it's perfectly easy. Indeed, it
helps that I'm working on a Mac and bypassed NBI entirely.
I don't see a huge problem in using native OS build slaves to get a
particular installer. I don't believe there is a crossplatform way to sign
Windows EXEs or change Windows EXE icons, etc.
But speaking of DMGs, I believe mkfs.hfsplus is able to make images, so
there is code out there, just not pure Java.
--emi
On Fri, Apr 21, 2017 at 6:44 PM, Peter Hansson <
peterhansson_se@yahoo.com.invalid> wrote:
>
>
> Some additional notes on this.
>
> First of all: NBI doesn't out-of-the-box support bundling a JRE for the OS
> X platform.
> This is dead simple to fix. You can read more about it here:
>
> http://stackoverflow.com/a/30479473/1504556
>
> (don't expect the RFE to be picked up, I believe development in
>
> the NBI area is stalled which is why I'm sooo looking forward to
>
> the Apache setup)
>
> Then to your actual question: Why isn't drag'n & drop installation
> supported ?
>
>
> I think what you refer is a DMG file. Just like anything else concerning
> Apple
> this is completely secret. It is a proprietary format and I guess Apple
> will come
>
> after you if you try to reverse engineer it. I'm pretty sure this is the
> reason
> why NBI isn't able to create a DMG file.
>
> Apple's strategy is clear: If you want to build a DMG for OS X you better
> buy a copy of our OS. And if you want use our OS then you must
> buy a copy of our hardware. (Apple doesn't allow you virtualize the OS).
>
> As it stands at the moment you'll need to actually be on a Mac OS X to
> create
>
> a DMG file. NBI was cleverly designed to be platform agnostic, meaning you
> can
> build an installer package for Windows on say Linux. So you don't need
> a build farm with each of your target platforms. This is actually what sets
> NBI apart from the competition. But on OS X it means that the clever people
> who designed NBI had to stop at ZIP files and App Bundles.
>
> So, how does netbeans.org manage to create a DMG installer for the
>
> IDE itself? Because they "cheat". They have an additional proprietary
> process which is executed on some Mac OS X box they must have access to.
> By proprietary I mean it is outside of what NBI is able to do and not
>
> documented. You can probably peak at what they do and then replicate
>
> their process.
>
>
> Peter
>
>
>
>
>
>
>
>
>
>
>
>
> On Wednesday, April 19, 2017 7:55 PM, Emilian Bold <em...@gmail.com>
> wrote:
>
>
>
> > The one difference I remember from that nb-javac conversation was that
> the JRE / JDK itself can be considered as "platform
> dependencies". Am I right to assume that still rules out the IDE binaries
> shipping with the JDK, from an Apache perspective at least?
>
> I think there is something more refined here wrt the GPL and Apache.
> nbjavac as a module dependency doesn't seem to me the same as JRE as a
> runtime dependency we could bundle.
>
> Perhaps some mentor or legal can jump in?
>
> The Classpath exception is explicitly written for this situation.
>
> > If so, that might render this thread moot - an installer that can
> download and install the JDK would probably be more user friendly then?
>
> Not to me. I already have the JDK installed and I don't want to type my
> admin password for NetBeans. A drag and drop Mac image would be perfect.
>
> Somebody doing PHP or JavaScript will not have a JDK so
> bundling/installing the JRE there makes sense.
>
> Platform apps might also prefer the drag and drop approach.
>
> --emi
>
> Pe 19 apr. 2017, la 20:21, Neil C Smith <ne...@googlemail.com> a
> scris:
>
>
> > I'm not sure this has any effect on Platform apps, just on distribution
> of
> > Apache NetBeans. The one difference I remember from that nb-javac
> > conversation was that the JRE / JDK itself can be considered as "platform
> > dependencies". Am I right to assume that still rules out the IDE
> binaries
> > shipping with the JDK, from an Apache perspective at least? If so, that
> > might render this thread moot - an installer that can download and
> install
> > the JDK would probably be more user friendly then?
>
Re: Drag and drop install on macOS instead of the current installer package
Posted by Emilian Bold <em...@gmail.com>.
@Peter: perhaps I should have mentioned that I already did a DMG, see
https://nextbeans.com/downloads/retina/ and it's perfectly easy. Indeed, it
helps that I'm working on a Mac and bypassed NBI entirely.
I don't see a huge problem in using native OS build slaves to get a
particular installer. I don't believe there is a crossplatform way to sign
Windows EXEs or change Windows EXE icons, etc.
But speaking of DMGs, I believe mkfs.hfsplus is able to make images, so
there is code out there, just not pure Java.
--emi
On Fri, Apr 21, 2017 at 6:44 PM, Peter Hansson <
peterhansson_se@yahoo.com.invalid> wrote:
>
>
> Some additional notes on this.
>
> First of all: NBI doesn't out-of-the-box support bundling a JRE for the OS
> X platform.
> This is dead simple to fix. You can read more about it here:
>
> http://stackoverflow.com/a/30479473/1504556
>
> (don't expect the RFE to be picked up, I believe development in
>
> the NBI area is stalled which is why I'm sooo looking forward to
>
> the Apache setup)
>
> Then to your actual question: Why isn't drag'n & drop installation
> supported ?
>
>
> I think what you refer is a DMG file. Just like anything else concerning
> Apple
> this is completely secret. It is a proprietary format and I guess Apple
> will come
>
> after you if you try to reverse engineer it. I'm pretty sure this is the
> reason
> why NBI isn't able to create a DMG file.
>
> Apple's strategy is clear: If you want to build a DMG for OS X you better
> buy a copy of our OS. And if you want use our OS then you must
> buy a copy of our hardware. (Apple doesn't allow you virtualize the OS).
>
> As it stands at the moment you'll need to actually be on a Mac OS X to
> create
>
> a DMG file. NBI was cleverly designed to be platform agnostic, meaning you
> can
> build an installer package for Windows on say Linux. So you don't need
> a build farm with each of your target platforms. This is actually what sets
> NBI apart from the competition. But on OS X it means that the clever people
> who designed NBI had to stop at ZIP files and App Bundles.
>
> So, how does netbeans.org manage to create a DMG installer for the
>
> IDE itself? Because they "cheat". They have an additional proprietary
> process which is executed on some Mac OS X box they must have access to.
> By proprietary I mean it is outside of what NBI is able to do and not
>
> documented. You can probably peak at what they do and then replicate
>
> their process.
>
>
> Peter
>
>
>
>
>
>
>
>
>
>
>
>
> On Wednesday, April 19, 2017 7:55 PM, Emilian Bold <em...@gmail.com>
> wrote:
>
>
>
> > The one difference I remember from that nb-javac conversation was that
> the JRE / JDK itself can be considered as "platform
> dependencies". Am I right to assume that still rules out the IDE binaries
> shipping with the JDK, from an Apache perspective at least?
>
> I think there is something more refined here wrt the GPL and Apache.
> nbjavac as a module dependency doesn't seem to me the same as JRE as a
> runtime dependency we could bundle.
>
> Perhaps some mentor or legal can jump in?
>
> The Classpath exception is explicitly written for this situation.
>
> > If so, that might render this thread moot - an installer that can
> download and install the JDK would probably be more user friendly then?
>
> Not to me. I already have the JDK installed and I don't want to type my
> admin password for NetBeans. A drag and drop Mac image would be perfect.
>
> Somebody doing PHP or JavaScript will not have a JDK so
> bundling/installing the JRE there makes sense.
>
> Platform apps might also prefer the drag and drop approach.
>
> --emi
>
> Pe 19 apr. 2017, la 20:21, Neil C Smith <ne...@googlemail.com> a
> scris:
>
>
> > I'm not sure this has any effect on Platform apps, just on distribution
> of
> > Apache NetBeans. The one difference I remember from that nb-javac
> > conversation was that the JRE / JDK itself can be considered as "platform
> > dependencies". Am I right to assume that still rules out the IDE
> binaries
> > shipping with the JDK, from an Apache perspective at least? If so, that
> > might render this thread moot - an installer that can download and
> install
> > the JDK would probably be more user friendly then?
>
Re: Drag and drop install on macOS instead of the current installer package
Posted by Emilian Bold <em...@gmail.com>.
Gatekeeper is a problem regardless if we put a drag and drop application
bundle or an installer package in the DMG.
We will just have to sign the app, like Oracle does right now.
--emi
On Fri, Apr 21, 2017 at 9:13 PM, Raphael Bircher <rb...@gmail.com>
wrote:
> Am .04.2017, 18:38 Uhr, schrieb Neil C Smith <
> neilcsmith.net@googlemail.com>:
>
> On Fri, Apr 21, 2017 at 4:44 PM Peter Hansson
>> <pe...@yahoo.com.invalid> wrote:
>>
>> As it stands at the moment you'll need to actually be on a Mac OS X to
>>> create
>>> a DMG file. NBI was cleverly designed to be platform agnostic, meaning
>>> you
>>> can
>>> build an installer package for Windows on say Linux. So you don't need
>>> a build farm with each of your target platforms. This is actually what
>>> sets
>>> NBI apart from the competition. But on OS X it means that the clever
>>> people
>>> who designed NBI had to stop at ZIP files and App Bundles.
>>>
>>>
>> Isn't what we're talking about just App Bundles though? They don't *have*
>> to be inside a DMG, although I guess that's more common. You can also
>> stick them in a zip or tar.gz file. Possibly more of an issue is working
>> out how to handle Gatekeeper?!
>>
> You to be a certified developer and register the Application. or you teach
> the people how to ship around this problem.
>
> I made a video about this since we have the same Problem at OpenOffice
> https://youtu.be/tTZw5o2EC0M
>
>
>> Incidentally, I'm currently looking into NSIS as an alternative for a
>> platform application Windows installer - it's platform agnostic from a
>> build point of view.
>>
>> Best wishes,
>>
>> Neil
>>
>>
>>
>
> --
> My introduction https://youtu.be/Ln4vly5sxYU
>
Re: Drag and drop install on macOS instead of the current installer
package
Posted by Raphael Bircher <rb...@gmail.com>.
Am .04.2017, 18:38 Uhr, schrieb Neil C Smith
<ne...@googlemail.com>:
> On Fri, Apr 21, 2017 at 4:44 PM Peter Hansson
> <pe...@yahoo.com.invalid> wrote:
>
>> As it stands at the moment you'll need to actually be on a Mac OS X to
>> create
>> a DMG file. NBI was cleverly designed to be platform agnostic, meaning
>> you
>> can
>> build an installer package for Windows on say Linux. So you don't need
>> a build farm with each of your target platforms. This is actually what
>> sets
>> NBI apart from the competition. But on OS X it means that the clever
>> people
>> who designed NBI had to stop at ZIP files and App Bundles.
>>
>
> Isn't what we're talking about just App Bundles though? They don't
> *have*
> to be inside a DMG, although I guess that's more common. You can also
> stick them in a zip or tar.gz file. Possibly more of an issue is working
> out how to handle Gatekeeper?!
You to be a certified developer and register the Application. or you teach
the people how to ship around this problem.
I made a video about this since we have the same Problem at OpenOffice
https://youtu.be/tTZw5o2EC0M
>
> Incidentally, I'm currently looking into NSIS as an alternative for a
> platform application Windows installer - it's platform agnostic from a
> build point of view.
>
> Best wishes,
>
> Neil
>
>
--
My introduction https://youtu.be/Ln4vly5sxYU
Re: Drag and drop install on macOS instead of the current installer package
Posted by Neil C Smith <ne...@googlemail.com>.
On Fri, Apr 21, 2017 at 4:44 PM Peter Hansson
<pe...@yahoo.com.invalid> wrote:
> As it stands at the moment you'll need to actually be on a Mac OS X to
> create
> a DMG file. NBI was cleverly designed to be platform agnostic, meaning you
> can
> build an installer package for Windows on say Linux. So you don't need
> a build farm with each of your target platforms. This is actually what sets
> NBI apart from the competition. But on OS X it means that the clever people
> who designed NBI had to stop at ZIP files and App Bundles.
>
Isn't what we're talking about just App Bundles though? They don't *have*
to be inside a DMG, although I guess that's more common. You can also
stick them in a zip or tar.gz file. Possibly more of an issue is working
out how to handle Gatekeeper?!
Incidentally, I'm currently looking into NSIS as an alternative for a
platform application Windows installer - it's platform agnostic from a
build point of view.
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Drag and drop install on macOS instead of the current installer
package
Posted by Peter Hansson <pe...@yahoo.com.INVALID>.
Some additional notes on this.
First of all: NBI doesn't out-of-the-box support bundling a JRE for the OS X platform.
This is dead simple to fix. You can read more about it here:
http://stackoverflow.com/a/30479473/1504556
(don't expect the RFE to be picked up, I believe development in
the NBI area is stalled which is why I'm sooo looking forward to
the Apache setup)
Then to your actual question: Why isn't drag'n & drop installation supported ?
I think what you refer is a DMG file. Just like anything else concerning Apple
this is completely secret. It is a proprietary format and I guess Apple will come
after you if you try to reverse engineer it. I'm pretty sure this is the reason
why NBI isn't able to create a DMG file.
Apple's strategy is clear: If you want to build a DMG for OS X you better
buy a copy of our OS. And if you want use our OS then you must
buy a copy of our hardware. (Apple doesn't allow you virtualize the OS).
As it stands at the moment you'll need to actually be on a Mac OS X to create
a DMG file. NBI was cleverly designed to be platform agnostic, meaning you can
build an installer package for Windows on say Linux. So you don't need
a build farm with each of your target platforms. This is actually what sets
NBI apart from the competition. But on OS X it means that the clever people
who designed NBI had to stop at ZIP files and App Bundles.
So, how does netbeans.org manage to create a DMG installer for the
IDE itself? Because they "cheat". They have an additional proprietary
process which is executed on some Mac OS X box they must have access to.
By proprietary I mean it is outside of what NBI is able to do and not
documented. You can probably peak at what they do and then replicate
their process.
Peter
On Wednesday, April 19, 2017 7:55 PM, Emilian Bold <em...@gmail.com> wrote:
> The one difference I remember from that nb-javac conversation was that the JRE / JDK itself can be considered as "platform
dependencies". Am I right to assume that still rules out the IDE binaries shipping with the JDK, from an Apache perspective at least?
I think there is something more refined here wrt the GPL and Apache. nbjavac as a module dependency doesn't seem to me the same as JRE as a runtime dependency we could bundle.
Perhaps some mentor or legal can jump in?
The Classpath exception is explicitly written for this situation.
> If so, that might render this thread moot - an installer that can download and install the JDK would probably be more user friendly then?
Not to me. I already have the JDK installed and I don't want to type my admin password for NetBeans. A drag and drop Mac image would be perfect.
Somebody doing PHP or JavaScript will not have a JDK so bundling/installing the JRE there makes sense.
Platform apps might also prefer the drag and drop approach.
--emi
Pe 19 apr. 2017, la 20:21, Neil C Smith <ne...@googlemail.com> a scris:
> I'm not sure this has any effect on Platform apps, just on distribution of
> Apache NetBeans. The one difference I remember from that nb-javac
> conversation was that the JRE / JDK itself can be considered as "platform
> dependencies". Am I right to assume that still rules out the IDE binaries
> shipping with the JDK, from an Apache perspective at least? If so, that
> might render this thread moot - an installer that can download and install
> the JDK would probably be more user friendly then?
Re: Drag and drop install on macOS instead of the current installer
package
Posted by Simon IJskes <si...@ijskes.org>.
On 19-04-17 19:55, Emilian Bold wrote:
>> The one difference I remember from that nb-javac conversation was that the JRE / JDK itself can be considered as "platform
> dependencies". Am I right to assume that still rules out the IDE binaries shipping with the JDK, from an Apache perspective at least?
>
> I think there is something more refined here wrt the GPL and Apache. nbjavac as a module dependency doesn't seem to me the same as JRE as a runtime dependency we could bundle.
>
> Perhaps some mentor or legal can jump in?
My advice, try to find if there is a similar case documented on
apache.org. And if not, subscribe to legal-discuss@a.o and ask there.
I've never seen legal join in on discussion on a project list.
G. Simon
Re: Drag and drop install on macOS instead of the current installer package
Posted by Emilian Bold <em...@gmail.com>.
> The one difference I remember from that nb-javac conversation was that the JRE / JDK itself can be considered as "platform
dependencies". Am I right to assume that still rules out the IDE binaries shipping with the JDK, from an Apache perspective at least?
I think there is something more refined here wrt the GPL and Apache. nbjavac as a module dependency doesn't seem to me the same as JRE as a runtime dependency we could bundle.
Perhaps some mentor or legal can jump in?
The Classpath exception is explicitly written for this situation.
> If so, that might render this thread moot - an installer that can download and install the JDK would probably be more user friendly then?
Not to me. I already have the JDK installed and I don't want to type my admin password for NetBeans. A drag and drop Mac image would be perfect.
Somebody doing PHP or JavaScript will not have a JDK so bundling/installing the JRE there makes sense.
Platform apps might also prefer the drag and drop approach.
--emi
Pe 19 apr. 2017, la 20:21, Neil C Smith <ne...@googlemail.com> a scris:
> I'm not sure this has any effect on Platform apps, just on distribution of
> Apache NetBeans. The one difference I remember from that nb-javac
> conversation was that the JRE / JDK itself can be considered as "platform
> dependencies". Am I right to assume that still rules out the IDE binaries
> shipping with the JDK, from an Apache perspective at least? If so, that
> might render this thread moot - an installer that can download and install
> the JDK would probably be more user friendly then?
Re: Drag and drop install on macOS instead of the current installer package
Posted by Neil C Smith <ne...@googlemail.com>.
On Wed, 19 Apr 2017 at 14:22 Emilian Bold <em...@gmail.com> wrote:
> Hm, the nb-javac problem was for GPL dependencies of an Apache project.
>
> I wonder if the interpretation is the same for bundling a JRE? That would
> restrict Platform apps a lot.
>
I'm not sure this has any effect on Platform apps, just on distribution of
Apache NetBeans. The one difference I remember from that nb-javac
conversation was that the JRE / JDK itself can be considered as "platform
dependencies". Am I right to assume that still rules out the IDE binaries
shipping with the JDK, from an Apache perspective at least? If so, that
might render this thread moot - an installer that can download and install
the JDK would probably be more user friendly then?
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Drag and drop install on macOS instead of the current installer package
Posted by Emilian Bold <em...@gmail.com>.
Hm, the nb-javac problem was for GPL dependencies of an Apache project.
I wonder if the interpretation is the same for bundling a JRE? That would restrict Platform apps a lot.
Perhaps you should open an issue for the launcher silent failure.
--emi
Pe 19 apr. 2017, la 15:01, Neil C Smith <ne...@googlemail.com> a scris:
> Hi,
>
>> On Wed, 19 Apr 2017 at 12:23 Emilian Bold <em...@apache.org> wrote:
>>
>> I suspect bundling the JDK, as opposed to just the JRE, might have
>> licensing issues.
>>
>
> Considering they have the same license, there shouldn't be a difference.
> Mind you, I think that license would be a problem full stop, unless the
> binaries were distributed by a third party? This is similar to the
> discussion around nb-javac.
>
>
>> As for the launcher, it should be a bug if it silently fails. On macOS
>> you are able, as a last resort, to show a dialog using Apple Script or
>> something else.
>>
>
> Yes, was looking at modifying the script to do this or similar on OSX and
> Linux.
>
> Neil
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Drag and drop install on macOS instead of the current installer package
Posted by Neil C Smith <ne...@googlemail.com>.
Hi,
On Wed, 19 Apr 2017 at 12:23 Emilian Bold <em...@apache.org> wrote:
> I suspect bundling the JDK, as opposed to just the JRE, might have
> licensing issues.
>
Considering they have the same license, there shouldn't be a difference.
Mind you, I think that license would be a problem full stop, unless the
binaries were distributed by a third party? This is similar to the
discussion around nb-javac.
> As for the launcher, it should be a bug if it silently fails. On macOS
> you are able, as a last resort, to show a dialog using Apple Script or
> something else.
>
Yes, was looking at modifying the script to do this or similar on OSX and
Linux.
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Drag and drop install on macOS instead of the current installer package
Posted by Emilian Bold <em...@apache.org>.
Hm, I guess the official NetBeans installer has some native code in
there so it might still show some dialog without a JRE.
For a Platform app I would generally include a JRE, unless you really
care about bandwidth. At least for the Mac AppStore you have to
include the JRE.
NetBeans itself could include a JRE for, say, the PHP bundle but for
Java development could offer an image without a JRE.
I suspect bundling the JDK, as opposed to just the JRE, might have
licensing issues.
As for the launcher, it should be a bug if it silently fails. On macOS
you are able, as a last resort, to show a dialog using Apple Script or
something else.
--emi
On Wed, Apr 19, 2017 at 1:47 PM, Neil C Smith
<ne...@googlemail.com> wrote:
> Hi,
>
> On Wed, 19 Apr 2017 at 11:40 Emilian Bold <em...@gmail.com> wrote:
>
>> Either we assume the user has it ...
>>
>
> My (wordily made!) point was that at least with the RCP launcher, the .app
> fails silently if it can't find a JVM. The icon bounces around for a bit
> and then disappears. Not sure what the installer does if it can't find a
> JVM? I think we'd need to find a way to pop up a GUI dialog from the shell
> script in case there's no JVM, unless it's bundled of course.
>
> Neil
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Drag and drop install on macOS instead of the current installer package
Posted by Neil C Smith <ne...@googlemail.com>.
Hi,
On Wed, 19 Apr 2017 at 11:40 Emilian Bold <em...@gmail.com> wrote:
> Either we assume the user has it ...
>
My (wordily made!) point was that at least with the RCP launcher, the .app
fails silently if it can't find a JVM. The icon bounces around for a bit
and then disappears. Not sure what the installer does if it can't find a
JVM? I think we'd need to find a way to pop up a GUI dialog from the shell
script in case there's no JVM, unless it's bundled of course.
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Drag and drop install on macOS instead of the current installer package
Posted by Emilian Bold <em...@gmail.com>.
Well the point was you don't really need to search for Java.
Either we assume the user has it or we bundle a JRE.
--emi
Pe 19 apr. 2017, la 13:17, Neil C Smith <ne...@googlemail.com> a scris:
> Hi Emi,
>
>> On Wed, 19 Apr 2017 at 07:53 Emilian Bold <em...@apache.org> wrote:
>>
>> ... while the rest will run as-is using
>> the Java on the PATH.
>>
>
> Interesting topic! I think I mostly agree with you. While slightly
> different IIRC, it would be good to consider the needs of RCP applications
> here too. I experimented with building an OSX installer for Praxis LIVE at
> the last release, but the RCP installer build seems to have broken relative
> resource references.
>
> More relevantly, one thing I've noticed shipping as an .app is the problem
> if Java isn't on the path. The launcher just fails silently - few user bug
> reports there! If the IDE were to be shipped as an .app would it have the
> same issue? I assume the current installer handles this situation better?
> Aren't .app bundles generally intended to be self-contained, in which case
> should we consider shipping with JDK, and not relying on Java in the path?
>
> 2c,
>
> Best wishes,
>
> Neil
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Drag and drop install on macOS instead of the current installer package
Posted by Neil C Smith <ne...@googlemail.com>.
Hi Emi,
On Wed, 19 Apr 2017 at 07:53 Emilian Bold <em...@apache.org> wrote:
> ... while the rest will run as-is using
> the Java on the PATH.
>
Interesting topic! I think I mostly agree with you. While slightly
different IIRC, it would be good to consider the needs of RCP applications
here too. I experimented with building an OSX installer for Praxis LIVE at
the last release, but the RCP installer build seems to have broken relative
resource references.
More relevantly, one thing I've noticed shipping as an .app is the problem
if Java isn't on the path. The launcher just fails silently - few user bug
reports there! If the IDE were to be shipped as an .app would it have the
same issue? I assume the current installer handles this situation better?
Aren't .app bundles generally intended to be self-contained, in which case
should we consider shipping with JDK, and not relying on Java in the path?
2c,
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org