Le 2023-11-03 à 21 h 30, Romain Manni-Bucau a écrit :
The <type> proposal would put the dependency on whatever path the
<type> said it should be.
Means you create as much type as plugin*pathTypePerPlugin, looks overkill.
The current set of new path types would contain about 6 types (class,
module, taglet, doclet, agent, annotation-processor). Maybe more types
would need to be added for new plugins, but I presume we could design a
mechanism for allowing plugins to extend the set of types.
By comparison, the DependencySet approach can also be seen as an
overkill, and conflicts with the goal of not forcing users to care about
class-path / module-path distinction unless they need to. The <type>
approach has the advantage of being optional.
And just using class/module paths does not work, so ultimately plugins
will need filters and maybe just rely on scopes+filters
A filtering-per-plugin is already done by <scope>test</scope>,
<scope>runtime</scope>, etc. Is there a need for another filtering
mechanism? As far as JPMS is concerned, the current <scope> mechanism
works unchanged. Other aspects such as --add-exports or --limit-modules
options can be handled separately as proposed in previous emails. So I
think we can keep this thread focused on only paths.
Yes, but you just added a jaxws type to maven core - see why this does
no scale/work?
I'm not familiar with JAXWS. Would it be because it would add a new kind
of path in addition of class-path and module-path? If yes, then as said
above, maybe it is possible to design the set of types in an extensible
way. If JAXWS also adds a need for a new filtering condition, then maybe
the set of scopes can also be designed as extensible.
I'm not sure if you are talking about the Java compiler's "Module
Source Hierarchy" here. If yes, this is indeed something that I would
like, but I'm not trying to push that for Maven
This already works with maven, needs to tune the folder layouts and a
few plugins - (…snip…) so not sure what misses there.
Maven is missing all the plugins. Many of them would need major work.
But anyway, this is not the topic of this thread.
Thanks for the configuration tip, but it works by setting the
--class-path and --module-path options in the <arguments> block of
the exec-maven-plugin. My issue was also execution with surefire,
javadoc, etc. All plugins need the same configuration.
It is the same there, nothing relates to depency type (which is my
point).
I was not clear. The java, javac, javap, jdeps, javadoc and jshell tools
all have the same class-path and module-path options. Projects typically
need to set the same paths for all those tools, with variations
controlled by the <scope> element in dependency declarations. The
configuration tip in previous email was replacing the Maven classpath
management by full command-line arguments passed to Java in the
maven-exec-plugin. That tip would require to repeat the same
configuration overriding in all plugins (surefire, javadoc, etc.), each
with their own syntax, and forces all users of the library to do the
same on their side. Basically, it was transforming Maven into Ant.
Global configuration is also desirable (…snip…).
I see a lot of overlap but no 1-1 cases except on simple projects.
Compiler != Surefire != Javadoc for ex, this is why type looks very
limiting until combinable or each plugin has filter capability which
also mean type is useless.
The filtering is already done by <scope>test</scope>,
<scope>runtime</scope>, etc. What else do we need? JPMS needs no change
at all on this aspect. Or are you proposing to adopt DependencySet as a
replacement for both <type> and <scope> in general (not only for the
topic of this thread)?
For trying to get this discussion to converge, can we try to agree on
the design goals? I see the following ones:
1. Make possible to declare paths globally, for sharing by all plugins.
2. Allow per-plugin filtering. This is already done in Maven 3 by <scope>.
3. Allow library developers to specify what should be on the module-path.
4. Free users from bothering about class/module paths when above works.
5. Allow users to override if they need to, similar to overriding versions.
6. Minimize changes compared to current way that Maven work.
The <type> proposal extends an existing concept rather than introducing
a new one. Filtering is done by <scope> and needs no change for JPMS.
The way transitive dependencies are managed, and the way users can
override, is the same as what Maven does today with dependency versions.
Type and scope are optional, allowing users to ignore as long as the
defaults work for them.
In my understanding, DependencySet would be a new concept. It seems to
be a replacement for both <type> and <scope>, thus introducing a
significant shift in the way peoples use Maven. It would force users to
care about class-path versus module-path difference instead of bothering
only if they need to. It does not allow the class-path / module-path
preference to be expressed by the library producer instead of the user.
But of course my understanding of the DependencySet alternative proposal
may be wrong.
Martin
