On Wed, Nov 15, 2017 at 8:55 AM, Lars Bruun-Hansen <[email protected]> wrote:
> Ahh. I see. I'm sure there's solution to the module dependency problem. I > like best your idea of a dummy. Why do you need checks on entry points? > Because you want it to fail gracefully in the absence of the real library? > Isn't that nice-to-have for now? (we will tell the user in very clear words > Without the checks, various things will fail with exceptions/errors - it may happen even before/while showing the dialog (there are warmup tasks that create/preinitialize Java components). That does not seem like a good behavior to me. Jan > that this library is needed one way or the other) > > Regarding if it is OK to automate this process so that user only needs to > click a button: I don't see why not. As long as the user is made aware of > what he's doing and is accepting an on-screen nb-javac license, etc. The > IDE already allows to download plugins from various sources, also non-ASF > or non Apache Licensed. This is no different. > > You really don't want to do a download task *outside* of the Platform. > Because you don't have proprietary stuff like Oracle's deploy.jar you'll > need to rely on Platform to find your way to Internet. > > Assuming the dependency problem can be solved, I'm hoping for the following > solution: > > - The first time the IDE starts you'll be asked if you want to download and > install nb-javac. In terms of development effort this is mainly an UI > exercise. With the latest proxy improvements this will hopefully work for > 95% of users without them having to do anything. Then there's 3% who we > need to ask to input their proxy settings manually in Options (we can open > the window for them if download task fails). > - The last 2% are users where we just cannot make the download task work > from within NetBeans. For these users we'll need manual instructions on > what they need to do. > > nb-javac hosted on say Bitbucket as a mirror of hg.netbeans.org and the > users download from bitbucket.com/<projectname>/downloads. Something like > that. > > > I'll gladly work on some of this. I feel very strongly about the need for a > click-a-button solution. > > > Lars > > PS: Regardless of the above it may still be a good idea to work in parallel > on a long term solution, i.e. get rid of the dependency of nb-javac and > replace with something else, but I feel the above is pretty > straight-forward as an acceptable solution for the next 1-2 years. > > > > > > On Wed, Nov 15, 2017 at 7:40 AM, Jan Lahoda <[email protected]> wrote: > > > On Tue, Nov 14, 2017 at 9:09 PM, Lars Bruun-Hansen < > [email protected] > > > > > wrote: > > > > > I think (a) is a major deviation from NetBeans' hallmark: > plug-and-play, > > > just install it and start programming. It is exactly this kind of thing > > > we've accused Eclipse for over the years. If NetBeans started on that > > path > > > it would be ironic. I think it can only be justified if it is an > > > intermediary solution because we really want to release something NOW. > > And > > > even then I feel it will be frowned upon and we may loose some users > as a > > > consequence. > > > > > > Re (b): This can be done when the IDE starts the first time. Then > you'll > > > have proxy resolution in place. Have the user accept the nb-javac > > license, > > > start a download task and do it all automatically. The user can decline > > of > > > course, but then he'll basically have an IDE which cannot be used for > > Java > > > development. I think this is an acceptable workflow. There are lots of > > > examples from open source software where it has to happen like this > (for > > > legal reasons). The best solutions has this automated so it is really > > just > > > a click for the user. > > > > > > > While I agree with that, it is not immediately obvious how to do this (or > > if this is OK for an Apache product). As the modules depending on > > libs.javacapi and libs.javacimpl are usually regular modules, a missing > > dependency will trigger an "unsatisfied dependencies" dialog on startup > and > > the modules would be really disabled. Two possible solutions come to > mind: > > a) make all the modules eager (which would probably bring its own > problems, > > like the modules would be silently disabled if any deendency would be > > missing, not only libs.javac{api,impl}); b) keep the libs.javac{api,impl} > > modules, just don't put the library in them. Do manual checks on all > entry > > points (which may or may not be a significant number) to see if nb-javac > is > > available and do nothing if it is not. And install the nb-javac library > > using module fragments (which one of the tricks the jdk-javac branch is > > doing). > > > > Jan > > > > > > > So, between (a) and (b), I vote for (b). > > > > > > As a side note I'll be launching even more PRs to make sure that NB can > > > truly detect the user's proxy settings without having the user enter > the > > > proxy settings manually in NB. First step was PR161 (already > integrated). > > > More will come, for example so that NB will have WPAD support. The > > > benchmark is what the browsers do. With a modern browser like > > > Chrome/Firefox/Edge the user rarely needs to configure anything. The > same > > > should be true for NB: if the Chrome/FF/Edge can detect proxy settings > > > without user intervention then so should NetBeans. Not there yet, but > > we'll > > > get there. > > > > > > > > > > > > > > > On Tue, Nov 14, 2017 at 8:36 PM, Neil C Smith <[email protected]> > > > wrote: > > > > > > > On Tue, 14 Nov 2017, 18:54 Jan Lahoda, <[email protected]> wrote: > > > > > > > > > Another aspect is from where to download the library: I assume we > > would > > > > > need a reasonably stable place to which we could point the users. > > > > > > > > > > Are there any opinions on this? > > > > > > > > > > > > > As before when this came up, as well as where it's downloaded from, > I'd > > > be > > > > interested to know how it's going to be maintained there? It feels > hard > > > to > > > > answer one question without the other? > > > > > > > > I also still wonder whether there's been further thought on asking > the > > > > OpenJDK project to host it (as ide-javac)? The last time I suggested > > that > > > > there was a feeling that it was too NetBeans specific, and other > > projects > > > > were moving to things like Language Server Protocol. Just for the > > record > > > > (as I mentioned to Jaroslav a while back) of the two LSP plugins for > > > Java, > > > > one is Eclipse based, and the other is using nb-javac. There is > > > obviously a > > > > wider need for the features it brings! > > > > > > > > Best wishes, > > > > > > > > Neil > > > > > > > > > -- > > > > Neil C Smith > > > > Artist & Technologist > > > > www.neilcsmith.net > > > > > > > > Praxis LIVE - hybrid visual IDE for creative coding - > > www.praxislive.org > > > > > > > > > >
