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 instead (of limited Maven ArtifactHandler): https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactType.java And plugins should just do what given Artifact's ArtifactType says, no more, no less. No heuristic, no "guesswork", or anything like that, just keep the simple stupid. Thanks T On Tue, Oct 24, 2023 at 7:42 AM Thomas Reinhardt <tho...@reinhardt.com> wrote: > > 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 > more. But right now it is basically unusable for us and part of it is > lacking maven support. The next big maven release should definitely > improve the support. One big problem is testing (and all the > implications with different classpaths etc) but that deserves its own > discussion I think. > > > > > > 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 ven. 20 oct. 2023 à 20:24, Henning Schmiedehausen < > > henn...@schmiedehausen.org> a écrit : > > > >> I think we will need to start rethinking dependencies more. A similar > >> problem exists with modules; the current heuristics to decide whether a > >> dependency goes on module path or classpath will start to become > painful in > >> the very near future. > >> > >> -h > >> > >> > >> On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell <bmarw...@apache.org> > >> wrote: > >> > >>> If you can still use it twice, works for me, too. > >>> > >>> Either way, you'd need it both as a dependency and as an agent. > >>> > >>> Another requirement Romain mentioned is the order of agent loading. > >> Mockito > >>> wants to be first, and others can come later. > >>> > >>> - Ben > >>> > >>> > >>> > >>> > >>> On Wed, 18 Oct 2023, 00:11 Tamás Cservenák, <ta...@cservenak.net> > wrote: > >>> > >>>> What about type=java-agent? Basically a new ArtifactHandler? > >>>> > >>>> See https://maven.apache.org/repositories/artifacts.html > >>>> > >>>> T > >>>> > >>>> On Tue, Oct 17, 2023, 23:54 Benjamin Marwell <bmarw...@apache.org> > >>> wrote: > >>>> > >>>>> Hey all, > >>>>> > >>>>> In a mockito issue, JDK maintainers suggested to differentiate > >> between > >>>>> agents and normal dependencies. Starting with JDK 21 already, this > >>> makes > >>>> a > >>>>> lot of sense: dynamic loading of agents will be a no-go. > >>>>> > >>>>> One suggestion was: > >>>>> > >>>>> <dependencies> > >>>>> <dependency> > >>>>> ... > >>>>> </dependency> > >>>>> <agents> > >>>>> <dependency> > >>>>> ... > >>>>> </dependency> > >>>>> </agents> > >>>>> </dependencies> > >>>>> > >>>>> Not sure if this is the best way, but this is something similar might > >>> be > >>>>> needed. > >>>>> Currently, the only way to handle agents is to add them manually to > >> the > >>>>> surefire argLine. To make things worse, a deoendency goal is needed > >>> until > >>>>> Romains PR is merged: > >>>>> https://github.com/apache/maven/pull/1281 > >>>>> > >>>>> Another issue is that a parent pom might not be able to easily define > >>>> this > >>>>> option. There were some concerns that part of the configuration > >> needed > >>> to > >>>>> be repeated in every module. > >>>>> > >>>>> So, I wrote Maven 5. > >>>>> Maven 4 is the stepping stone to the build/consumer pom. But this is > >> an > >>>>> extension. Not really a breaking change in terms of parsing, but in > >>> terms > >>>>> of building a project. Thus, it should go onto the roadmap. > >>>>> > >>>>> ... unless you want to keep the current status quo, which is also an > >>>>> option. But before making an argument here, I'd recommend reading the > >>>>> lengthy (sorry!) discussion on the mockito issue tracker. Since Karl > >>>> Heinz > >>>>> started the issue, I'd love to hear back from you, too. Link: > >>>>> https://github.com/mockito/mockito/issues/3037 > >>>>> > >>>>> If no discussion is needed at this point, let's keep this as a > >> reminder > >>>> for > >>>>> the next Apero and/or Maven 5 then. > >>>>> > >>>>> - Ben > >>>>> > >>>> > >>> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
