Le mer. 3 janv. 2024 à 16:11, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-03 à 15 h 19, Romain Manni-Bucau a écrit : > > > I can agree with that so let's move it in a plugin related code maybe? > > > The call is on core Maven developers. If Tamas (or someone else) moves > everything related to class-path to another location, I will follow. But > I think it would need to be a place shared by all Java plugins. > Not really, maven4 introduces the notion of "services", this is where it sits in maven plugin api probably "findDependenciesByFlag(flag)" or "findDependenciesByFilter(...)" - thinking out loud it can not need anything but just to resolve all deps of the module upfront the module build instead of doing it by phase then it is just a .stream().filter() matter. So guess all is there to do it and core can stay as this for backward compat (maven4 must support maven3) but nothing more. > > > > The SPI registration is different depending you are on the class or > > module path. > > > Yes, but it is different than saying that ServiceLoader does not work > well with modules. Managing those differences is one purpose of better > class-path / module-path control. > > > So how do I resolve a "library-path" lib which is > > org/foo/bar/1.0.0/bar-1.0.0.so for example? > > > In a custom plugin written by Java code? > * Create a new PathType instance, e.g. named NATIVE_LIBRARIES. > * Create a new Type instance, e.g. named "so", which declares that > dependencies of this type are members of the NATIVE_LIBRARIES paths. > Notes: > o As said before, this requires a minor change in > DependencyProperties API. > o This approach may have changed since December 14th, I'm not sure. > * In the plugin code, call the following: > > DependencyResolverResult result = > session.getService(DependencyResolver.class) > .resolve(session, project, ResolutionScope.PROJECT_COMPILE); > List<Path> paths = result.getDispatchedPaths().get(NATIVE_LIBRARIES); > > That's all, plugin uses the paths as they want. If there is a need for > custom code specifying what to do when the same dependency belong to 2 > or more PathType, it could be done by adding some methods in > DependencyResolverRequest (not shown in above example). > Maybe I misread your PR but I didn't see where dependencies were added in dep resolver using the meta but if it is the case you are in the case I mentionned in previous comment: you just let to the plugin the filtering so precollecting it makes it a lot of work compared a custom filter (this so example look simple but add dll/dylib cases and you'll see that it is easier with a filter, we had the same issue with path filtering and ended dropping most of the tools plugin shared for that reason). So overall, if this genericity is true it means that the surfacing of the jpms flags can sit in a maven 4 service and be it (and drop it from internal basically). That said I'm not sure how getPathType can return PathType.FOO in current code. > > > > No need to modify it, just run javadoc:aggregate on this example > > > javadoc:aggregate (as opposed to javadoc:javadoc) is a special case, as > it does not process a single Maven module, but all modules together. So > it needs to compute the union of source-directories, class-paths and > module-paths of all Maven modules, which is indeed not a standard Maven > usage. If I remember right an email seen on this list or on JIRA years > ago, they way that javadoc:aggregate does that is a dirty trick even by > Maven 3 standards. But anyway, 1) plugins will still be allowed to do > dirty tricks if they want, and 2) the need for javadoc:aggregate would > be greatly reduced with Module Source Hierarchy (javadoc:javadoc would > do the same work in a cleaner way), but this is another debate that I > would like to avoid for now. > use javadoc:javadoc then, intent is to run it with --module-path target/classes but compile with --classpath in the mentionned example (it is true from deps too) so it stays in the current situation for pom writer IMHO even if you enhanced the plain jpms adopter case. this currently works cause both plugins handle the path differently but it seems your intent is to align both - which is something I can understand for your case. so the issue is still the same for me: you cover one valid use case quite well but we add mess on mess (agree with you that each plugin having got a custom jpms integration was not great even if it has explanation for mvn3). so I still think we should step back, review the concepts we have and identify that some are outdated - cause classpath is no more a single thing for example, you are right - and check if we add a hack - type usage - or just rethink the dependencies management to make the overall solution easier. hope we go with last option whatever we can do with types.& > > > > You said you can declare a type from a pom without coding anything. > > > Without coding anything in Maven core, i.e., additions of new types are > not blocked by the need to modify and release new versions of core. > Plugins still need their own code. > Does it mean the pom consumer generation integration and/or pom v4.2 code are already there or is it a "would be easy to do" (trying to match code and statements for now). > > Martin > >
