You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Matteo Di Giovinazzo <ma...@gmail.com> on 2019/12/10 02:39:25 UTC
NB Platform apps only compile against the JDK running the IDE
Hi there,
has anyone any hint about this?
https://issues.apache.org/jira/browse/NETBEANS-3278
It would be great to have this fixed by 11.3
I guess it is because the new JDKs (since 9) are missing "lib/tools.jar"
(that's what it seems from a shallow look at harness/jdk.xml).
Thanks!
--
Matteo Di Giovinazzo
Re: Re: NB Platform apps only compile against the JDK running the IDE
Posted by Matteo Di Giovinazzo <ma...@gmail.com>.
Yes, even though we set up a new JDK location in Java Platform
configuration it did not help: we got the below (somehow truncated) message
and NetBeans IDE ended up using the JDK used to run itself:
Warning: nbjdk.active=OpenJDK13 or
nbjdk.home=D:\Java\OpenJDK\jdk-13.0.1 is an invalid Java platform;
ignoring and using D:\Java\OpenJDK
On Fri, 13 Dec 2019 at 02:42, Eric Bresie <eb...@gmail.com> wrote:
> Assume adding the new JDK location to java support in the ide doesn’t help
> here than?
>
> Eric Bresie
> Ebresie@gmail.com
> > On December 12, 2019 at 10:20:13 PM CST, Tim Boudreau <
> niftiness@gmail.com> wrote:
> > Did you try to find a workable combination of versions that would work to
> > simply have one version of each on the classpath of the libraries that
> need
> > them (hint: exclude the original dependency when building the wrapper
> > module and have it depend on the wrapper for the version you want to use
> of
> > that library).
> >
> > On Wed, Dec 11, 2019 at 11:53 PM Matteo Di Giovinazzo <
> matteodg@gmail.com>
> > wrote:
> >
> > > Thanks Tim,
> > > but unfortunately the problem we are having with moving to Maven is
> the one
> > > I described in [1].
> > >
> > > The solution we implemented is to create a Gradle plugin (because
> Gradle
> > > offers higher flexibility and dependencies configuration than Maven)
> that
> > > resolves the dependency tree from a declared list of dependencies in a
> > > build.gradle script.
> > > Then the plugin packages all artifact files in either:
> > >
> > > 1. a single NB library wrapper module or
> > > 2. a series of NB library wrapper modules whose inter-dependencies are
> > > exactly those of the dependency tree resolved by Gradle.
> > >
> > > The solution #2 is not ideal because NetBeans is using non-transitive
> > > dependencies: so in the client modules we would need to depend on all
> > > library wrapper modules of the subtree of the needed library.
> > > Have we used Maven we would end up with redundant libraries described
> in
> > > [1].
> > >
> > > We might share later on the Gradle plugin to help other developers
> facing
> > > the same issue.
> > > -Matteo
> > >
> > > [1] NetBeans app with Maven with 3rd party libs
> > > <
> > >
> https://lists.apache.org/thread.html/1377d9a39df8ac652d39c0d886ada3ce15bddb051517805363ea141b%40%3Cdev.netbeans.apache.org%3E
> > > >
> > >
> > >
> > > On Wed, 11 Dec 2019 at 19:37, Tim Boudreau <ni...@gmail.com>
> wrote:
> > >
> > > > No clue about the bug, but a mitigation would be to migrate your
> platform
> > > > app to build with maven, which also makes dealing with libraries much
> > > > simpler
> > > > -Tim
> > > >
> > > > On Mon, Dec 9, 2019 at 9:39 PM Matteo Di Giovinazzo <
> matteodg@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi there,
> > > > > has anyone any hint about this?
> > > > > https://issues.apache.org/jira/browse/NETBEANS-3278
> > > > >
> > > > > It would be great to have this fixed by 11.3
> > > > > I guess it is because the new JDKs (since 9) are missing
> > > "lib/tools.jar"
> > > > > (that's what it seems from a shallow look at harness/jdk.xml).
> > > > >
> > > > > Thanks!
> > > > > --
> > > > > Matteo Di Giovinazzo
> > > > >
> > > > --
> > > > http://timboudreau.com
> > > >
> > >
> > >
> > > --
> > > Matteo Di Giovinazzo
> > >
> > --
> > http://timboudreau.com
>
--
Matteo Di Giovinazzo
Re: Re: NB Platform apps only compile against the JDK running
the IDE
Posted by Eric Bresie <eb...@gmail.com>.
Assume adding the new JDK location to java support in the ide doesn’t help here than?
Eric Bresie
Ebresie@gmail.com
> On December 12, 2019 at 10:20:13 PM CST, Tim Boudreau <ni...@gmail.com> wrote:
> Did you try to find a workable combination of versions that would work to
> simply have one version of each on the classpath of the libraries that need
> them (hint: exclude the original dependency when building the wrapper
> module and have it depend on the wrapper for the version you want to use of
> that library).
>
> On Wed, Dec 11, 2019 at 11:53 PM Matteo Di Giovinazzo <ma...@gmail.com>
> wrote:
>
> > Thanks Tim,
> > but unfortunately the problem we are having with moving to Maven is the one
> > I described in [1].
> >
> > The solution we implemented is to create a Gradle plugin (because Gradle
> > offers higher flexibility and dependencies configuration than Maven) that
> > resolves the dependency tree from a declared list of dependencies in a
> > build.gradle script.
> > Then the plugin packages all artifact files in either:
> >
> > 1. a single NB library wrapper module or
> > 2. a series of NB library wrapper modules whose inter-dependencies are
> > exactly those of the dependency tree resolved by Gradle.
> >
> > The solution #2 is not ideal because NetBeans is using non-transitive
> > dependencies: so in the client modules we would need to depend on all
> > library wrapper modules of the subtree of the needed library.
> > Have we used Maven we would end up with redundant libraries described in
> > [1].
> >
> > We might share later on the Gradle plugin to help other developers facing
> > the same issue.
> > -Matteo
> >
> > [1] NetBeans app with Maven with 3rd party libs
> > <
> > https://lists.apache.org/thread.html/1377d9a39df8ac652d39c0d886ada3ce15bddb051517805363ea141b%40%3Cdev.netbeans.apache.org%3E
> > >
> >
> >
> > On Wed, 11 Dec 2019 at 19:37, Tim Boudreau <ni...@gmail.com> wrote:
> >
> > > No clue about the bug, but a mitigation would be to migrate your platform
> > > app to build with maven, which also makes dealing with libraries much
> > > simpler
> > > -Tim
> > >
> > > On Mon, Dec 9, 2019 at 9:39 PM Matteo Di Giovinazzo <ma...@gmail.com>
> > > wrote:
> > >
> > > > Hi there,
> > > > has anyone any hint about this?
> > > > https://issues.apache.org/jira/browse/NETBEANS-3278
> > > >
> > > > It would be great to have this fixed by 11.3
> > > > I guess it is because the new JDKs (since 9) are missing
> > "lib/tools.jar"
> > > > (that's what it seems from a shallow look at harness/jdk.xml).
> > > >
> > > > Thanks!
> > > > --
> > > > Matteo Di Giovinazzo
> > > >
> > > --
> > > http://timboudreau.com
> > >
> >
> >
> > --
> > Matteo Di Giovinazzo
> >
> --
> http://timboudreau.com
Re: NB Platform apps only compile against the JDK running the IDE
Posted by Tim Boudreau <ni...@gmail.com>.
On Fri, Dec 13, 2019 at 11:12 AM Matteo Di Giovinazzo <ma...@gmail.com>
wrote:
> Hi thanks Tim,
> the 3-libraries case in my email was just an example: we actually have 52
> declared dependencies that end up resolving in 170 jar files... pretty
> unmanageable by hand...
Figuring out which version is problematic would be the hard part. I’d write
a script to generate all the wrapper modules and pick the newest version of
each, and then start testing and tweaking versions.
I guess having NetBeans application using transitive dependencies between
> NB modules would be a fundamental and disrupting change in the current
> architecture, isn't it?
Couldn’t possibly help. Each module gets its own class loader with multiple
parents. If module A depends on library N’1 and module B depends on library
N’2 passes a reference to a class to a type known to both, an instanceof
test in module A will fail - they are instances of unrelated types that
happen to have the same package and class names as far as the JVM is
concerned.
Your problem is not how dependencies are specified, it is the fact of
needing to depend on multiple versions of the same logical thing.
Now, as I think I said earlier, for things that really can’t mix and don’t
expose library types externally, there isn’t really a problem - they can
have their private dependency on their private copy of the library and
they’re fine (though it would be preferable to find a version to share). If
you were having a problem with jar name collisions (doubtful) in
modules/ext, you could build a fat jar of your module that includes the
class files from the library.
So the only hard cases are where
- instances of library classes are passed BETWEEN modules depending on
different versions of the library
- those truly cannot depend on the same version of the library in question
I expect most dependencies will not be a big deal. The main point of work
would be generating the wrapper modules.
-Tim
>
>
>
> On Thu, 12 Dec 2019 at 21:20, Tim Boudreau <ni...@gmail.com> wrote:
>
> > Did you try to find a workable combination of versions that would work to
> > simply have one version of each on the classpath of the libraries that
> need
> > them (hint: exclude the original dependency when building the wrapper
> > module and have it depend on the wrapper for the version you want to use
> of
> > that library).
> >
> > On Wed, Dec 11, 2019 at 11:53 PM Matteo Di Giovinazzo <
> matteodg@gmail.com>
> > wrote:
> >
> > > Thanks Tim,
> > > but unfortunately the problem we are having with moving to Maven is the
> > one
> > > I described in [1].
> > >
> > > The solution we implemented is to create a Gradle plugin (because
> Gradle
> > > offers higher flexibility and dependencies configuration than Maven)
> that
> > > resolves the dependency tree from a declared list of dependencies in a
> > > build.gradle script.
> > > Then the plugin packages all artifact files in either:
> > >
> > > 1. a single NB library wrapper module or
> > > 2. a series of NB library wrapper modules whose inter-dependencies
> are
> > > exactly those of the dependency tree resolved by Gradle.
> > >
> > > The solution #2 is not ideal because NetBeans is using non-transitive
> > > dependencies: so in the client modules we would need to depend on all
> > > library wrapper modules of the subtree of the needed library.
> > > Have we used Maven we would end up with redundant libraries described
> in
> > > [1].
> > >
> > > We might share later on the Gradle plugin to help other developers
> facing
> > > the same issue.
> > > -Matteo
> > >
> > > [1] NetBeans app with Maven with 3rd party libs
> > > <
> > >
> >
> https://lists.apache.org/thread.html/1377d9a39df8ac652d39c0d886ada3ce15bddb051517805363ea141b%40%3Cdev.netbeans.apache.org%3E
> > > >
> > >
> > >
> > > On Wed, 11 Dec 2019 at 19:37, Tim Boudreau <ni...@gmail.com>
> wrote:
> > >
> > > > No clue about the bug, but a mitigation would be to migrate your
> > platform
> > > > app to build with maven, which also makes dealing with libraries much
> > > > simpler
> > > > -Tim
> > > >
> > > > On Mon, Dec 9, 2019 at 9:39 PM Matteo Di Giovinazzo <
> > matteodg@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi there,
> > > > > has anyone any hint about this?
> > > > > https://issues.apache.org/jira/browse/NETBEANS-3278
> > > > >
> > > > > It would be great to have this fixed by 11.3
> > > > > I guess it is because the new JDKs (since 9) are missing
> > > "lib/tools.jar"
> > > > > (that's what it seems from a shallow look at harness/jdk.xml).
> > > > >
> > > > > Thanks!
> > > > > --
> > > > > Matteo Di Giovinazzo
> > > > >
> > > > --
> > > > http://timboudreau.com
> > > >
> > >
> > >
> > > --
> > > Matteo Di Giovinazzo
> > >
> > --
> > http://timboudreau.com
> >
>
>
> --
> Matteo Di Giovinazzo
>
--
http://timboudreau.com
Re: NB Platform apps only compile against the JDK running the IDE
Posted by Matteo Di Giovinazzo <ma...@gmail.com>.
Hi thanks Tim,
the 3-libraries case in my email was just an example: we actually have 52
declared dependencies that end up resolving in 170 jar files... pretty
unmanageable by hand...
I guess having NetBeans application using transitive dependencies between
NB modules would be a fundamental and disrupting change in the current
architecture, isn't it?
On Thu, 12 Dec 2019 at 21:20, Tim Boudreau <ni...@gmail.com> wrote:
> Did you try to find a workable combination of versions that would work to
> simply have one version of each on the classpath of the libraries that need
> them (hint: exclude the original dependency when building the wrapper
> module and have it depend on the wrapper for the version you want to use of
> that library).
>
> On Wed, Dec 11, 2019 at 11:53 PM Matteo Di Giovinazzo <ma...@gmail.com>
> wrote:
>
> > Thanks Tim,
> > but unfortunately the problem we are having with moving to Maven is the
> one
> > I described in [1].
> >
> > The solution we implemented is to create a Gradle plugin (because Gradle
> > offers higher flexibility and dependencies configuration than Maven) that
> > resolves the dependency tree from a declared list of dependencies in a
> > build.gradle script.
> > Then the plugin packages all artifact files in either:
> >
> > 1. a single NB library wrapper module or
> > 2. a series of NB library wrapper modules whose inter-dependencies are
> > exactly those of the dependency tree resolved by Gradle.
> >
> > The solution #2 is not ideal because NetBeans is using non-transitive
> > dependencies: so in the client modules we would need to depend on all
> > library wrapper modules of the subtree of the needed library.
> > Have we used Maven we would end up with redundant libraries described in
> > [1].
> >
> > We might share later on the Gradle plugin to help other developers facing
> > the same issue.
> > -Matteo
> >
> > [1] NetBeans app with Maven with 3rd party libs
> > <
> >
> https://lists.apache.org/thread.html/1377d9a39df8ac652d39c0d886ada3ce15bddb051517805363ea141b%40%3Cdev.netbeans.apache.org%3E
> > >
> >
> >
> > On Wed, 11 Dec 2019 at 19:37, Tim Boudreau <ni...@gmail.com> wrote:
> >
> > > No clue about the bug, but a mitigation would be to migrate your
> platform
> > > app to build with maven, which also makes dealing with libraries much
> > > simpler
> > > -Tim
> > >
> > > On Mon, Dec 9, 2019 at 9:39 PM Matteo Di Giovinazzo <
> matteodg@gmail.com>
> > > wrote:
> > >
> > > > Hi there,
> > > > has anyone any hint about this?
> > > > https://issues.apache.org/jira/browse/NETBEANS-3278
> > > >
> > > > It would be great to have this fixed by 11.3
> > > > I guess it is because the new JDKs (since 9) are missing
> > "lib/tools.jar"
> > > > (that's what it seems from a shallow look at harness/jdk.xml).
> > > >
> > > > Thanks!
> > > > --
> > > > Matteo Di Giovinazzo
> > > >
> > > --
> > > http://timboudreau.com
> > >
> >
> >
> > --
> > Matteo Di Giovinazzo
> >
> --
> http://timboudreau.com
>
--
Matteo Di Giovinazzo
Re: NB Platform apps only compile against the JDK running the IDE
Posted by Tim Boudreau <ni...@gmail.com>.
Did you try to find a workable combination of versions that would work to
simply have one version of each on the classpath of the libraries that need
them (hint: exclude the original dependency when building the wrapper
module and have it depend on the wrapper for the version you want to use of
that library).
On Wed, Dec 11, 2019 at 11:53 PM Matteo Di Giovinazzo <ma...@gmail.com>
wrote:
> Thanks Tim,
> but unfortunately the problem we are having with moving to Maven is the one
> I described in [1].
>
> The solution we implemented is to create a Gradle plugin (because Gradle
> offers higher flexibility and dependencies configuration than Maven) that
> resolves the dependency tree from a declared list of dependencies in a
> build.gradle script.
> Then the plugin packages all artifact files in either:
>
> 1. a single NB library wrapper module or
> 2. a series of NB library wrapper modules whose inter-dependencies are
> exactly those of the dependency tree resolved by Gradle.
>
> The solution #2 is not ideal because NetBeans is using non-transitive
> dependencies: so in the client modules we would need to depend on all
> library wrapper modules of the subtree of the needed library.
> Have we used Maven we would end up with redundant libraries described in
> [1].
>
> We might share later on the Gradle plugin to help other developers facing
> the same issue.
> -Matteo
>
> [1] NetBeans app with Maven with 3rd party libs
> <
> https://lists.apache.org/thread.html/1377d9a39df8ac652d39c0d886ada3ce15bddb051517805363ea141b%40%3Cdev.netbeans.apache.org%3E
> >
>
>
> On Wed, 11 Dec 2019 at 19:37, Tim Boudreau <ni...@gmail.com> wrote:
>
> > No clue about the bug, but a mitigation would be to migrate your platform
> > app to build with maven, which also makes dealing with libraries much
> > simpler
> > -Tim
> >
> > On Mon, Dec 9, 2019 at 9:39 PM Matteo Di Giovinazzo <ma...@gmail.com>
> > wrote:
> >
> > > Hi there,
> > > has anyone any hint about this?
> > > https://issues.apache.org/jira/browse/NETBEANS-3278
> > >
> > > It would be great to have this fixed by 11.3
> > > I guess it is because the new JDKs (since 9) are missing
> "lib/tools.jar"
> > > (that's what it seems from a shallow look at harness/jdk.xml).
> > >
> > > Thanks!
> > > --
> > > Matteo Di Giovinazzo
> > >
> > --
> > http://timboudreau.com
> >
>
>
> --
> Matteo Di Giovinazzo
>
--
http://timboudreau.com
Re: NB Platform apps only compile against the JDK running the IDE
Posted by Matteo Di Giovinazzo <ma...@gmail.com>.
Thanks Tim,
but unfortunately the problem we are having with moving to Maven is the one
I described in [1].
The solution we implemented is to create a Gradle plugin (because Gradle
offers higher flexibility and dependencies configuration than Maven) that
resolves the dependency tree from a declared list of dependencies in a
build.gradle script.
Then the plugin packages all artifact files in either:
1. a single NB library wrapper module or
2. a series of NB library wrapper modules whose inter-dependencies are
exactly those of the dependency tree resolved by Gradle.
The solution #2 is not ideal because NetBeans is using non-transitive
dependencies: so in the client modules we would need to depend on all
library wrapper modules of the subtree of the needed library.
Have we used Maven we would end up with redundant libraries described in
[1].
We might share later on the Gradle plugin to help other developers facing
the same issue.
-Matteo
[1] NetBeans app with Maven with 3rd party libs
<https://lists.apache.org/thread.html/1377d9a39df8ac652d39c0d886ada3ce15bddb051517805363ea141b%40%3Cdev.netbeans.apache.org%3E>
On Wed, 11 Dec 2019 at 19:37, Tim Boudreau <ni...@gmail.com> wrote:
> No clue about the bug, but a mitigation would be to migrate your platform
> app to build with maven, which also makes dealing with libraries much
> simpler
> -Tim
>
> On Mon, Dec 9, 2019 at 9:39 PM Matteo Di Giovinazzo <ma...@gmail.com>
> wrote:
>
> > Hi there,
> > has anyone any hint about this?
> > https://issues.apache.org/jira/browse/NETBEANS-3278
> >
> > It would be great to have this fixed by 11.3
> > I guess it is because the new JDKs (since 9) are missing "lib/tools.jar"
> > (that's what it seems from a shallow look at harness/jdk.xml).
> >
> > Thanks!
> > --
> > Matteo Di Giovinazzo
> >
> --
> http://timboudreau.com
>
--
Matteo Di Giovinazzo
Re: NB Platform apps only compile against the JDK running the IDE
Posted by Tim Boudreau <ni...@gmail.com>.
No clue about the bug, but a mitigation would be to migrate your platform
app to build with maven, which also makes dealing with libraries much
simpler
-Tim
On Mon, Dec 9, 2019 at 9:39 PM Matteo Di Giovinazzo <ma...@gmail.com>
wrote:
> Hi there,
> has anyone any hint about this?
> https://issues.apache.org/jira/browse/NETBEANS-3278
>
> It would be great to have this fixed by 11.3
> I guess it is because the new JDKs (since 9) are missing "lib/tools.jar"
> (that's what it seems from a shallow look at harness/jdk.xml).
>
> Thanks!
> --
> Matteo Di Giovinazzo
>
--
http://timboudreau.com