Can you provide a real example? As I don't quite understand, so you would
have a dependency (a fat spring boot jar), that is a "module dep is a
module in compile/some tests but not at runtime (spring boot fatjar)". So
all this within one maven module (compile/test/runtime?).

T

On Sun, Oct 29, 2023 at 12:37 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Le dim. 29 oct. 2023 à 12:12, Tamás Cservenák <ta...@cservenak.net> a
> écrit :
>
> > Given that jar (spring boot fatjar) is once this once that, you refer to
> it
> > in deps as needed:
> > in one module is fat:jar in other is fat:module, as needed.
> >
> > You are the one explicitly telling what you want.
> >
>
> In my example (and spring boot is not the only one, wars are another common
> one, or any java command more generally) the two modules are a single
> one....and no doing two module would be worse than what we have today.
>
>
> > Thanks
> > T
> >
> > On Sun, Oct 29, 2023 at 8:42 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Interesting but common case: a module dep is a module in compile/some
> > tests
> > > but not at runtime (spring boot fatjar).
> > > Back to explicit config in plugins and drop new module type?
> > >
> > > Le dim. 29 oct. 2023 à 07:46, Christoph Läubrich <m...@laeubi-soft.de>
> a
> > > écrit :
> > >
> > > >  > where properties are totally extensible,
> > > >
> > > > And if now I could supply additional properties from the xml-model
> ...
> > > >
> > > > Am 29.10.23 um 00:40 schrieb Tamás Cservenák:
> > > > > And finally this is hardly gonna happen in Maven 3 lifespan, as
> sadly
> > > > > ArtifactHandler of it is quite limited: has only one flag:
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55
> > > > >
> > > > > Sadly, Maven4 Type continued on this path, but luckily we are in
> > alpha,
> > > > and
> > > > > will propose a PR to type that currently looks like this:
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80
> > > > >
> > > > > And would rework it to be more (if not same as) the resolver
> > > > ArtifactType:
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactType.java#L63
> > > > >
> > > > > where properties are totally extensible, for example "add to
> > classpath"
> > > > is
> > > > > really just one flag (added by ArifactType):
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactProperties.java#L58
> > > > >
> > > > > So, ArtifactProperties could be extended with
> > "constitutesModulePath",
> > > > > "agent" and so on... To make this really extensible.
> > > > >
> > > > > In maven3 the ArtifactHandler this makes it impossible. There is
> > still
> > > > hope
> > > > > in Maven 4
> > > > >
> > > > > Thanks
> > > > > T
> > > > >
> > > > >
> > > > > On Sun, Oct 29, 2023 at 12:32 AM Tamás Cservenák <
> > ta...@cservenak.net>
> > > > > wrote:
> > > > >
> > > > >> This would also mean, that if you have a dependency that is
> already
> > > JPMS
> > > > >> modularized (is java9+ and has module-info), then:
> > > > >>
> > > > >> a) if you declare it as type="jar" it means you want to put it on
> > > > >> classpath (use it as "plain old jar")
> > > > >> b) if you declare it as type="module" it means you want it on
> > > modulepath
> > > > >> etc
> > > > >>
> > > > >> On Sun, Oct 29, 2023 at 12:30 AM Tamás Cservenák <
> > ta...@cservenak.net
> > > >
> > > > >> wrote:
> > > > >>
> > > > >>> Of course, the logic HOW and WHAT to make with these would be
> > needed
> > > to
> > > > >>> be added to javadoc, compiler and all the plugins that need to
> > > > distinguish.
> > > > >>> But this would stop any need for any heuristic, guesswork,
> > > smart-ness,
> > > > >>> etc...
> > > > >>>
> > > > >>> OTOH, if we introduce new packaging lifecycle "module" (so a
> > project
> > > > that
> > > > >>> builds module would do project/packaging=module), it could nicely
> > > > enforce
> > > > >>> things like:
> > > > >>> - prevent non allowed packages
> > > > >>> - enforce presence of module-info.class (maybe some light
> > > verification)
> > > > >>> - ensure project is Java9+ etc
> > > > >>>
> > > > >>> Most of this was somewhat done in Takari Lifecycle (also with
> > custom
> > > > >>> packaging like "takari-jar" was).
> > > > >>>
> > > > >>>
> > > > >>> T
> > > > >>>
> > > > >>> On Sun, Oct 29, 2023 at 12:26 AM Tamás Cservenák <
> > > ta...@cservenak.net>
> > > > >>> wrote:
> > > > >>>
> > > > >>>> So, basically this is what am proposing:
> > > > >>>>
> https://gist.github.com/cstamas/76f262538b5a11f6ee23d6d8c86f10ec
> > > > >>>>
> > > > >>>> Basically, Maven core (and hence plugins) could distinguish
> among
> > > > >>>> different "types" of dependencies (while would all still be
> plain
> > > > JARs).
> > > > >>>> So "jar" would be put on classpath, "module" on module path,
> > "agent"
> > > > >>>> would got special treatment and so on.
> > > > >>>>
> > > > >>>> Point is to _differentiate_.
> > > > >>>>
> > > > >>>> T
> > > > >>>>
> > > > >>>> On Sun, Oct 29, 2023 at 12:21 AM Tamás Cservenák <
> > > ta...@cservenak.net
> > > > >
> > > > >>>> wrote:
> > > > >>>>
> > > > >>>>> Unsure from where you get that, but is wrong conclusion.
> > > > >>>>>
> > > > >>>>> You can have dep1:jar, dep2:module, dep3:agent and all 3 MAY
> > > > >>>>> (ArtifactHandler dependent, assuming "jar", "module" and
> "agent"
> > > > artifact
> > > > >>>>> handlers all return extension=jar) refer to the same JAR file
> in
> > > > your local
> > > > >>>>> repository.
> > > > >>>>>
> > > > >>>>> Type merely adds "semantics" WHAT is it about, HOW to make use
> of
> > > it.
> > > > >>>>> Please see
> > > > >>>>>
> > > >
> > >
> >
> https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension
> > > > >>>>>
> > > > >>>>> Thanks
> > > > >>>>> T
> > > > >>>>>
> > > > >>>>> On Sun, Oct 29, 2023 at 12:17 AM Martin Desruisseaux <
> > > > >>>>> martin.desruisse...@geomatys.com> wrote:
> > > > >>>>>
> > > > >>>>>> Le 2023-10-28 à 22 h 54, Tamás Cservenák a écrit :
> > > > >>>>>>
> > > > >>>>>>> I still see these just as new dependency types: "module",
> > > "agent",
> > > > >>>>>>> "doclet", and so on.
> > > > >>>>>>>
> > > > >>>>>> Does "dependency type" means the <type> element inside
> > > <dependency>?
> > > > >>>>>> If
> > > > >>>>>> yes, then specifying a different type causes Maven to
> download a
> > > > >>>>>> different JAR, without changing the kind of path (class path
> > > versus
> > > > >>>>>> module path) where the JAR is put. The proposed <usage>
> element
> > > (or
> > > > >>>>>> whatever equivalent alternatives) has the opposite semantic:
> it
> > > does
> > > > >>>>>> not
> > > > >>>>>> change the JAR to download, but put it on a different kind of
> > > path.
> > > > >>>>>>
> > > > >>>>>>       Martin
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > ---------------------------------------------------------------------
> > > > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >>>>>>
> > > > >>>>>>
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
>

Reply via email to