I didn't mean to involve you too much with this, just curious if my patch made sense. I certainly don't want to split the efforts under NetBeans.
It would be great if there was a single flag in the canonical build that would include nb-javac but it doesn't seem obvious to me how... Especially considering the current nb/updatecenters/extra config. But, as you can see, if I can just patch things then the change is quite small. Which seems not a whole lot of work for me in the future to maintain. I recently asked if Apache is fine with me producing a NetBeans installer that is only the NetBeans release + a bundled JDK. The PMC Chair reply was that Apache most certainly does *not* allow such a thing and that the project would have to be rebranded. So, for this reason alone a distribution is still needed. --emi On Tue, Nov 26, 2019 at 11:17 PM Jan Lahoda <lah...@gmail.com> wrote: > > On Mon, Nov 25, 2019 at 8:18 PM Emilian Bold <emilian.b...@gmail.com> wrote: > > > Jan, I'm curious if this patch makes sense to you: > > > > https://github.com/OpenBeans/OpenBeans/commit/ec4bfe3db429abd8830d750f8bc5dcc14285db37#diff-03465d6aba3fa54304c800a82884a4b9R31 > > > Technically, yes, this is likely to work. But I wonder if that's the good > direction overall - it feels like splitting the efforts (just the effort to > keep the patch queue apply!), rather than joining the efforts. > > One related note is that when I asked if third-party can still call their > build Apache Netbeans, the answer[1] (which was not disputed) was that > there are draft conditions on that: > http://www.apache.org/foundation/marks/downstream.html > > One of the conditions is: > All source code from which the software it is built must be available in > the Apache Software Foundation source code repository for the project. > > So, custom patches are not allowed, but if there would be a way to > configure the canonical build to include nb-javac and other libraries, > third-parties could produce binaries called "Apache NetBeans" with those > libraries. Advantage is that everything is joint development here, as > opposed to creating separate "distributions". > > (Another condition is "The software must be provided via a channel the end > user would expect to use to obtain packages for their platform.", but I > think a webpage satisfies that for most platforms.) > > Jan > > [1] > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201911.mbox/%3c86284876-2960-43eb-b3ec-b33538864...@apache.org%3e > > > > > > > > > I'm just including the javacapi/impl JARs in libs.javacimpl, like we > > used to in 8.2. I *think* this should be sufficient but perhaps I'm > > not testing it correctly. > > > > --emi > > > > On Mon, Nov 25, 2019 at 9:33 AM Jan Lahoda <lah...@gmail.com> wrote: > > > > > > Hello Emilian, > > > > > > While I understand your issue, the problem is that the space for > > solutions > > > if significantly limited: > > > -the ASF does not allow distribution of GPLv2+CPE libraries inside the > > > Apache distribution > > > -there is only a single Plugin Portal for all NetBeans 11.0, 11.1 and > > 11.2; > > > yet, nb-javac based on JDK 13 *cannot* work in NetBeans 11.0, because the > > > old javadoc APIs are stripped from it. So we cannot just upload the new > > > nb-javac to the Plugin Portal, as that would (and did, actually) break > > > NetBeans 11.0. And I don't think this will be a unique situation, > > assuming > > > the records (JEP 359) is merged into JDK 14, nb-javac based on JDK 14 > > will > > > not work with any NetBeans 11.0, 11.1 and 11.2, because of new enum > > > constants added to ElementKind. Overall, as long as we share the Plugin > > > Portals across versions (which makes sense, unless we want to force > > > everyone to upload their plugins to a new portal every 3 months), we > > cannot > > > have nb-javac there, as older versions of NetBeans may not be compatible > > > with the new nb-javac. > > > > > > If you want to add a new constraint that it must be easy to do a build > > > which includes nb-javac, I have nothing against that, but you may need to > > > design that yourself (and preferably contribute that back). > > > > > > Jan > > > > > > > > > On Mon, Nov 25, 2019 at 12:15 AM Emilian Bold <emilian.b...@gmail.com> > > > wrote: > > > > > > > Hello, > > > > > > > > Before 11.2, nb-javac was just suggested and downloaded as a plain 3rd > > > > party plugin from the UC. Neat and clean. > > > > > > > > In 11.2 there is this rather complicated setup that's getting hard to > > > > untangle. > > > > > > > > So, following the spirit of the JavaFX plugins we use the same '3rd > > > > party' *meta* update center which is just an XML generated at build > > > > time together with the hollow NBMs. > > > > > > > > The magic of these NBMs is that we use .external files for the real > > > > GPL w/ CPE meat of things and these files have an URL pointing to > > > > something like netbeans.osuosl.org . > > > > > > > > Now, I'm trying to just include nb-javac at build time and don't need > > > > all this complicated mechanism. Is it something obvious I'm missing > > > > about how to do it? > > > > > > > > I see that although we have java/libs.javacimpl the external JAR is > > > > *not* copied to modules/ext. This seems like a 'standard' approach. > > > > > > > > But it seems I still need the modules in nb/updatecenters/extras such > > > > as nbjavac.impl, most likely for something magic like > > > > OpenIDE-Module-Provides: org.netbeans.modules.nbjavac In which case > > > > nbjavac.impl probably just needs to depend on libs.javacimpl? > > > > > > > > I'll look some more about how this used to work in 8.2 or something. > > > > > > > > The current mechanism is quite something. Bundling NBMs and UCs inside > > > > the updatecenters.jar just so we can grab at runtime the magic JAR via > > > > the URL in the .external file? Wowee. > > > > > > > > --emi > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > > > > > For further information about the NetBeans mailing lists, visit: > > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
