Re: Maven 5 pom extension for agents

Le 2023-11-02 à 00 h 31, Tamás Cservenák a écrit : Here is where I am currently: https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support It seems that I cannot add comment on that page, so below are my proposals: 1) Modify the explanation of the "jar" type. It

Re: Maven 5 pom extension for agents

Ps (seems i lost a paragraph): how does it work in consumer pom, breaks most consumers which will assume right a single jar cant be found twice in deps no? Le sam. 4 nov. 2023 à 14:39, Romain Manni-Bucau a écrit : > I still see it as abusing of extension to create sets. > Means you can only do

Re: Maven 5 pom extension for agents

I still see it as abusing of extension to create sets. Means you can only do it while it is jars - how would it work with .jmod for ext? Now the critical part: how do plugin know about it? Ie is it better to define a ton of potentially conflicting default names + add name config in all plugins

Re: Maven 5 pom extension for agents

Le 2023-11-04 à 14 h 02, Tamás Cservenák a écrit : What would a dependency type=jar, sources be? That represents two different files... Okay, it makes sense to avoid multi-types then. On a second though, even when the file is the same, some types are mutually exclusive (e.g. "classpath"

Re: Maven 5 pom extension for agents

No, imho a dependency cannot have two or more types: we are focused on this topic (jar vs module) but type is more than that, think sources. In former case we talk about same file (artifact.jar) but representing different thing (cp or mp candidate). What would a dependency type=jar, sources be?

Re: Maven 5 pom extension for agents

Le 2023-11-04 à 13 h 47, Romain Manni-Bucau a écrit : How does an artifact has 2 types (it is the main issue with this design)? I also thought about that. For an initial version, Tamas's proposal would work. For a solution that avoid repetition, maybe should allow a comma or

Re: Maven 5 pom extension for agents

Like this https://gist.github.com/cstamas/dd3795fd47f15a28d48a8c03fa9dd939 This is completely legal from mvn pov (no warning, unlike same artifact in two scopes) T On Sat, Nov 4, 2023, 13:48 Romain Manni-Bucau wrote: > How does an artifact has 2 types (it is the main issue with this design)?

Re: Maven 5 pom extension for agents

How does an artifact has 2 types (it is the main issue with this design)? Le sam. 4 nov. 2023 à 11:05, Tamás Cservenák a écrit : > So, just for fun, I used MIMA /w local mods (MIMA is vanilla mvn39 models + > resolver1) to resolve one of my demo modules: > (neglect the root type of

Re: Maven 5 pom extension for agents

Le 2023-11-03 à 21 h 30, Romain Manni-Bucau a écrit : The proposal would put the dependency on whatever path the 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,

Re: Maven 5 pom extension for agents

So, just for fun, I used MIMA /w local mods (MIMA is vanilla mvn39 models + resolver1) to resolve one of my demo modules: (neglect the root type of "dinosaur"...Also, this is really simplified, _resolving_ this graph would FAIL, as MIMA has no idea what "module" type is, as can be seen in GAVs,

Re: Maven 5 pom extension for agents

Well, I have to disagree... Maven Core has no idea what "add to classpath" means, and the flag is not even used in core. Same would stand for MP etc. Maven Core (simplified: the POM) tells WHAT IT IS only. Maven Plugin is the one who uses the core provided information to process things. So

Re: Maven 5 pom extension for agents

Yes, this is the part I find broken in maven design (even mvn3) 1nd hope we stop abusing. Also note it keeps the flag per maven module whereas we have a need per plugin. So first step is to fix plugin config to get them filters of artifacts per their "paths" and sounds like it will be sufficient,

Re: Maven 5 pom extension for agents

So, just to explain w/ code: In Maven3 ArtifactHandler (type=id selects a handler) looks like this: https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55 And you can spot the two boolean "lfags": addedToClasspath

Re: Maven 5 pom extension for agents

Well, even mvn3 works like it today, except it has "fixed set" of flags. All i did is opened up the number of possible flags, added MP (next to existing CP flag from mvn 3). Types were really eztensible in mvn3 as well, but less expressive with fixed set of flags. Basically even in mvn3, an

Re: Maven 5 pom extension for agents

Doesnt it mean you dont need type at all. I understand the idea to add new method in the handler but this is really a weird design and still blocked by the predefined set so user is still locked by design so not sure how it helps to rely on type. Le ven. 3 nov. 2023 à 21:44, Tamás Cservenák a

Re: Maven 5 pom extension for agents

Just 5 cents: Plugins (as "consumer of dependency") would NOT handle with type _directlty_, but the _flags_. So, if you look at this table (a bit outdated): https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8 m-compiler-p: handles artifacts flagged with CP, MP, AP m-javadoc-p:

Re: Maven 5 pom extension for agents

Le ven. 3 nov. 2023 à 20:55, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit : > > >> putting a dependency on the module-path of a non-JPMS application > >> such as Spring is okay > >> > > Is not ok for me and is a big hidden

Re: Maven 5 pom extension for agents

Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit : putting a dependency on the module-path of a non-JPMS application such as Spring is okay Is not ok for me and is a big hidden bug of current guess logic when not disabled IMHO, we should drop all that guess code probably. The current

Re: Maven 5 pom extension for agents

Le ven. 3 nov. 2023 à 17:50, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2023-11-03 à 16 h 45, Romain Manni-Bucau a écrit : > > > > The detail point you forget is that since this is a partial solution > > either nobody cares of it today and it will not be adopted more

Re: Maven 5 pom extension for agents

Le 2023-11-03 à 16 h 45, Romain Manni-Bucau a écrit : The detail point you forget is that since this is a partial solution either nobody cares of it today and it will not be adopted more than today (more later on that) or it will break in the future Is the proposal only partial because it

Re: Maven 5 pom extension for agents

Howdy, That said no issue, I will step down from this thread as you request, goal > was just to try to not push in a way which will likely not solve the > original issue and was hurting users by some projects having adopted this > solution (bundle). No, I did NOT ask you to "step down from this

Re: Maven 5 pom extension for agents

Le ven. 3 nov. 2023 à 16:17, Tamás Cservenák a écrit : > Howdy, > > @Romain, it seems it is not only me alone having difficulties to understand > your responses, that are almost always rejecting the idea. > > I asked you to create a counter example (not "recipe" in prose), you did > not. When I

Re: Maven 5 pom extension for agents

Howdy, @Romain, it seems it is not only me alone having difficulties to understand your responses, that are almost always rejecting the idea. I asked you to create a counter example (not "recipe" in prose), you did not. When I joined this thread, I said clearly "this is hardly gonna happen in

Re: Maven 5 pom extension for agents

Le 2023-11-02 à 20 h 07, Romain Manni-Bucau a écrit : as of today libs can't ignore classpath cause it stays the majority of consumers so it is "as if" in this thread IMHO. Maven can't ignore classpath. But for artifact producers, it is up to them to decide. They may target a niche market.

Re: Maven 5 pom extension for agents

Le jeu. 2 nov. 2023 à 19:49, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2023-11-02 à 17 h 35, Romain Manni-Bucau a écrit : > > > Now, do the same example but with app in a classpath centric build > > (spring boot, EE, ...) which consumes lib1 as a classpath jar even if

Re: Maven 5 pom extension for agents

Le 2023-11-02 à 17 h 35, Romain Manni-Bucau a écrit : Now, do the same example but with app in a classpath centric build (spring boot, EE, ...) which consumes lib1 as a classpath jar even if it is a module in its original pom (perfectly valid). Consuming lib1 on the classpath is *not*

Re: Maven 5 pom extension for agents

Le jeu. 2 nov. 2023 à 17:24, Tamás Cservenák a écrit : > Romain, > > Could you draft an example project that proves or at least showcases your > points? > It's probably me, but I don't get your responses :( > > WTH is "lifecycle of your project graph"? > > But really, could you draft an example

Re: Maven 5 pom extension for agents

Romain, Could you draft an example project that proves or at least showcases your points? It's probably me, but I don't get your responses :( WTH is "lifecycle of your project graph"? But really, could you draft an example project that showcases your points? T On Thu, Nov 2, 2023 at 2:08 PM

Re: Maven 5 pom extension for agents

Le jeu. 2 nov. 2023 à 13:59, Tamás Cservenák a écrit : > Howdy, > > "not upgrading maven" can simply be extrapolated to "not upgrading java", > so what are we talking about at all here? Imposing illogical requirements > really does not make sense. (today) I'm writing app A, and I'm depending

Re: Maven 5 pom extension for agents

Howdy, "not upgrading maven" can simply be extrapolated to "not upgrading java", so what are we talking about at all here? Imposing illogical requirements really does not make sense. The whole point of mvn4 is to allow progress at the same time not excluding the mvn3 universe (consumer POM).

Re: Maven 5 pom extension for agents

Just as a reminder: * type=module breaks downstream consumers not upgrading maven * transitivity is broken since everything ends in modulepath whereas in most cases you want it in the classpath So really we should move forward on something else than artifact definition as the sole solution if we

Re: Maven 5 pom extension for agents

Just to chime in to Martin thoughts: - yes, the default "type" is still "jar" (so if you omit type, "jar" is applied as today) - transitivity: yes, as I show above, project-impl [type=module] depends on project-api [type=module] so the whole tree lands on "modulepath". - override: exactly as

Re: Maven 5 pom extension for agents

Le 2023-11-02 à 12 h 53, Romain Manni-Bucau a écrit : You would also note that using "type" *forces* users to care about this separation too in an unexpected way. Type is an optional element. The use of module is a workaround for the heuristic rules sometime doing the wrong choice. But

Re: Maven 5 pom extension for agents

Le jeu. 2 nov. 2023 à 12:37, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2023-11-02 à 11 h 21, Romain Manni-Bucau a écrit : > > > you are right they are orthogonal in terms of design but as soon as > > you get the set notion you don't need the others and I prefer to not

Re: Maven 5 pom extension for agents

Le 2023-11-02 à 11 h 21, Romain Manni-Bucau a écrit : you are right they are orthogonal in terms of design but as soon as you get the set notion you don't need the others and I prefer to not multiply the way to do which is always confusing. It is not necessarily a multiplication of ways of

Re: Maven 5 pom extension for agents

@Tamas: when you import a type=module dependency, how do I get its module transitive deps or how do I not get it when it is imported as a jar? type=module => transitive modules=module so means you assume the original pom is deployed on central (this is really an assumption even with maven where it

Re: Maven 5 pom extension for agents

@Martin: you are right they are orthogonal in terms of design but as soon as you get the set notion you don't need the others and I prefer to not multiply the way to do which is always confusing. Since the dependency option does not work generally speaking, I'm clearly on the other side *if we

Re: Maven 5 pom extension for agents

Howdy, Unsure about your remark "you are still not solving the transitivity": As consume-module in Maven debug outputs this (but, debug shows only scope not type, as before whole universe was "jar"): [DEBUG] org.cstamas.maven.jpms.modular:consume-module:jar:1.0.0-SNAPSHOT [DEBUG]

Re: Maven 5 pom extension for agents

Le 2023-11-02 à 10 h 49, Romain Manni-Bucau a écrit : this assumes all plugins + runtimes will use the exact same option whereas this is generally not true so must be configured per mojo when forking and in jvm.config when not forking so I don't see any work done at dependency/artifact level

Re: Maven 5 pom extension for agents

Hi Martin, this assumes all plugins + runtimes will use the exact same option whereas this is generally not true so must be configured per mojo when forking and in jvm.config when not forking so I don't see any work done at dependency/artifact level working on jvm ecosystem. Romain Manni-Bucau

Re: Maven 5 pom extension for agents

Le 2023-10-29 à 21 h 36, Romain Manni-Bucau a écrit : Was referencing the options using module names, if you drop the dep or reference a package not supported by the module we should be able to fail. I do not want to distract this thread from the core issue (control on class-path versus

Re: Maven 5 pom extension for agents

Hi Tamas, You table shows exactly my point: you need to be able to compose dependencies sets (potentially named from user space) and you can *not* define types - or any similar solution - and let plugins get their config from there. If you don't you are not better than today and assume that in

Re: Maven 5 pom extension for agents

consumer POM _especially_ remains outside of project limits (again, is "just outside of" but not "inside" of a reactor), so unsure what should that solve... the "fat" thing gives you exactly this ability, so unsure what the problem here is? T On Tue, Oct 31, 2023 at 8:05 AM Romain Manni-Bucau

Re: Maven 5 pom extension for agents

Here is where I am currently: https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support T On Tue, Oct 31, 2023 at 12:21 AM Tamás Cservenák wrote: > Oh, and just as "dependency reduced pom", the flatten does not work within > the reactor _either_. > > In fact, the

Re: Maven 5 pom extension for agents

Le mar. 31 oct. 2023 à 00:22, Tamás Cservenák a écrit : > Oh, and just as "dependency reduced pom", the flatten does not work within > the reactor _either_. > This part should be solved with consumer pom but within the reactor you should get the same behavior in terms of dep with flattening

Re: Maven 5 pom extension for agents

Oh, and just as "dependency reduced pom", the flatten does not work within the reactor _either_. In fact, the existence of a flatten plugin per se is an IMHO sign that "something is wrong" here. Thanks T On Tue, Oct 31, 2023 at 12:08 AM Romain Manni-Bucau wrote: > Hmm, new types are not a

Re: Maven 5 pom extension for agents

Romain, the "fat" flag was always present, since Maven 3.0 (with introduction of resolver). Really, nothing new here. Even you already use it (without knowing). Resolver is (and was) abused currently (see my other mail), this is more to unleash its potential instead. T On Tue, Oct 31, 2023 at

Re: Maven 5 pom extension for agents

Hmm, new types are not a real option for that, it is fully the lifecycle (plugin chain thesz days since lifecycles are never rich enough and it depends too much on projects. Your fatjar example is not a type but the flatten plugin presence and it is really not a type cause it implies a specific

Re: Maven 5 pom extension for agents

... makes resolver STOP _whatever_ the referenced POM list as dependencies (basically does not matter, the node once collected will NOT dive into getting possible children). T On Mon, Oct 30, 2023 at 9:58 PM Tamás Cservenák wrote: > The fat* mechanism is already present even in maven 3.9, but

Re: Maven 5 pom extension for agents

The fat* mechanism is already present even in maven 3.9, but not so visible: https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L51 Is "fat" when this method returns true. Moreover, the new type would give you (as

Re: Maven 5 pom extension for agents

Howdy, The fat* is needed to STOP resolver resolving further external dependencies (or in-reactor ones), it gives you more control to _express_ this case to Maven. Typical case: - you have in reactor "uber" JAR built (with replace POM set) - hence, you deploy the rewritten POM, so for consumers

Re: Maven 5 pom extension for agents

I don't understand fatjar and fatmodule. Why would we need that? How would maven treat this different from a regular jar / module ? -h On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák wrote: > Howdy, > > The current draft of types we want to introduce (and packaging): >

Re: Maven 5 pom extension for agents

If the current standard type would be "dependency", this would work IMHO. It is not. It is "jar". This is perceived as "packaging", not a specific semantic type that represents "dependency"). A bom is "type == pom, scope == import" which is a special case. If this were "type == bom, scope ==

Re: Maven 5 pom extension for agents

the thing is modules are one example but you also have several plugin related dependencies (living doc one is a common example I hit and I workaround with provided or test but this is wrong, another one can be a generator plugin, but most common ones are assembler plugins where sets enable to

Re: Maven 5 pom extension for agents

Modules are just regular dependencies that need to end up on the module path instead of the classpath. Creating a new section in the pom (with all its pains, because it would not just be "modules" but also "moduleManagement", akin to "dependencyManagement") is IMHO a really bad idea. Also,

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 21:32, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2023-10-29 à 21 h 25, Romain Manni-Bucau a écrit : > > > Then you are back to the dependency set solution which is not the type > > solution and in this option the type is fully useless. > > >

Re: Maven 5 pom extension for agents

Le 2023-10-29 à 21 h 25, Romain Manni-Bucau a écrit : Then you are back to the dependency set solution which is not the type solution and in this option the type is fully useless. Maybe we would need a wiki page explaining how the DependencySet approach would apply to JPMS. At this time, the

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 21:21, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2023-10-29 à 20 h 58, Romain Manni-Bucau a écrit : > > > > Is it really different since part of options are related so either we > > align on the jvm making using maven location mapping easier or

Re: Maven 5 pom extension for agents

Le 2023-10-29 à 20 h 58, Romain Manni-Bucau a écrit : Is it really different since part of options are related so either we align on the jvm making using maven location mapping easier or we fully integrate but means we must detect errors in options which is for me a hard task Why do we

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 21:11, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2023-10-29 à 18 h 05, Romain Manni-Bucau a écrit : > > > > *type* is not a good solution for jpms, only dependency can help > > > Since we are talking about specifying the type of dependencies, I

Re: Maven 5 pom extension for agents

Le 2023-10-29 à 18 h 05, Romain Manni-Bucau a écrit : *type* is not a good solution for jpms, only dependency can help Since we are talking about specifying the type of dependencies, I do not understand well what would not work exactly? One thing that we may need is a way for a dependency

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 20:49, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2023-10-29 à 16 h 10, Tamás Cservenák a écrit : > > > The current draft of types we want to introduce (and packaging): > > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8 > > >

Re: Maven 5 pom extension for agents

Le 2023-10-29 à 16 h 54, Tamás Cservenák a écrit : History shows that having lengthy ML discussions usually dies off into silence. I think we could use Google Meet, where the 60min limit is actually even welcome, to not get into marathon meetings and stay focused (or continue on the next

Re: Maven 5 pom extension for agents

Le 2023-10-29 à 16 h 10, Tamás Cservenák a écrit : The current draft of types we want to introduce (and packaging): https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8 Thanks! I fully support this proposal, as I believe it can resolve the most blocking issue in using JPMS with

Re: Maven 5 pom extension for agents

Le 2023-10-29 à 00 h 21, Tamás Cservenák a écrit : Unsure from where you get that, but is wrong conclusion. Declaring a dependency with test-jar causes Maven to download a different JAR file. So I assumed that it was a general behaviour. However looking at the link you provided [1], it seems

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 16:10, Tamás Cservenák a écrit : > Howdy, > > The current draft of types we want to introduce (and packaging): > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8 > > === > > Romain, I don't understand your "This is wrong, downstream is either module > or

Re: Maven 5 pom extension for agents

...and one more thing: Sorry for bombing this thread, and I see we have clear counter-points for each other, so here is a proposal: long time ago there was an institution of "Maven Hangouts", where regular (or irregular) face2face meetings were held between not only Maven devs, but any interested

Re: Maven 5 pom extension for agents

=== Digression: I _think_ we have a misconception present, so excuse me for this digression, but I have to write it down here, just to make things clear. Is basically represented by this issue https://issues.apache.org/jira/browse/MNG-7373 tl;dr: It is common misconception, that Maven works like

Re: Maven 5 pom extension for agents

Howdy, The current draft of types we want to introduce (and packaging): https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8 === Romain, I don't understand your "This is wrong, downstream is either module or jar", as it was actually you and your example that mentioned "once put it

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák a écrit : > Howdy, > > So to return to the "root" idea (of Maven), Maven is "declarative", where > users should declare what they want, it should most certainly not "guess" > what user intent is. As long as we have "magical implicit guesswork" (like

Re: Maven 5 pom extension for agents

Howdy, So to return to the "root" idea (of Maven), Maven is "declarative", where users should declare what they want, it should most certainly not "guess" what user intent is. As long as we have "magical implicit guesswork" (like that in javadoc) present in process, it is bad, as that means we do

Re: Maven 5 pom extension for agents

Romain, it's probably me, but I have no faintest idea what you are trying to say... What do you mean by "standalone"? What is the wrong packaging? Why will I lose the ability to specify where it goes? Also, as I said before, if you list project/deps gav:jar AND gav:module, you would be putting

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 12:44, Tamás Cservenák a écrit : > 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

Re: Maven 5 pom extension for agents

And just realized something: by using dependencies as above, we even fix an issue https://issues.apache.org/jira/browse/MCOMPILER-496 Typical problem: a multi reactor build contains an annotation processor, and then that processor needs to be used in subsequent modules. Maven is unaware of

Re: Maven 5 pom extension for agents

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,

Re: Maven 5 pom extension for agents

Le dim. 29 oct. 2023 à 12:12, Tamás Cservenák 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

Re: Maven 5 pom extension for agents

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. Thanks T On Sun, Oct 29, 2023 at 8:42 AM Romain Manni-Bucau wrote: > Interesting but

Re: Maven 5 pom extension for agents

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 a écrit : > > where properties are totally extensible, > > And if

Re: Maven 5 pom extension for agents

> 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:

Re: Maven 5 pom extension for agents

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

Re: Maven 5 pom extension for agents

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

Re: Maven 5 pom extension for agents

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

Re: Maven 5 pom extension for agents

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

Re: Maven 5 pom extension for agents

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

Re: Maven 5 pom extension for agents

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 element inside ? If yes, then specifying a different type causes Maven to download a different JAR, without changing

Re: Maven 5 pom extension for agents

Howdy, I still see these just as new dependency types: "module", "agent", "doclet", and so on. Also, for "other end" (producing) we'd need new packaging as well: "module" at least for example. ArtifactHandler would need to be extended as well, or better, complete adopt Resolver ArtifactType

Re: Maven 5 pom extension for agents

On 20/10/2023 20:43, Romain Manni-Bucau wrote: Can be the way to define the lookup, an heuristic will never work by design...that said, on my side, not sure JPMS will be widely adopted anytime soon so can be a false problem. This is a chicken and egg problem. My company would love to use JPMS

Re: Maven 5 pom extension for agents

the point is that if you open, as you mention, a system you always end up having compatibility matrix - no plugin except yours will read your meta - so this becomes a nightmare for end users, whereas when there is a standard way - no built-in extensibility - then you never have this issue and it

Re: Maven 5 pom extension for agents

> Exactly the opposite right? of what? > If we do that then a particular plugin can use that but all others > will don't read it right Whats "right" depends on the context, at least one don't need a new discussion/extension for each use case, also most of these discussions cover the needs of

Re: Maven 5 pom extension for agents

Le 2023-10-23 à 11 h 48, Romain Manni-Bucau a écrit : (…snip…) but still, I don't think we need that for the mentionned issue. For agents, alternatives have indeed been proposed in this thread. But some form of usage specification (either as element or composition) will be needed anyway at

Re: Maven 5 pom extension for agents

Le 2023-10-23 à 11 h 28, Romain Manni-Bucau a écrit : anyway, if we go with the "usages" path we can want to enable a definition containing wrapped in a scope () this way you can reference a dependency set in a plugin or even main dependencies (import all). Maybe, but the element

Re: Maven 5 pom extension for agents

Le lun. 23 oct. 2023 à 11:31, Christoph Läubrich a écrit : > I always wished there was support for generic element in > this can then be literally used for everything in an > extensible way. > > > > ... usual stuff ... > > module > ... > > > > Exactly

Re: Maven 5 pom extension for agents

I always wished there was support for generic element in this can then be literally used for everything in an extensible way. ... usual stuff ... module ... Am 23.10.23 um 11:24 schrieb Martin Desruisseaux: Le 2023-10-20 à 20 h 43, Romain Manni-Bucau a

Re: Maven 5 pom extension for agents

well chicken-egg or just lack of need (from my window the people you reference are very few and mainly testers) anyway, if we go with the "usages" path we can want to enable a < dependenciesSet> definition containing wrapped in a scope () this way you can reference a dependency set in a

Re: Maven 5 pom extension for agents

Le 2023-10-20 à 20 h 43, Romain Manni-Bucau a écrit : that said, on my side, not sure JPMS will be widely adopted anytime soon so can be a false problem. I think that this is a chicken-and-egg problem: some peoples renounce to JPMS because tools support is poor (at least in Maven and

Re: Maven 5 pom extension for agents

Le ven. 20 oct. 2023 à 22:00, Guillaume Nodet a écrit : > If false positives are a problem, we could just have an empty default > value. > Users would simply have to configure something like: >net.bytebuddy:byte-buddy-agent > Also, a special auto-discover value (or another predefined value

Re: Maven 5 pom extension for agents

All this discussion, but I honestly find the idea of mockito creating a plugin like jacoco a cleaner solution. Are there any drawbacks? It worked for a long time now. On Fri, 20 Oct 2023, 22:00 Guillaume Nodet, wrote: > If false positives are a problem, we could just have an empty default >

Re: Maven 5 pom extension for agents

If false positives are a problem, we could just have an empty default value. Users would simply have to configure something like: net.bytebuddy:byte-buddy-agent Also, a special auto-discover value (or another predefined value of course) could be used to discover agents in the test classpath

Re: Maven 5 pom extension for agents

Guess we would get a lot of false positive and surefire already has it so not sure it would help to simplify, complexity seems 1-1 :s Romain Manni-Bucau @rmannibucau | Blog | Old Blog |

Re: Maven 5 pom extension for agents

Not sure agents are widely used during the build either. I wonder if surefire should be given a list of artifacts coordinates that it would consider as agents if they are in the test class path... The default value would contain bytebuddy, but it could be changed (and ordered considered in that

  1   2   >