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...@gmail.com> on 2019/11/24 23:15:07 UTC
Figuring out nbjavac in 11.2 is a doozy
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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Jan Lahoda <la...@gmail.com>.
On Wed, Nov 27, 2019 at 10:23 PM Neil C Smith <ne...@apache.org> wrote:
> On Wed, 27 Nov 2019 at 20:13, Emilian Bold <em...@gmail.com> wrote:
> > An exe installer would be a derivative work imho even if it bundles
> > the same bits.
> >
> > Calling that installer NetBeans based on nominative fair user seems an
> > interesting angle.
>
> I think it's a major stretch to call the installer derivative. It's a
> separate piece of software to package the IDE. And if the IDE that it
> packages is the same as upstream, then it's not a derivative.
>
> Now, the installer itself shouldn't be just called Apache NetBeans if
> it is not developed here, but note I actually suggested use of "XXX
> installer for Apache NetBeans and OpenJDK" (or "OpenBeans installer
> for Apache NetBeans and OpenJDK"!)
>
> That seems perfectly within the scope of the permissions. In fact,
> was considering building one myself.
>
I'd even say the installer *can* be developed here, our source code can
contain a script that will build it, and if the installer is built using
that script, without custom patches, then the draft policy allows it to be
called Apache NetBeans (as, frankly, it would be something we have done.)
Jan
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 27 Nov 2019 at 20:13, Emilian Bold <em...@gmail.com> wrote:
> An exe installer would be a derivative work imho even if it bundles
> the same bits.
>
> Calling that installer NetBeans based on nominative fair user seems an
> interesting angle.
I think it's a major stretch to call the installer derivative. It's a
separate piece of software to package the IDE. And if the IDE that it
packages is the same as upstream, then it's not a derivative.
Now, the installer itself shouldn't be just called Apache NetBeans if
it is not developed here, but note I actually suggested use of "XXX
installer for Apache NetBeans and OpenJDK" (or "OpenBeans installer
for Apache NetBeans and OpenJDK"!)
That seems perfectly within the scope of the permissions. In fact,
was considering building one myself.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Emilian Bold <em...@gmail.com>.
> However, we can certainly have build scripts that have optional flags
> that allow anyone building from the source release to include either
> of those things for themselves. That's no different to providing the
> option for a binary consumer to install at runtime. And means we
> don't all have to keep reinventing the wheel.
Sure, and I already said I would love something like that. My patch is
already done though, has 70 lines, just changes a few files.
Re-doing this as a proper build system addition seems like another
thing altogether. NetBeans never did have build flags like this. I
guess it's not that hard to append to libs.javacapi/manifest.mf (or to
have a 2nd manifest.mf for the flag) but this seems a crude solution.
> You're looking at the wrong thing - that's about derivatives, not
> distributing NetBeans itself. Check out the first example of
> nominative fair use here and tell me that doesn't cover what you're
> talking about doing!
>
> http://www.apache.org/foundation/marks/#guidelines
An exe installer would be a derivative work imho even if it bundles
the same bits.
Calling that installer NetBeans based on nominative fair user seems an
interesting angle.
--emi
On Wed, Nov 27, 2019 at 8:12 PM Neil C Smith <ne...@apache.org> wrote:
>
> On Wed, 27 Nov 2019 at 17:30, Emilian Bold <em...@gmail.com> wrote:
> > I don't see what I'm doing as splitting the effort. If anything it's
> > complementary. Can NetBeans bundle a JDK? Can it bundle nbjavac?
>
> Depends what you mean! Can we bundle either in our binaries - at the
> moment, no, although there is still an open legal question on some of
> this.
>
> However, we can certainly have build scripts that have optional flags
> that allow anyone building from the source release to include either
> of those things for themselves. That's no different to providing the
> option for a binary consumer to install at runtime. And means we
> don't all have to keep reinventing the wheel.
>
> > Looking at stuff like
> > http://www.apache.org/foundation/marks/faq/#products they are clear
> > that I cannot use the Apache marks.
>
> You're looking at the wrong thing - that's about derivatives, not
> distributing NetBeans itself. Check out the first example of
> nominative fair use here and tell me that doesn't cover what you're
> talking about doing!
>
> http://www.apache.org/foundation/marks/#guidelines
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 27 Nov 2019 at 17:30, Emilian Bold <em...@gmail.com> wrote:
> I don't see what I'm doing as splitting the effort. If anything it's
> complementary. Can NetBeans bundle a JDK? Can it bundle nbjavac?
Depends what you mean! Can we bundle either in our binaries - at the
moment, no, although there is still an open legal question on some of
this.
However, we can certainly have build scripts that have optional flags
that allow anyone building from the source release to include either
of those things for themselves. That's no different to providing the
option for a binary consumer to install at runtime. And means we
don't all have to keep reinventing the wheel.
> Looking at stuff like
> http://www.apache.org/foundation/marks/faq/#products they are clear
> that I cannot use the Apache marks.
You're looking at the wrong thing - that's about derivatives, not
distributing NetBeans itself. Check out the first example of
nominative fair use here and tell me that doesn't cover what you're
talking about doing!
http://www.apache.org/foundation/marks/#guidelines
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Emilian Bold <em...@gmail.com>.
> > 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.
>
> I think that was meant that you doing it separately is splitting the
> effort! Ideally something to solve here.
I don't see what I'm doing as splitting the effort. If anything it's
complementary. Can NetBeans bundle a JDK? Can it bundle nbjavac?
Some of the other features could also be in NetBeans, but I didn't
manage to put them in last time when I was a committer and PMC member.
Maybe someday they will be reimplemented by the right person and I can
drop my variant.
> > 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.
>
> I wonder if the old extra cluster mechanism, as JavaFX is (was?)
> doing, is easier in this respect? Some of this was discussed in
> https://github.com/apache/netbeans/pull/1560 if you haven't read that?
I guess? But not by much. The current patch is just fine I think and I
have everything in java/libs.javacimpl / ~-api.
> > 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.
>
> Really?! IMO that's something we've said multiple times we would
> allow, including in a recent thread (when Debian, etc. came up).
Like many other threads, the most recent one got into many areas but
I'm not sure I saw a clear cut conclusion. I expressly asked about the
installer then went into CoolBeans and Debian and more and come back
head spinning.
https://lists.apache.org/thread.html/4075e5bc05d4d5f4eb51ced4e99dfb03847d16b337259bce593a38d4@%3Cdev.netbeans.apache.org%3E
The one conclusion was that NetBeans has no specific stance besides
what ASF has.
Looking at stuff like
http://www.apache.org/foundation/marks/faq/#products they are clear
that I cannot use the Apache marks.
Apache seems to officially not allow their marks being used but in
practice allow it (for Linux distros, etc). So, it would be nice to
see this black on white. Jan's link
http://www.apache.org/foundation/marks/downstream.html with a more
recent draft seems a step in the right direction. Hopefully it stops
being a draft and actual ASF policy.
--emi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 27 Nov 2019 at 08:26, Emilian Bold <em...@gmail.com> wrote:
> 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.
I think that was meant that you doing it separately is splitting the
effort! Ideally something to solve here.
> 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.
I wonder if the old extra cluster mechanism, as JavaFX is (was?)
doing, is easier in this respect? Some of this was discussed in
https://github.com/apache/netbeans/pull/1560 if you haven't read that?
> 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.
Really?! IMO that's something we've said multiple times we would
allow, including in a recent thread (when Debian, etc. came up).
Presumably the installer itself would need to be called something like
"XXX installer for Apache NetBeans and JDK", but as long as what it
installs is our binary release or built from our source release,
what's the problem?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Emilian Bold <em...@gmail.com>.
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 <la...@gmail.com> wrote:
>
> On Mon, Nov 25, 2019 at 8:18 PM Emilian Bold <em...@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-B33538864504@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 <la...@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 <em...@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-unsubscribe@netbeans.apache.org
> > > > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Jan Lahoda <la...@gmail.com>.
On Mon, Nov 25, 2019 at 8:18 PM Emilian Bold <em...@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-B33538864504@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 <la...@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 <em...@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-unsubscribe@netbeans.apache.org
> > > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Emilian Bold <em...@gmail.com>.
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 <la...@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 <em...@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-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Ernie Rael <er...@raelity.com>.
On 11/24/2019 11:32 PM, Jan Lahoda 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),
I also like the idea of sharing plugins over versions. At some point it
seems like it will be necessary to have a way to provide a new plugin,
e.g. for plugin XYZZY 11.0 and 11.2 versions are not the same. One way,
somewhat kludgy, would be to make a clone of the portal for a new
version and allow plugins to be individually added/replaced on an as
need basis. Depending on the capabilities/features of the new portal
different techniques (or kludges) might be available.
> 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 <em...@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-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Ernie Rael <er...@raelity.com>.
On 11/25/2019 1:39 AM, Neil C Smith wrote:
>
> On Mon, 25 Nov 2019 at 08:17, Ernie Rael <er...@raelity.com> wrote:
>> On 11/24/2019 11:32 PM, Jan Lahoda wrote:
>>> -there is only a single Plugin Portal for all NetBeans 11.0, 11.1 and 11.2;
>>> ....
>> One way,
>> somewhat kludgy, would be to make a clone of the portal for a new
>> version and allow plugins to be individually added/replaced on an as
>> need basis.
> Each version of the IDE has its own plugin portal URL already. It is
> purely a quirk of the current legacy infrastructure that the same
> plugin catalog is served to each. The portal will be replaced soon,
> and AFAIK serving different catalogs to different IDE versions will no
> longer be an issue - at least I hope that issue is solved in it?!
Agree. And (somewhat off topic) I'm suggesting might want to populate a
new catalog, with the previous catalogue (at least for minor releases).
This would address the concern (valid I believe) that Jan brought up
unless we want to force everyone to upload their plugins to a new
portal every 3 months
The new apache portal could have this same problem. I don't know what
the plan about release frequency is like, is it still going to target
every 3 months?
-ernie
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Neil C Smith <ne...@apache.org>.
On Mon, 25 Nov 2019 at 07:33, Jan Lahoda <la...@gmail.com> wrote:
> 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).
I will also need to solve this problem for PraxisLIVE, so definitely
motivated to contribute here. As I said when we merged this, though,
I think we need a build flag to include the nb-javac and/or JavaFX
modules. There is no reason someone building from our sources needs
to be restricted by our binary distribution restrictions.
Derivatives, distributions and corporate/education deployments could
all benefit here.
This was potentially easier with the older extra cluster use?
On Mon, 25 Nov 2019 at 08:17, Ernie Rael <er...@raelity.com> wrote:
> On 11/24/2019 11:32 PM, Jan Lahoda wrote:
> > -there is only a single Plugin Portal for all NetBeans 11.0, 11.1 and 11.2;
> > ....
> One way,
> somewhat kludgy, would be to make a clone of the portal for a new
> version and allow plugins to be individually added/replaced on an as
> need basis.
Each version of the IDE has its own plugin portal URL already. It is
purely a quirk of the current legacy infrastructure that the same
plugin catalog is served to each. The portal will be replaced soon,
and AFAIK serving different catalogs to different IDE versions will no
longer be an issue - at least I hope that issue is solved in it?!
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Emilian Bold <em...@gmail.com>.
I know Jan that the current solution is based on the license
restrictions Apache landed on us. It's actually a very neat solution
but it's getting hard to follow up and harder to untangle. For
OpenBeans I just want to include everything out of the box so the IDE
works entirely offline, if needed, with no missing pieces. While
including nb-javac was rather trivial before 11.2 now it's become the
major roadblock.
I suspect the solution is to see how things were done in 8.2 and patch
the codebase that way. That means fix java/libs.javacimpl and see how
extras/nbjavac.impl fits in all that (perhaps by adding some friend
dependencies, not sure).
Ideally it would be great to have a patch for NetBeans proper too so a
single flag does all this but I suspect it will multiply the effort
many times. So far I have to figure out how it can be done... then see
which way to patch what.
--emi
On Mon, Nov 25, 2019 at 9:33 AM Jan Lahoda <la...@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 <em...@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-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Figuring out nbjavac in 11.2 is a doozy
Posted by Jan Lahoda <la...@gmail.com>.
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 <em...@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>