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 <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 à 21:05, Guillaume Nodet <gno...@apache.org> a écrit : > 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 list) if needed. > That would be very specific to surefire, but I'm not sure there are many > use cases... > > Guillaume > > Le ven. 20 oct. 2023, 20:44, Romain Manni-Bucau <rmannibu...@gmail.com> a > écrit : > > > 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. > > > > 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 > > > > > > > > > > > > > > > > > > > > >
