You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Michael Bien <mb...@gmail.com> on 2021/11/10 18:42:34 UTC
13+17
Hello,
I got encouraged by Neil to start a new thread - its not my fault.
current status:
JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
Building NB on JDK 17 involves most likely just a few property bumps and
library updates. I could make the java cluster build just by doing that
and by updating the build-time gradle wrapper.
(https://github.com/apache/netbeans/pull/3278)
I can't actually update the gradle wrapper myself (outside of making it
point to a local zip for testing purposes) because i am not familiar
with the lib hosting service the NB build uses - that is why its not
part of the PR - someone else would have to do that (why can't it just
use a maven repo?).
That would be the easy part, testing on JDK 16+ is going to be more
interesting, since NetBeans appears to hook into a very old version of
osgi (3.9 via the netbinox module and friends as far as i see, which
doesn't even officially support JDK8 btw). There need to be also some
updates to junit JVM flags and build configs, but i have those in my
stash and it isn't really worth mentioning, beside that its all over the
place as to be expected in a big project. Using JDK 16 as a intermediate
step before progressing to 17, might help there since the module system
of 17 became more restrictive on top of all that.
If NetBeans 13 would like to claim to support JDK 17 i would recommend
to start with some of this early in the development cycle, esp with the
low hanging fruits (gradle wrapper, which unblocks the
build-java-cluster-on-17 PR etc).
best regards,
michael
---------------------------------------------------------------------
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: 13+17
Posted by Eric Bresie <eb...@gmail.com>.
Not sure if this helps further (this was written prior to JDK 17 but has
links to other "depricated/removed" APIs which may also be related
https://issues.apache.org/jira/browse/NETBEANS-5349
Eric Bresie
ebresie@gmail.com
On Thu, Dec 30, 2021 at 9:09 AM Michael Bien <mb...@gmail.com> wrote:
> I don't want to leave this old thread open without a status report:
>
> whats left:
> - JDK 17 doesn't have the javascript runtime
>
Assume this is related to
https://issues.apache.org/jira/browse/NETBEANS-4168 Handling Nashorn
Removal inline with JDK 15
(see links in comments for possible migration guidance)
Not sure if this will show up or if this has already been fixed (and not
closed out) but does this also account for removal of some of the XML
functionality likeNETBEANS-1866
<https://issues.apache.org/jira/browse/NETBEANS-1866> Netbean XML
Compilation Issues JDK 11?
-michael
>
>
> On 10.11.21 19:42, Michael Bien wrote:
> > Hello,
> >
> > I got encouraged by Neil to start a new thread - its not my fault.
> >
> > current status:
> >
> > JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
> >
> >
> > Building NB on JDK 17 involves most likely just a few property bumps
> > and library updates. I could make the java cluster build just by doing
> > that and by updating the build-time gradle wrapper.
> > (https://github.com/apache/netbeans/pull/3278)
> >
> > I can't actually update the gradle wrapper myself (outside of making
> > it point to a local zip for testing purposes) because i am not
> > familiar with the lib hosting service the NB build uses - that is why
> > its not part of the PR - someone else would have to do that (why can't
> > it just use a maven repo?).
> >
> >
> > That would be the easy part, testing on JDK 16+ is going to be more
> > interesting, since NetBeans appears to hook into a very old version of
> > osgi (3.9 via the netbinox module and friends as far as i see, which
> > doesn't even officially support JDK8 btw). There need to be also some
> > updates to junit JVM flags and build configs, but i have those in my
> > stash and it isn't really worth mentioning, beside that its all over
> > the place as to be expected in a big project. Using JDK 16 as a
> > intermediate step before progressing to 17, might help there since the
> > module system of 17 became more restrictive on top of all that.
> >
> >
> > If NetBeans 13 would like to claim to support JDK 17 i would recommend
> > to start with some of this early in the development cycle, esp with
> > the low hanging fruits (gradle wrapper, which unblocks the
> > build-java-cluster-on-17 PR etc).
> >
> > best regards,
> >
> > michael
> >
>
>
> ---------------------------------------------------------------------
> 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: 13+17
Posted by Michael Bien <mb...@gmail.com>.
I don't want to leave this old thread open without a status report:
- gradle module is up2date and is now pulling the files from the
official gradle server thanks to Laszlo and Matthias
-> https://github.com/apache/netbeans/pull/3326
- Java cluster is buildable on JDK 17
-> https://github.com/apache/netbeans/pull/3278
-> https://github.com/apache/netbeans/pull/3372
- nb-javac is pulled from maven and included by default, which makes
javac 17 the new baseline if i see this correctly
-> https://github.com/apache/netbeans/pull/3251
-> https://github.com/apache/netbeans/pull/2783
whats left:
- a lot of tests won't work without solving the OSGI issue (I suppose
"netbinox" isn't relevant at runtime otherwise we would have noticed it
by now while running on JDK 17)
- JDK 17 doesn't have the javascript runtime
- "Replacing SecurityManager with a tracking agent" sounds super
interesting for JDK 17+
-> https://github.com/apache/netbeans/pull/3386
good job everyone!
-michael
On 10.11.21 19:42, Michael Bien wrote:
> Hello,
>
> I got encouraged by Neil to start a new thread - its not my fault.
>
> current status:
>
> JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
>
>
> Building NB on JDK 17 involves most likely just a few property bumps
> and library updates. I could make the java cluster build just by doing
> that and by updating the build-time gradle wrapper.
> (https://github.com/apache/netbeans/pull/3278)
>
> I can't actually update the gradle wrapper myself (outside of making
> it point to a local zip for testing purposes) because i am not
> familiar with the lib hosting service the NB build uses - that is why
> its not part of the PR - someone else would have to do that (why can't
> it just use a maven repo?).
>
>
> That would be the easy part, testing on JDK 16+ is going to be more
> interesting, since NetBeans appears to hook into a very old version of
> osgi (3.9 via the netbinox module and friends as far as i see, which
> doesn't even officially support JDK8 btw). There need to be also some
> updates to junit JVM flags and build configs, but i have those in my
> stash and it isn't really worth mentioning, beside that its all over
> the place as to be expected in a big project. Using JDK 16 as a
> intermediate step before progressing to 17, might help there since the
> module system of 17 became more restrictive on top of all that.
>
>
> If NetBeans 13 would like to claim to support JDK 17 i would recommend
> to start with some of this early in the development cycle, esp with
> the low hanging fruits (gradle wrapper, which unblocks the
> build-java-cluster-on-17 PR etc).
>
> best regards,
>
> michael
>
---------------------------------------------------------------------
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: 13+17
Posted by Michael Bien <mb...@gmail.com>.
excellent!
On 12.11.21 18:34, Laszlo Kishalmi wrote:
> I think no one likes to mirror anything on OSUOSL.
>
> (However Oregon State University in Corvallis, Oregon is a really nice
> place. Just passed through a few times...)
>
> I've started a conversation with Gradle people:
> https://github.com/gradle/gradle/issues/18951
>
>
> On 11/12/21 03:42, Michael Bien wrote:
>> would someone like to mirror gradle-7.3-bin.zip and
>> gradle-wrapper-7.3.jar on OSUOSL?
>>
>> The wrapper is actually in the zip too, I could take a look if the
>> build could be changed to use the wrapper from there instead of
>> downloading a different version again. The build deals now with three
>> different versions of gradle libraries - this does not have to be the
>> case.
>>
>> 7.3 is still compatible with JDK 8 in case anyone is wondering.
>>
>> thanks!
>>
>> On 11.11.21 16:24, Michael Bien wrote:
>>> Thanks Tim, that is useful to know.
>>>
>>> however, gradle-tooling-api-7.3.jar has just been updated yesterday
>>> in "OSUOSL".
>>>
>>> https://github.com/apache/netbeans/pull/3313
>>> https://netbeans.osuosl.org/binaries/?C=M;O=D
>>>
>>> what i was asking is to do the same for gradle-7.3-bin.zip and
>>> gradle-wrapper-X.XX.X.jar, to have all compatible gradle libs of the
>>> same version available.
>>> https://github.com/apache/netbeans/blob/master/extide/gradle/external/binaries-list
>>>
>>>
>>> As i mentioned, I don't have access to the oregon university, so i
>>> can't actually do this.
>>>
>>> If there would be maven coords for all required artifacts, we should
>>> probably switch all at once, I wouldn't want the netbeans build to
>>> download gradle from several places if its somehow avoidable.
>>>
>>> best regards,
>>> michael
>>>
>>>
>>> On 11.11.21 01:16, Tim Boudreau wrote:
>>>> FWIW, today locally I added a dep from the profile to an atomic bit
>>>> set
>>>> library I wrote Tara in maven central.
>>>>
>>>> Just add the maven coordinates and hash (upper case for some
>>>> reason) to
>>>> external/binaries-list.
>>>>
>>>> Have a look at the groovy modules for the format - it’s pretty
>>>> self-explanatory.
>>>>
>>>> I don’t know if there’s some further process for getting a new dep
>>>> into a
>>>> release, but that will get you going.
>>>>
>>>> -Tim
>>>>
>>>> On Wed, Nov 10, 2021 at 4:57 PM Laszlo Kishalmi
>>>> <la...@gmail.com>
>>>> wrote:
>>>>
>>>>> Well that would be nice if we can download Gradle binaries from their
>>>>> repository.
>>>>>
>>>>> I try to recall what was the issue we needed to upload those
>>>>> binaries to
>>>>> OSUOSL.
>>>>>
>>>>> If there is no legal problem to add Gradle's artifact repository
>>>>> to our
>>>>> build, it would be really easy to move on.
>>>>>
>>>>> On 11/10/21 10:42, Michael Bien wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I got encouraged by Neil to start a new thread - its not my fault.
>>>>>>
>>>>>> current status:
>>>>>>
>>>>>> JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested
>>>>>> on.
>>>>>>
>>>>>>
>>>>>> Building NB on JDK 17 involves most likely just a few property bumps
>>>>>> and library updates. I could make the java cluster build just by
>>>>>> doing
>>>>>> that and by updating the build-time gradle wrapper.
>>>>>> (https://github.com/apache/netbeans/pull/3278)
>>>>>>
>>>>>> I can't actually update the gradle wrapper myself (outside of making
>>>>>> it point to a local zip for testing purposes) because i am not
>>>>>> familiar with the lib hosting service the NB build uses - that is
>>>>>> why
>>>>>> its not part of the PR - someone else would have to do that (why
>>>>>> can't
>>>>>> it just use a maven repo?).
>>>>>>
>>>>>>
>>>>>> That would be the easy part, testing on JDK 16+ is going to be more
>>>>>> interesting, since NetBeans appears to hook into a very old
>>>>>> version of
>>>>>> osgi (3.9 via the netbinox module and friends as far as i see, which
>>>>>> doesn't even officially support JDK8 btw). There need to be also
>>>>>> some
>>>>>> updates to junit JVM flags and build configs, but i have those in my
>>>>>> stash and it isn't really worth mentioning, beside that its all over
>>>>>> the place as to be expected in a big project. Using JDK 16 as a
>>>>>> intermediate step before progressing to 17, might help there
>>>>>> since the
>>>>>> module system of 17 became more restrictive on top of all that.
>>>>>>
>>>>>>
>>>>>> If NetBeans 13 would like to claim to support JDK 17 i would
>>>>>> recommend
>>>>>> to start with some of this early in the development cycle, esp with
>>>>>> the low hanging fruits (gradle wrapper, which unblocks the
>>>>>> build-java-cluster-on-17 PR etc).
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> michael
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>> http://timboudreau.com
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: 13+17
Posted by Laszlo Kishalmi <la...@gmail.com>.
I think no one likes to mirror anything on OSUOSL.
(However Oregon State University in Corvallis, Oregon is a really nice
place. Just passed through a few times...)
I've started a conversation with Gradle people:
https://github.com/gradle/gradle/issues/18951
On 11/12/21 03:42, Michael Bien wrote:
> would someone like to mirror gradle-7.3-bin.zip and
> gradle-wrapper-7.3.jar on OSUOSL?
>
> The wrapper is actually in the zip too, I could take a look if the
> build could be changed to use the wrapper from there instead of
> downloading a different version again. The build deals now with three
> different versions of gradle libraries - this does not have to be the
> case.
>
> 7.3 is still compatible with JDK 8 in case anyone is wondering.
>
> thanks!
>
> On 11.11.21 16:24, Michael Bien wrote:
>> Thanks Tim, that is useful to know.
>>
>> however, gradle-tooling-api-7.3.jar has just been updated yesterday
>> in "OSUOSL".
>>
>> https://github.com/apache/netbeans/pull/3313
>> https://netbeans.osuosl.org/binaries/?C=M;O=D
>>
>> what i was asking is to do the same for gradle-7.3-bin.zip and
>> gradle-wrapper-X.XX.X.jar, to have all compatible gradle libs of the
>> same version available.
>> https://github.com/apache/netbeans/blob/master/extide/gradle/external/binaries-list
>>
>>
>> As i mentioned, I don't have access to the oregon university, so i
>> can't actually do this.
>>
>> If there would be maven coords for all required artifacts, we should
>> probably switch all at once, I wouldn't want the netbeans build to
>> download gradle from several places if its somehow avoidable.
>>
>> best regards,
>> michael
>>
>>
>> On 11.11.21 01:16, Tim Boudreau wrote:
>>> FWIW, today locally I added a dep from the profile to an atomic bit set
>>> library I wrote Tara in maven central.
>>>
>>> Just add the maven coordinates and hash (upper case for some reason) to
>>> external/binaries-list.
>>>
>>> Have a look at the groovy modules for the format - it’s pretty
>>> self-explanatory.
>>>
>>> I don’t know if there’s some further process for getting a new dep
>>> into a
>>> release, but that will get you going.
>>>
>>> -Tim
>>>
>>> On Wed, Nov 10, 2021 at 4:57 PM Laszlo Kishalmi
>>> <la...@gmail.com>
>>> wrote:
>>>
>>>> Well that would be nice if we can download Gradle binaries from their
>>>> repository.
>>>>
>>>> I try to recall what was the issue we needed to upload those
>>>> binaries to
>>>> OSUOSL.
>>>>
>>>> If there is no legal problem to add Gradle's artifact repository to
>>>> our
>>>> build, it would be really easy to move on.
>>>>
>>>> On 11/10/21 10:42, Michael Bien wrote:
>>>>> Hello,
>>>>>
>>>>> I got encouraged by Neil to start a new thread - its not my fault.
>>>>>
>>>>> current status:
>>>>>
>>>>> JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
>>>>>
>>>>>
>>>>> Building NB on JDK 17 involves most likely just a few property bumps
>>>>> and library updates. I could make the java cluster build just by
>>>>> doing
>>>>> that and by updating the build-time gradle wrapper.
>>>>> (https://github.com/apache/netbeans/pull/3278)
>>>>>
>>>>> I can't actually update the gradle wrapper myself (outside of making
>>>>> it point to a local zip for testing purposes) because i am not
>>>>> familiar with the lib hosting service the NB build uses - that is why
>>>>> its not part of the PR - someone else would have to do that (why
>>>>> can't
>>>>> it just use a maven repo?).
>>>>>
>>>>>
>>>>> That would be the easy part, testing on JDK 16+ is going to be more
>>>>> interesting, since NetBeans appears to hook into a very old
>>>>> version of
>>>>> osgi (3.9 via the netbinox module and friends as far as i see, which
>>>>> doesn't even officially support JDK8 btw). There need to be also some
>>>>> updates to junit JVM flags and build configs, but i have those in my
>>>>> stash and it isn't really worth mentioning, beside that its all over
>>>>> the place as to be expected in a big project. Using JDK 16 as a
>>>>> intermediate step before progressing to 17, might help there since
>>>>> the
>>>>> module system of 17 became more restrictive on top of all that.
>>>>>
>>>>>
>>>>> If NetBeans 13 would like to claim to support JDK 17 i would
>>>>> recommend
>>>>> to start with some of this early in the development cycle, esp with
>>>>> the low hanging fruits (gradle wrapper, which unblocks the
>>>>> build-java-cluster-on-17 PR etc).
>>>>>
>>>>> best regards,
>>>>>
>>>>> michael
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>> http://timboudreau.com
>>>
>>
>
>
> ---------------------------------------------------------------------
> 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: 13+17
Posted by Michael Bien <mb...@gmail.com>.
would someone like to mirror gradle-7.3-bin.zip and
gradle-wrapper-7.3.jar on OSUOSL?
The wrapper is actually in the zip too, I could take a look if the build
could be changed to use the wrapper from there instead of downloading a
different version again. The build deals now with three different
versions of gradle libraries - this does not have to be the case.
7.3 is still compatible with JDK 8 in case anyone is wondering.
thanks!
On 11.11.21 16:24, Michael Bien wrote:
> Thanks Tim, that is useful to know.
>
> however, gradle-tooling-api-7.3.jar has just been updated yesterday in
> "OSUOSL".
>
> https://github.com/apache/netbeans/pull/3313
> https://netbeans.osuosl.org/binaries/?C=M;O=D
>
> what i was asking is to do the same for gradle-7.3-bin.zip and
> gradle-wrapper-X.XX.X.jar, to have all compatible gradle libs of the
> same version available.
> https://github.com/apache/netbeans/blob/master/extide/gradle/external/binaries-list
>
>
> As i mentioned, I don't have access to the oregon university, so i
> can't actually do this.
>
> If there would be maven coords for all required artifacts, we should
> probably switch all at once, I wouldn't want the netbeans build to
> download gradle from several places if its somehow avoidable.
>
> best regards,
> michael
>
>
> On 11.11.21 01:16, Tim Boudreau wrote:
>> FWIW, today locally I added a dep from the profile to an atomic bit set
>> library I wrote Tara in maven central.
>>
>> Just add the maven coordinates and hash (upper case for some reason) to
>> external/binaries-list.
>>
>> Have a look at the groovy modules for the format - it’s pretty
>> self-explanatory.
>>
>> I don’t know if there’s some further process for getting a new dep
>> into a
>> release, but that will get you going.
>>
>> -Tim
>>
>> On Wed, Nov 10, 2021 at 4:57 PM Laszlo Kishalmi
>> <la...@gmail.com>
>> wrote:
>>
>>> Well that would be nice if we can download Gradle binaries from their
>>> repository.
>>>
>>> I try to recall what was the issue we needed to upload those
>>> binaries to
>>> OSUOSL.
>>>
>>> If there is no legal problem to add Gradle's artifact repository to our
>>> build, it would be really easy to move on.
>>>
>>> On 11/10/21 10:42, Michael Bien wrote:
>>>> Hello,
>>>>
>>>> I got encouraged by Neil to start a new thread - its not my fault.
>>>>
>>>> current status:
>>>>
>>>> JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
>>>>
>>>>
>>>> Building NB on JDK 17 involves most likely just a few property bumps
>>>> and library updates. I could make the java cluster build just by doing
>>>> that and by updating the build-time gradle wrapper.
>>>> (https://github.com/apache/netbeans/pull/3278)
>>>>
>>>> I can't actually update the gradle wrapper myself (outside of making
>>>> it point to a local zip for testing purposes) because i am not
>>>> familiar with the lib hosting service the NB build uses - that is why
>>>> its not part of the PR - someone else would have to do that (why can't
>>>> it just use a maven repo?).
>>>>
>>>>
>>>> That would be the easy part, testing on JDK 16+ is going to be more
>>>> interesting, since NetBeans appears to hook into a very old version of
>>>> osgi (3.9 via the netbinox module and friends as far as i see, which
>>>> doesn't even officially support JDK8 btw). There need to be also some
>>>> updates to junit JVM flags and build configs, but i have those in my
>>>> stash and it isn't really worth mentioning, beside that its all over
>>>> the place as to be expected in a big project. Using JDK 16 as a
>>>> intermediate step before progressing to 17, might help there since the
>>>> module system of 17 became more restrictive on top of all that.
>>>>
>>>>
>>>> If NetBeans 13 would like to claim to support JDK 17 i would recommend
>>>> to start with some of this early in the development cycle, esp with
>>>> the low hanging fruits (gradle wrapper, which unblocks the
>>>> build-java-cluster-on-17 PR etc).
>>>>
>>>> best regards,
>>>>
>>>> michael
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>> --
>> http://timboudreau.com
>>
>
---------------------------------------------------------------------
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: 13+17
Posted by Michael Bien <mb...@gmail.com>.
Thanks Tim, that is useful to know.
however, gradle-tooling-api-7.3.jar has just been updated yesterday in
"OSUOSL".
https://github.com/apache/netbeans/pull/3313
https://netbeans.osuosl.org/binaries/?C=M;O=D
what i was asking is to do the same for gradle-7.3-bin.zip and
gradle-wrapper-X.XX.X.jar, to have all compatible gradle libs of the
same version available.
https://github.com/apache/netbeans/blob/master/extide/gradle/external/binaries-list
As i mentioned, I don't have access to the oregon university, so i can't
actually do this.
If there would be maven coords for all required artifacts, we should
probably switch all at once, I wouldn't want the netbeans build to
download gradle from several places if its somehow avoidable.
best regards,
michael
On 11.11.21 01:16, Tim Boudreau wrote:
> FWIW, today locally I added a dep from the profile to an atomic bit set
> library I wrote Tara in maven central.
>
> Just add the maven coordinates and hash (upper case for some reason) to
> external/binaries-list.
>
> Have a look at the groovy modules for the format - it’s pretty
> self-explanatory.
>
> I don’t know if there’s some further process for getting a new dep into a
> release, but that will get you going.
>
> -Tim
>
> On Wed, Nov 10, 2021 at 4:57 PM Laszlo Kishalmi <la...@gmail.com>
> wrote:
>
>> Well that would be nice if we can download Gradle binaries from their
>> repository.
>>
>> I try to recall what was the issue we needed to upload those binaries to
>> OSUOSL.
>>
>> If there is no legal problem to add Gradle's artifact repository to our
>> build, it would be really easy to move on.
>>
>> On 11/10/21 10:42, Michael Bien wrote:
>>> Hello,
>>>
>>> I got encouraged by Neil to start a new thread - its not my fault.
>>>
>>> current status:
>>>
>>> JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
>>>
>>>
>>> Building NB on JDK 17 involves most likely just a few property bumps
>>> and library updates. I could make the java cluster build just by doing
>>> that and by updating the build-time gradle wrapper.
>>> (https://github.com/apache/netbeans/pull/3278)
>>>
>>> I can't actually update the gradle wrapper myself (outside of making
>>> it point to a local zip for testing purposes) because i am not
>>> familiar with the lib hosting service the NB build uses - that is why
>>> its not part of the PR - someone else would have to do that (why can't
>>> it just use a maven repo?).
>>>
>>>
>>> That would be the easy part, testing on JDK 16+ is going to be more
>>> interesting, since NetBeans appears to hook into a very old version of
>>> osgi (3.9 via the netbinox module and friends as far as i see, which
>>> doesn't even officially support JDK8 btw). There need to be also some
>>> updates to junit JVM flags and build configs, but i have those in my
>>> stash and it isn't really worth mentioning, beside that its all over
>>> the place as to be expected in a big project. Using JDK 16 as a
>>> intermediate step before progressing to 17, might help there since the
>>> module system of 17 became more restrictive on top of all that.
>>>
>>>
>>> If NetBeans 13 would like to claim to support JDK 17 i would recommend
>>> to start with some of this early in the development cycle, esp with
>>> the low hanging fruits (gradle wrapper, which unblocks the
>>> build-java-cluster-on-17 PR etc).
>>>
>>> best regards,
>>>
>>> michael
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>> --
> http://timboudreau.com
>
---------------------------------------------------------------------
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: 13+17 (Nashorn Removal)
Posted by Eric Bresie <eb...@gmail.com>.
Since discussing JDK 17 concerns..
$ java --version
openjdk 17 2021-09-14
OpenJDK Runtime Environment Temurin-17+35 (build 17+35)
OpenJDK 64-Bit Server VM Temurin-17+35 (build 17+35, mixed mode, sharing)
Pulled down the latest from master
$ ant -Dcluster.config=full
prepare-vanilla-javac:
[mkdir] Created dir: C:\git\nb.latest\netbeans\nbbuild\build\langtools
[unzip] Expanding:
C:\git\nb.latest\netbeans\nbbuild\external\langtools-9.zip into
C:\git\nb.latest\netbeans\nbbuild\build\langtools
Java 15 has removed Nashorn, you must provide an engine for running
JavaScript yourself. GraalVM JavaScript currently is the preferred option.
Assume this involves different imports/dependencies changes but figured I
would bring it up as well. Maybe related to NETBEANS-4168
<https://issues.apache.org/jira/browse/NETBEANS-4168> Handling Nashorn
Removal inline with JDK 15
Eric Bresie
ebresie@gmail.com
On Thu, Nov 11, 2021 at 3:43 AM Neil C Smith <ne...@apache.org> wrote:
> On Thu, 11 Nov 2021 at 07:44, Laszlo Kishalmi <la...@gmail.com>
> wrote:
> > It's not about the how. It's about from where (legal).
> >
> > I've already implemented to be able to use multiple maven repositories
> > in the build. But legally can we?
>
> Isn't sufficient support for multiple repositories already
> implemented? I add local repository for development purposes, but
> should work with remote already.
>
> What's the legal question here in your mind? Surely a security
> question if anything, but as we're validating hashes of all externals
> ...
>
> Reducing and removing our reliance on OSUOSL uploads is a good thing
> in my opinion.
>
> 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: 13+17
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 11 Nov 2021 at 07:44, Laszlo Kishalmi <la...@gmail.com> wrote:
> It's not about the how. It's about from where (legal).
>
> I've already implemented to be able to use multiple maven repositories
> in the build. But legally can we?
Isn't sufficient support for multiple repositories already
implemented? I add local repository for development purposes, but
should work with remote already.
What's the legal question here in your mind? Surely a security
question if anything, but as we're validating hashes of all externals
...
Reducing and removing our reliance on OSUOSL uploads is a good thing
in my opinion.
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: 13+17
Posted by Jan Lahoda <la...@gmail.com>.
Hi,
On Thu, Nov 11, 2021 at 8:44 AM Laszlo Kishalmi <la...@gmail.com>
wrote:
> It's not about the how. It's about from where (legal).
>
(As Neil), I am not sure if there's a legal problem. The
libraries/dependencies we use have some license, and that license needs to
fulfil some requirements, but we could download from various places.
But, I would be careful with adding new servers to the list from where we
can download (currently Maven Central and OSUOSL) - if any of the servers
will be down, NetBeans won't build anymore.
Jan
> I've already implemented to be able to use multiple maven repositories
> in the build. But legally can we?
>
> On 11/10/21 16:17, Tim Boudreau wrote:
> > Ugh, phone swipe typing
> >
> > profile -> profiler
> >
> > Tara -> that’s
> >
> > Sorry,
> >
> > Tim
> >
> > On Wed, Nov 10, 2021 at 7:16 PM Tim Boudreau <ni...@gmail.com>
> wrote:
> >
> >> FWIW, today locally I added a dep from the profile to an atomic bit set
> >> library I wrote Tara in maven central.
> >>
> >> Just add the maven coordinates and hash (upper case for some reason) to
> >> external/binaries-list.
> >>
> >> Have a look at the groovy modules for the format - it’s pretty
> >> self-explanatory.
> >>
> >> I don’t know if there’s some further process for getting a new dep into
> a
> >> release, but that will get you going.
> >>
> >> -Tim
> >>
> >> On Wed, Nov 10, 2021 at 4:57 PM Laszlo Kishalmi <
> laszlo.kishalmi@gmail.com>
> >> wrote:
> >>
> >>> Well that would be nice if we can download Gradle binaries from their
> >>> repository.
> >>>
> >>> I try to recall what was the issue we needed to upload those binaries
> to
> >>> OSUOSL.
> >>>
> >>> If there is no legal problem to add Gradle's artifact repository to our
> >>> build, it would be really easy to move on.
> >>>
> >>> On 11/10/21 10:42, Michael Bien wrote:
> >>>> Hello,
> >>>>
> >>>> I got encouraged by Neil to start a new thread - its not my fault.
> >>>>
> >>>> current status:
> >>>>
> >>>> JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
> >>>>
> >>>>
> >>>> Building NB on JDK 17 involves most likely just a few property bumps
> >>>> and library updates. I could make the java cluster build just by doing
> >>>> that and by updating the build-time gradle wrapper.
> >>>> (https://github.com/apache/netbeans/pull/3278)
> >>>>
> >>>> I can't actually update the gradle wrapper myself (outside of making
> >>>> it point to a local zip for testing purposes) because i am not
> >>>> familiar with the lib hosting service the NB build uses - that is why
> >>>> its not part of the PR - someone else would have to do that (why can't
> >>>> it just use a maven repo?).
> >>>>
> >>>>
> >>>> That would be the easy part, testing on JDK 16+ is going to be more
> >>>> interesting, since NetBeans appears to hook into a very old version of
> >>>> osgi (3.9 via the netbinox module and friends as far as i see, which
> >>>> doesn't even officially support JDK8 btw). There need to be also some
> >>>> updates to junit JVM flags and build configs, but i have those in my
> >>>> stash and it isn't really worth mentioning, beside that its all over
> >>>> the place as to be expected in a big project. Using JDK 16 as a
> >>>> intermediate step before progressing to 17, might help there since the
> >>>> module system of 17 became more restrictive on top of all that.
> >>>>
> >>>>
> >>>> If NetBeans 13 would like to claim to support JDK 17 i would recommend
> >>>> to start with some of this early in the development cycle, esp with
> >>>> the low hanging fruits (gradle wrapper, which unblocks the
> >>>> build-java-cluster-on-17 PR etc).
> >>>>
> >>>> best regards,
> >>>>
> >>>> michael
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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
> >>>
> >>>
> >>>
> >>> --
> >> http://timboudreau.com
> >>
>
> ---------------------------------------------------------------------
> 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: 13+17
Posted by Laszlo Kishalmi <la...@gmail.com>.
It's not about the how. It's about from where (legal).
I've already implemented to be able to use multiple maven repositories
in the build. But legally can we?
On 11/10/21 16:17, Tim Boudreau wrote:
> Ugh, phone swipe typing
>
> profile -> profiler
>
> Tara -> that’s
>
> Sorry,
>
> Tim
>
> On Wed, Nov 10, 2021 at 7:16 PM Tim Boudreau <ni...@gmail.com> wrote:
>
>> FWIW, today locally I added a dep from the profile to an atomic bit set
>> library I wrote Tara in maven central.
>>
>> Just add the maven coordinates and hash (upper case for some reason) to
>> external/binaries-list.
>>
>> Have a look at the groovy modules for the format - it’s pretty
>> self-explanatory.
>>
>> I don’t know if there’s some further process for getting a new dep into a
>> release, but that will get you going.
>>
>> -Tim
>>
>> On Wed, Nov 10, 2021 at 4:57 PM Laszlo Kishalmi <la...@gmail.com>
>> wrote:
>>
>>> Well that would be nice if we can download Gradle binaries from their
>>> repository.
>>>
>>> I try to recall what was the issue we needed to upload those binaries to
>>> OSUOSL.
>>>
>>> If there is no legal problem to add Gradle's artifact repository to our
>>> build, it would be really easy to move on.
>>>
>>> On 11/10/21 10:42, Michael Bien wrote:
>>>> Hello,
>>>>
>>>> I got encouraged by Neil to start a new thread - its not my fault.
>>>>
>>>> current status:
>>>>
>>>> JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
>>>>
>>>>
>>>> Building NB on JDK 17 involves most likely just a few property bumps
>>>> and library updates. I could make the java cluster build just by doing
>>>> that and by updating the build-time gradle wrapper.
>>>> (https://github.com/apache/netbeans/pull/3278)
>>>>
>>>> I can't actually update the gradle wrapper myself (outside of making
>>>> it point to a local zip for testing purposes) because i am not
>>>> familiar with the lib hosting service the NB build uses - that is why
>>>> its not part of the PR - someone else would have to do that (why can't
>>>> it just use a maven repo?).
>>>>
>>>>
>>>> That would be the easy part, testing on JDK 16+ is going to be more
>>>> interesting, since NetBeans appears to hook into a very old version of
>>>> osgi (3.9 via the netbinox module and friends as far as i see, which
>>>> doesn't even officially support JDK8 btw). There need to be also some
>>>> updates to junit JVM flags and build configs, but i have those in my
>>>> stash and it isn't really worth mentioning, beside that its all over
>>>> the place as to be expected in a big project. Using JDK 16 as a
>>>> intermediate step before progressing to 17, might help there since the
>>>> module system of 17 became more restrictive on top of all that.
>>>>
>>>>
>>>> If NetBeans 13 would like to claim to support JDK 17 i would recommend
>>>> to start with some of this early in the development cycle, esp with
>>>> the low hanging fruits (gradle wrapper, which unblocks the
>>>> build-java-cluster-on-17 PR etc).
>>>>
>>>> best regards,
>>>>
>>>> michael
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>> --
>> http://timboudreau.com
>>
---------------------------------------------------------------------
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: 13+17
Posted by Tim Boudreau <ni...@gmail.com>.
Ugh, phone swipe typing
profile -> profiler
Tara -> that’s
Sorry,
Tim
On Wed, Nov 10, 2021 at 7:16 PM Tim Boudreau <ni...@gmail.com> wrote:
> FWIW, today locally I added a dep from the profile to an atomic bit set
> library I wrote Tara in maven central.
>
> Just add the maven coordinates and hash (upper case for some reason) to
> external/binaries-list.
>
> Have a look at the groovy modules for the format - it’s pretty
> self-explanatory.
>
> I don’t know if there’s some further process for getting a new dep into a
> release, but that will get you going.
>
> -Tim
>
> On Wed, Nov 10, 2021 at 4:57 PM Laszlo Kishalmi <la...@gmail.com>
> wrote:
>
>> Well that would be nice if we can download Gradle binaries from their
>> repository.
>>
>> I try to recall what was the issue we needed to upload those binaries to
>> OSUOSL.
>>
>> If there is no legal problem to add Gradle's artifact repository to our
>> build, it would be really easy to move on.
>>
>> On 11/10/21 10:42, Michael Bien wrote:
>> > Hello,
>> >
>> > I got encouraged by Neil to start a new thread - its not my fault.
>> >
>> > current status:
>> >
>> > JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
>> >
>> >
>> > Building NB on JDK 17 involves most likely just a few property bumps
>> > and library updates. I could make the java cluster build just by doing
>> > that and by updating the build-time gradle wrapper.
>> > (https://github.com/apache/netbeans/pull/3278)
>> >
>> > I can't actually update the gradle wrapper myself (outside of making
>> > it point to a local zip for testing purposes) because i am not
>> > familiar with the lib hosting service the NB build uses - that is why
>> > its not part of the PR - someone else would have to do that (why can't
>> > it just use a maven repo?).
>> >
>> >
>> > That would be the easy part, testing on JDK 16+ is going to be more
>> > interesting, since NetBeans appears to hook into a very old version of
>> > osgi (3.9 via the netbinox module and friends as far as i see, which
>> > doesn't even officially support JDK8 btw). There need to be also some
>> > updates to junit JVM flags and build configs, but i have those in my
>> > stash and it isn't really worth mentioning, beside that its all over
>> > the place as to be expected in a big project. Using JDK 16 as a
>> > intermediate step before progressing to 17, might help there since the
>> > module system of 17 became more restrictive on top of all that.
>> >
>> >
>> > If NetBeans 13 would like to claim to support JDK 17 i would recommend
>> > to start with some of this early in the development cycle, esp with
>> > the low hanging fruits (gradle wrapper, which unblocks the
>> > build-java-cluster-on-17 PR etc).
>> >
>> > best regards,
>> >
>> > michael
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>>
>> --
> http://timboudreau.com
>
--
http://timboudreau.com
Re: 13+17
Posted by Tim Boudreau <ni...@gmail.com>.
FWIW, today locally I added a dep from the profile to an atomic bit set
library I wrote Tara in maven central.
Just add the maven coordinates and hash (upper case for some reason) to
external/binaries-list.
Have a look at the groovy modules for the format - it’s pretty
self-explanatory.
I don’t know if there’s some further process for getting a new dep into a
release, but that will get you going.
-Tim
On Wed, Nov 10, 2021 at 4:57 PM Laszlo Kishalmi <la...@gmail.com>
wrote:
> Well that would be nice if we can download Gradle binaries from their
> repository.
>
> I try to recall what was the issue we needed to upload those binaries to
> OSUOSL.
>
> If there is no legal problem to add Gradle's artifact repository to our
> build, it would be really easy to move on.
>
> On 11/10/21 10:42, Michael Bien wrote:
> > Hello,
> >
> > I got encouraged by Neil to start a new thread - its not my fault.
> >
> > current status:
> >
> > JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
> >
> >
> > Building NB on JDK 17 involves most likely just a few property bumps
> > and library updates. I could make the java cluster build just by doing
> > that and by updating the build-time gradle wrapper.
> > (https://github.com/apache/netbeans/pull/3278)
> >
> > I can't actually update the gradle wrapper myself (outside of making
> > it point to a local zip for testing purposes) because i am not
> > familiar with the lib hosting service the NB build uses - that is why
> > its not part of the PR - someone else would have to do that (why can't
> > it just use a maven repo?).
> >
> >
> > That would be the easy part, testing on JDK 16+ is going to be more
> > interesting, since NetBeans appears to hook into a very old version of
> > osgi (3.9 via the netbinox module and friends as far as i see, which
> > doesn't even officially support JDK8 btw). There need to be also some
> > updates to junit JVM flags and build configs, but i have those in my
> > stash and it isn't really worth mentioning, beside that its all over
> > the place as to be expected in a big project. Using JDK 16 as a
> > intermediate step before progressing to 17, might help there since the
> > module system of 17 became more restrictive on top of all that.
> >
> >
> > If NetBeans 13 would like to claim to support JDK 17 i would recommend
> > to start with some of this early in the development cycle, esp with
> > the low hanging fruits (gradle wrapper, which unblocks the
> > build-java-cluster-on-17 PR etc).
> >
> > best regards,
> >
> > michael
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
>
> --
http://timboudreau.com
Re: 13+17
Posted by Laszlo Kishalmi <la...@gmail.com>.
Well that would be nice if we can download Gradle binaries from their
repository.
I try to recall what was the issue we needed to upload those binaries to
OSUOSL.
If there is no legal problem to add Gradle's artifact repository to our
build, it would be really easy to move on.
On 11/10/21 10:42, Michael Bien wrote:
> Hello,
>
> I got encouraged by Neil to start a new thread - its not my fault.
>
> current status:
>
> JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
>
>
> Building NB on JDK 17 involves most likely just a few property bumps
> and library updates. I could make the java cluster build just by doing
> that and by updating the build-time gradle wrapper.
> (https://github.com/apache/netbeans/pull/3278)
>
> I can't actually update the gradle wrapper myself (outside of making
> it point to a local zip for testing purposes) because i am not
> familiar with the lib hosting service the NB build uses - that is why
> its not part of the PR - someone else would have to do that (why can't
> it just use a maven repo?).
>
>
> That would be the easy part, testing on JDK 16+ is going to be more
> interesting, since NetBeans appears to hook into a very old version of
> osgi (3.9 via the netbinox module and friends as far as i see, which
> doesn't even officially support JDK8 btw). There need to be also some
> updates to junit JVM flags and build configs, but i have those in my
> stash and it isn't really worth mentioning, beside that its all over
> the place as to be expected in a big project. Using JDK 16 as a
> intermediate step before progressing to 17, might help there since the
> module system of 17 became more restrictive on top of all that.
>
>
> If NetBeans 13 would like to claim to support JDK 17 i would recommend
> to start with some of this early in the development cycle, esp with
> the low hanging fruits (gradle wrapper, which unblocks the
> build-java-cluster-on-17 PR etc).
>
> best regards,
>
> michael
>
>
> ---------------------------------------------------------------------
> 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