Side note: the api is similar for the plugins you mentionned but it is not the same since you can want to compile with everything on the classpath, document (javadoc) with modules and jshell is kind of worse depending what you run and deps you add so any plugin is really isolated from others which enforces, as we mentionned in the original thread, each plugin to have a set of dependency set identifiers to work (type in this PoC but hopefully we can find something else more user friendly later). So for me the common api is depService.findDependencies(dependencySetIds) but nothing more. Defaults can overlap then to make it backward compatible and smooth by default but don't think we should look for anything else which will likely block users more than helping (as current "guess" algorithm which enforces explicit configuration for it to work).
Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 19 déc. 2023 à 14:46, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2023-12-19 à 14 h 12, Guillaume Nodet a écrit : > > > Sure, but you asked for an API, there's none so far. > > > Right, thanks for the information, it is really useful for putting me on > track. > > > > I'm not sure what kind of API we could offer, as this depends on what > > you want to build. If you build an OSGi plugin, you may want to > > restrict the visibility to exported packages, kinda like with JPMS. > > Takari lifecycle does this sort of thing too. So the API depends on > > the packaging / type of artifact you're building imho. > > > Probably for some packaging. But there is also a common ground. The > algorithm is the same for java, javac, javadoc and jshell tools, just to > name the ones that I remember. So the idea would be to have common > algorithms covering at least the needs of standard JDK tools. I hope > that OSGi could, if they want, pickup the results and apply their own > modifications on it. An API may look like this (draft to be > revised/expanded later): > > > https://github.com/Geomatys/maven/blob/explicit-module-path/api/maven-api-core/src/main/java/org/apache/maven/api/DependencyPaths.java > > > > Imho, but Tamas has thought about it more afaik, JPMS modules should > > have their own packaging / lifecycle, not reusing plain JAR, as the > > rules are different. The compiler plugin maybe should be a different > > plugin too, that would make things less complicated maybe. > > > They would have their own packaging, named "modular-jar", but the "jar" > packaging would also apply at least for compatibility with current > behaviour. In Maven 3, "jar" packaging means "autodetect" (the Maven 3 > auto-detection algorithm has a problem, but this is another story). > Another argument is that, in the current Java ecosystem, we have a mix > of modular and non-modular dependencies. So we cannot create cleanly > separated plugins. Each plugin needs to be able to handle a mix modular > and non-modular dependencies. Thus the proposal to define a common API > dedicated to dispatching dependencies between different kind of paths, > covering at least the paths defined by standard JDK tools. > > Martin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
