Martin I can understand that theorically your proposal look good but just
to answer trivially to "But if an artifact is included, it should (at least
by default) always be placed consistently on the class-path or
module-path.", it is obvious it is not the case for several plugins like
surefire (where ultimately you want to test both but default on classpath
is fine in 80% of cases even if a module) and even javadoc/compiler will
differ as explained earlier (documentation "view" vs bytecode "view", each
view has its own constraints and alignment is a matter of consumers and lib
will always priviledge its main consumers - classpaths today - and enable
others - jpms so javadoc must include module metadata but build will enable
other features not always module friendly). This only uses built-in
plugins, it is worse when using plugins to build images for examples or to
generate part of the doc where using the classpath will enable to fall in
an area you can use more reflection for example or even plain exec plugin
which does not handle modules in java mode so will ignore - by design -
several of the options you added.
The first concern of my previous answer I mentionned was not "did you put
logic" but "you hardcoded the dispatching as _isAddedtoClasspath_ did
before" - even if the logic is more complex now - so basically we stay in
the same status quo where plugins still have to redo all the dispatching
logic themselves and, as you pointed out, since the number of consumers
("paths") becomes more serious it will need to be shared (maven-shared or
alike) to be consistent and not too laborious probably.
So to summarize my thinking:
* we need to share the *configuration* and gathering of dependencies per
plugin target
** a way to do that is to enable to compose dependency sets and a way to
reference them from plugins
* we need to ensure this "way" is shared and consistent in default plugins
(and consumable by external plugins for ecosystem consistency)
* we need to ensure we dont hardcode paths per pom but enable to get it per
plugin
* we need to ensure these dependency sets ("types" today) are extensible
from the pom directly, without any code or extensions to let plugins
consume more
* we need to review we still need scopes or if we just bind a set name to a
phase which would simplify the build by limiting the concepts (indeed
keeping default implicit conventions for an ease of use for "default" -
whatever it means - case)
* we should try to target to not get more than the default lifecycle in
maven-core and ideally ensure _MavenProject_ enables to collect
dependencies (from sets/types) with the shared rule rather than pre-doing
it in a rigid way needing another filtering pass - guess today lambdas and
collectors will help us to make it smooth enough compared to the old code
I know it is more changes than you probably expected but my goal is to keep
the overall delivery consistent and understandable by any dev, in
particular the one abusing conventions - for goods, and not hardcode
concepts in core and not solve the original challenge which is that a new
type of path needs to recode in core.
Making it even more concrete: how to you handle the _webjars_ path in your
proposal? This is needed to prebundle frontend resources when using
webjars? So let's add webjars type in core too. We also need npm type,
cargo type, composer type, .... and if you would argue maven is java (which
is not true) just think OSGi, jboss module, native libraries (so, dll, ...)
etc...
Maven is a generic tool so we can't hardcode the resolution in core and we
can only enable it there IMHO.
Then it is a matter of how we deal with the common challenges we have and
if we try to find a global solution and not add concepts on top of concepts
- once again type is not understood and will probably not be understood
more than extensions by most users so I think it is good if we stick to
that even if technically we could do more as Tamas explained - or if we
just patch core adding a new wart in it.
Indeed I'm for solving the challenge globally and not making it JPMS
specific.
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. 2 janv. 2024 à 22:00, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-01-02 à 20 h 51, Romain Manni-Bucau a écrit :
>
> > RMB: so you mean you don't intend to link the classpath to the type?
>
> Not directly. The code dispatching JAR files between classpath,
> module-path, etc., bases fully its decision on the following:
>
> * DependencyProperties
> * Sometime whether the dependency is modularized (whether to do this
> check or not depends on the properties)
> * In the specific case of --patch-module, dependencies previously
> added on --module-path.
>
> In the older proposal, DependencyProperties were determined by the Type.
> So this is where classpath was indirectly linked to type. However, it
> seems to have changed in a commit on December 14th, and I'm not sure
> what is the new way. But I will adapt.
>
>
> > assuming all the toggles you spoke about (let's focus on jpms for now)
> > are shared by plugins, this is not the case, javadoc, surefire and
> > compiler don't share them most of the time - it is the same for
> > exports/opens in another JVM area.
>
> My proposal is to gradually move away from that situation to a situation
> where the paths are managed in shared code, at least for standard tools.
> It does not mean that plugins cannot customize.
>
>
> > RMB: Probably the majority, not sure it is vast or just most of cases
> >
> Let's do a prototype, then create test cases showing the limitations.
> What are the proven limitations will give us a better idea about whether
> the prototype covers a majority of cases or not.
>
>
> > And this is a key point, this classpath definition is needed for any
> > project, not only JPMS, and this solution is specific to JPMS since it
> > ignores most of plugins outside java ecosystem,
> >
> The proposal also covers taglet, doclet, annotation processor, agent,
> etc., and is extensible so that plugins can define their own path types.
> The proposal needs to be made more extensible, but I don't think it will
> be a problem if the principle is accepted.
>
> In some way, the proposal has a little bit of similarity with the
> "dependency sets" you proposed. The DependencyProperties interface
> contains properties such as IS_CLASSPATH_CONSTITUENT,
> IS_MODULEPATH_CONSTITUENT, etc., which are boolean values. They could be
> interpreted as "this dependency is a member of the classpath set", "this
> dependency is a member of the module-path set", etc. I was thinking to
> replace those properties by a single property telling directly in which
> set(s) this dependency belong, but I thought that it does not need to be
> debated now because it is a very minor change.
>
>
> > annotation processor is core to java since 20 years, never been core
> > to any build tool even if widely used so for me it is 100% about the
> > usage and adoption/consumer need.
> >
> Annotation processor does not replace classpath. By contrast,
> module-path replaces fully the classpath if all dependencies are
> modularized. I see class-path as legacy, which would be deprecated if
> enough dependencies in the Java ecosystem were modularized.
>
>
> > the interface is almost the same for all, ack...does not mean they
> > will consume the same artifacts for all these options
> >
> Yes, this is why scope exists. An artifact may be compile-time only, or
> runtime only, etc. But if an artifact is included, it should (at least
> by default) always be placed consistently on the class-path or
> module-path. Other kinds of path (doclet, etc.) work in a similar way.
>
>
> > will you create a type=javadoc-module-path, type=javac-module-path etc
> >
> No, it is not my plan. I believe that making inconsistent "classpath
> versus module-path" choices for different tools is asking for trouble.
> To be convinced otherwise, I would need to see a small "hello world"
> application compiled and executed on the command line with inconsistent
> options, with an explanation demonstrating that the inconsistency is
> required for making the application works.
>
> Martin
>
>
