Jan, I'm curious if this patch makes sense to you: https://github.com/OpenBeans/OpenBeans/commit/ec4bfe3db429abd8830d750f8bc5dcc14285db37#diff-03465d6aba3fa54304c800a82884a4b9R31
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 <[email protected]> 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 <[email protected]> > 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
