Le ven. 20 oct. 2023 à 22:00, Guillaume Nodet <gno...@apache.org> a écrit :

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

Isnt it what we have today with a different syntax? If the goal is just to
avoid a plugin declaration the part I dont like is we stay specific again
whereas we could be global for all plugin otherwise the issue remains for
most plugins.


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

Reply via email to