If false positives are a problem, we could just have an empty default value. Users would simply have to configure something like: <agents>net.bytebuddy:byte-buddy-agent</agents> Also, a special auto-discover value (or another predefined value of course) could be used to discover agents in the test classpath and add them as agents automatically.
Le ven. 20 oct. 2023 à 21:29, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- ------------------------ Guillaume Nodet
