On Fri, Dec 13, 2019 at 11:12 AM Matteo Di Giovinazzo <matte...@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 <niftin...@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 < > matte...@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 <niftin...@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 < > > matte...@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
