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 <niftin...@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.kisha...@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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
--
http://timboudreau.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
