You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Cédric Champeau <ce...@gmail.com> on 2021/09/23 08:54:17 UTC
Alter configuration of another mojo
Hi folks,
I'm the maintainer of the GraalVM native build tools plugins for Maven and
Gradle. In the next release, we're moving to JUnit Platform 5.8, which now
integrates a "unique test id tracker", which before used to be implemented
in this plugin suite.
The goal of this ID tracker is to collect _unique_ test IDs for every test,
so that we can build a native image which would execute the same tests in
native mode. In other words, we first execute the tests in "JVM" mode,
using the surefire plugin, then there's a native image being built which
includes the tests and uses the information from the JVM execution to tell
which tests to execute in the native mode (that's because traditional test
discovery mechanisms don't work in a native executable).
Before JUnit 5.8, the listener which collects test ids used to live in the
"junit-platform-native" dependency, and because it did so, the sole fact of
adding this dependency was enough to trigger the listener. That was a
temporary solution until JUnit actually *bundles* this listener, and that's
where things get more complicated.
Starting with the 5.8 release, the listener is embedded into JUnit. This
means we can remove it from the "junit-platform-native" dependency [1].
However, it also means that there must be a way to opt-in, because most
users don't need this listener active. Therefore, JUnit requires the
"junit.platform.listeners.uid.tracking.enabled" system property to be set.
This means, in practice, that IF the native maven plugin is applied, THEN
the surefire mojo needs to be configured to set this property. It's an
implementation detail that users shouldn't have to worry about. For Gradle
this was trivial to implement because we can just react to the presence of
the native plugin and reconfigure the test task to add this system
property. For Maven, this proves quite challenging.
Currently, the only way I found is to have the user explicitly add this
system property to the surefire mojo:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M5</version>
<configuration>
<systemProperties>
<junit.platform.listeners.uid.tracking.enabled>true</junit.platform.listeners.uid.tracking.enabled>
</systemProperties>
</configuration>
</plugin>
This is certainly not nice, because as I said, the user shouldn't care:
because we apply the native plugin, we *know* that we need that listener.
Therefore I'm looking for ways to automatically alter the configuration of
the surefire plugin if the native plugin is applied. More importantly, this
is a breaking change since upgrading the plugin now requires a redundant
system property to be set.
I found that I could do this in the following situations:
- if my mojo runs _before_ the tests: this is not possible, since I need
the results of the test execution to get the list of tests
- using a lifecycle extension: it seems doable, but then I'm replacing one
problem with another: the user has to register the extension, either by
updating the POM file or adding it to their extensions. This, again, is a
no-go since we want this to be transparent.
Last but not least, I'm not mentioning that there's a 2d property which
would ideally need to be set too, which is the directory where those test
ids are dumped. By default it uses the target directory today, but this is
causing reliability issues, unless users do clean on every run. So it would
be great to be able to configure a *unique* directory per session. One
problem at a time, though.
All in all, is there any other way to do what I need that I'm missing?
Thanks for your help,
[1] https://github.com/graalvm/native-build-tools/issues/131
Re: Alter configuration of another mojo
Posted by Mantas Gridinas <mg...@gmail.com>.
Could that be combined with default mojo executions? Iirc you dont have to
explicitly configure some plugins so they would execute their goals
depending on lifecycle.
On Fri, Sep 24, 2021, 09:25 Maarten Mulders <mt...@apache.org> wrote:
> IIRC, that's how JaCoCo Maven Plugin [1] works as well: you have to
> configure two executions. The first one sets up the Java agent, the
> other one processes the collected data and writes a report.
>
> That's not to say "this is the way", but people may already be used to
> this kind of setup.
>
> HTH,
>
> Maarten
>
>
> [1] https://www.eclemma.org/jacoco/trunk/doc/maven.html
>
> On 23/09/2021 17:49, Lasse Lindqvist wrote:
> > They would need two executions yes, but they would not need to really
> know
> > about how surefire works with it. Native build tools plugin could in its
> > own docs explain that that execution is needed if junit tests are to be
> run
> > again, and the user would not have to touch the configurations of other
> > plugins.
> >
> > to 23. syysk. 2021 klo 18.46 Cédric Champeau (cedric.champeau@gmail.com)
> > kirjoitti:
> >
> >> Possibly, but as far as I understand it would just move the problem to a
> >> different location, since the user would have to declare the 2d
> execution,
> >> no? Something which is important is that I'm trying to avoid a breaking
> >> change, that is to say that there are existing POM files which work
> today
> >> that I don't want to break once they upgrade the plugin version.
> >>
> >> Le jeu. 23 sept. 2021 à 17:29, Lasse Lindqvist <
> >> lasse.k.lindqvist@gmail.com>
> >> a écrit :
> >>
> >>> Perhaps one way to make it so that users don't need to touch Surefire
> is
> >> to
> >>> have two executions for your plugin, the first one being in maybe
> >>> validation phase and doing
> >>>
> >>> // inject the project
> >>> @Parameter(defaultValue = "${project}")
> >>> private org.apache.maven.project.MavenProject project;
> >>>
> >>> ...
> >>>
> >>>
> >>
> project.getProperties().setProperty("junit.platform.listeners.uid.tracking.enabled",
> >>> "true");
> >>>
> >>> Not sure if this works, but if it does it would allow the users to
> >>> only configure one plugin.
> >>>
> >>>
> >>> to 23. syysk. 2021 klo 18.04 Cédric Champeau (
> cedric.champeau@gmail.com)
> >>> kirjoitti:
> >>>
> >>>> Thanks, but I totally disagree with you. The evidence that it's an
> >>>> implementation detail is that the previous version did NOT need any
> >> user
> >>> to
> >>>> configure anything: it just works and nobody complained that it was
> >>>> "magic": it just did what it was supposed to do. The fact that I
> cannot
> >>>> configure properly the JUnit engine and that as a workaround you have
> >> to
> >>>> ask the _user_ to do it is a PITA. That's the same for the build
> >>> directory:
> >>>> I can of course use different timestamps, but that again puts the
> >> burden
> >>> to
> >>>> the user when they shouldn't have to care: their builds should be
> >> correct
> >>>> _whatever configuration_ they use.
> >>>>
> >>>> Le jeu. 23 sept. 2021 à 15:48, Mantas Gridinas <mg...@gmail.com>
> a
> >>>> écrit :
> >>>>
> >>>>>> This means, in practice, that IF the native maven plugin is
> >> applied,
> >>>> THEN
> >>>>>> the surefire mojo needs to be configured to set this property. It's
> >>> an
> >>>>>> implementation detail that users shouldn't have to worry about. For
> >>>>> Gradle
> >>>>>> this was trivial to implement because we can just react to the
> >>> presence
> >>>>> of
> >>>>>> the native plugin and reconfigure the test task to add this system
> >>>>>> property. For Maven, this proves quite challenging.
> >>>>>
> >>>>> I'd argue otherwise. Users should be cognizant of what magical
> >> changes
> >>>> are
> >>>>> applied to their build processes. But to each their own.
> >>>>>
> >>>>> As for unique directory, why not utilize project.build.directory
> >>> property
> >>>>> that maven provides[1]? A quick workaround would be overriding it in
> >>>>> specific profile (or commandline) to include build timestamp. Ex
> >>>>>
> >>>>> ${project.basedir}/target-${maven.build.timestamp}[2]
> >>>>>
> >>>>> The above would ensure that every build is given a unique directory,
> >>>>> regardless of goals that you run. Though I'd put that behind a
> >> profile
> >>>> or a
> >>>>> commandline parameter, rather than encourage users to override the
> >>>> default
> >>>>> build directory. Not to mention this will probably break clean plugin
> >>>> since
> >>>>> it depends on project.build.directory. To fix that you could include
> >>>>> fileSets property under clean plugin's goal configuration[3] and
> >>>> configure
> >>>>> it to delete all directories that have prefix of
> >>>>> ${project.basedir)/target-.
> >>>>>
> >>>>> [1]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://maven.apache.org/pom.html#:~:text=%3Cdirectory%3E%24%7Bproject.basedir%7D/target%3C/directory%3E
> >>>>> [2]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#available-variables
> >>>>> [3]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Thu, Sep 23, 2021 at 11:54 AM Cédric Champeau <
> >>>>> cedric.champeau@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi folks,
> >>>>>>
> >>>>>> I'm the maintainer of the GraalVM native build tools plugins for
> >>> Maven
> >>>>> and
> >>>>>> Gradle. In the next release, we're moving to JUnit Platform 5.8,
> >>> which
> >>>>> now
> >>>>>> integrates a "unique test id tracker", which before used to be
> >>>>> implemented
> >>>>>> in this plugin suite.
> >>>>>>
> >>>>>> The goal of this ID tracker is to collect _unique_ test IDs for
> >> every
> >>>>> test,
> >>>>>> so that we can build a native image which would execute the same
> >>> tests
> >>>> in
> >>>>>> native mode. In other words, we first execute the tests in "JVM"
> >>> mode,
> >>>>>> using the surefire plugin, then there's a native image being built
> >>>> which
> >>>>>> includes the tests and uses the information from the JVM execution
> >> to
> >>>>> tell
> >>>>>> which tests to execute in the native mode (that's because
> >> traditional
> >>>>> test
> >>>>>> discovery mechanisms don't work in a native executable).
> >>>>>>
> >>>>>> Before JUnit 5.8, the listener which collects test ids used to live
> >>> in
> >>>>> the
> >>>>>> "junit-platform-native" dependency, and because it did so, the sole
> >>>> fact
> >>>>> of
> >>>>>> adding this dependency was enough to trigger the listener. That
> >> was a
> >>>>>> temporary solution until JUnit actually *bundles* this listener,
> >> and
> >>>>> that's
> >>>>>> where things get more complicated.
> >>>>>>
> >>>>>> Starting with the 5.8 release, the listener is embedded into JUnit.
> >>>> This
> >>>>>> means we can remove it from the "junit-platform-native" dependency
> >>> [1].
> >>>>>> However, it also means that there must be a way to opt-in, because
> >>> most
> >>>>>> users don't need this listener active. Therefore, JUnit requires
> >> the
> >>>>>> "junit.platform.listeners.uid.tracking.enabled" system property to
> >> be
> >>>>> set.
> >>>>>>
> >>>>>> This means, in practice, that IF the native maven plugin is
> >> applied,
> >>>> THEN
> >>>>>> the surefire mojo needs to be configured to set this property. It's
> >>> an
> >>>>>> implementation detail that users shouldn't have to worry about. For
> >>>>> Gradle
> >>>>>> this was trivial to implement because we can just react to the
> >>> presence
> >>>>> of
> >>>>>> the native plugin and reconfigure the test task to add this system
> >>>>>> property. For Maven, this proves quite challenging.
> >>>>>>
> >>>>>> Currently, the only way I found is to have the user explicitly add
> >>> this
> >>>>>> system property to the surefire mojo:
> >>>>>>
> >>>>>> <plugin>
> >>>>>> <groupId>org.apache.maven.plugins</groupId>
> >>>>>> <artifactId>maven-surefire-plugin</artifactId>
> >>>>>> <version>3.0.0-M5</version>
> >>>>>> <configuration>
> >>>>>> <systemProperties>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> <junit.platform.listeners.uid.tracking.enabled>true</junit.platform.listeners.uid.tracking.enabled>
> >>>>>> </systemProperties>
> >>>>>> </configuration>
> >>>>>> </plugin>
> >>>>>>
> >>>>>>
> >>>>>> This is certainly not nice, because as I said, the user shouldn't
> >>> care:
> >>>>>> because we apply the native plugin, we *know* that we need that
> >>>> listener.
> >>>>>> Therefore I'm looking for ways to automatically alter the
> >>> configuration
> >>>>> of
> >>>>>> the surefire plugin if the native plugin is applied. More
> >>> importantly,
> >>>>> this
> >>>>>> is a breaking change since upgrading the plugin now requires a
> >>>> redundant
> >>>>>> system property to be set.
> >>>>>>
> >>>>>> I found that I could do this in the following situations:
> >>>>>>
> >>>>>> - if my mojo runs _before_ the tests: this is not possible, since I
> >>>> need
> >>>>>> the results of the test execution to get the list of tests
> >>>>>> - using a lifecycle extension: it seems doable, but then I'm
> >>> replacing
> >>>>> one
> >>>>>> problem with another: the user has to register the extension,
> >> either
> >>> by
> >>>>>> updating the POM file or adding it to their extensions. This,
> >> again,
> >>>> is a
> >>>>>> no-go since we want this to be transparent.
> >>>>>>
> >>>>>> Last but not least, I'm not mentioning that there's a 2d property
> >>> which
> >>>>>> would ideally need to be set too, which is the directory where
> >> those
> >>>> test
> >>>>>> ids are dumped. By default it uses the target directory today, but
> >>> this
> >>>>> is
> >>>>>> causing reliability issues, unless users do clean on every run. So
> >> it
> >>>>> would
> >>>>>> be great to be able to configure a *unique* directory per session.
> >>> One
> >>>>>> problem at a time, though.
> >>>>>>
> >>>>>> All in all, is there any other way to do what I need that I'm
> >>> missing?
> >>>>>>
> >>>>>> Thanks for your help,
> >>>>>>
> >>>>>> [1] https://github.com/graalvm/native-build-tools/issues/131
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> // Mantas
> >>>>>
> >>>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Alter configuration of another mojo
Posted by Maarten Mulders <mt...@apache.org>.
IIRC, that's how JaCoCo Maven Plugin [1] works as well: you have to
configure two executions. The first one sets up the Java agent, the
other one processes the collected data and writes a report.
That's not to say "this is the way", but people may already be used to
this kind of setup.
HTH,
Maarten
[1] https://www.eclemma.org/jacoco/trunk/doc/maven.html
On 23/09/2021 17:49, Lasse Lindqvist wrote:
> They would need two executions yes, but they would not need to really know
> about how surefire works with it. Native build tools plugin could in its
> own docs explain that that execution is needed if junit tests are to be run
> again, and the user would not have to touch the configurations of other
> plugins.
>
> to 23. syysk. 2021 klo 18.46 Cédric Champeau (cedric.champeau@gmail.com)
> kirjoitti:
>
>> Possibly, but as far as I understand it would just move the problem to a
>> different location, since the user would have to declare the 2d execution,
>> no? Something which is important is that I'm trying to avoid a breaking
>> change, that is to say that there are existing POM files which work today
>> that I don't want to break once they upgrade the plugin version.
>>
>> Le jeu. 23 sept. 2021 à 17:29, Lasse Lindqvist <
>> lasse.k.lindqvist@gmail.com>
>> a écrit :
>>
>>> Perhaps one way to make it so that users don't need to touch Surefire is
>> to
>>> have two executions for your plugin, the first one being in maybe
>>> validation phase and doing
>>>
>>> // inject the project
>>> @Parameter(defaultValue = "${project}")
>>> private org.apache.maven.project.MavenProject project;
>>>
>>> ...
>>>
>>>
>> project.getProperties().setProperty("junit.platform.listeners.uid.tracking.enabled",
>>> "true");
>>>
>>> Not sure if this works, but if it does it would allow the users to
>>> only configure one plugin.
>>>
>>>
>>> to 23. syysk. 2021 klo 18.04 Cédric Champeau (cedric.champeau@gmail.com)
>>> kirjoitti:
>>>
>>>> Thanks, but I totally disagree with you. The evidence that it's an
>>>> implementation detail is that the previous version did NOT need any
>> user
>>> to
>>>> configure anything: it just works and nobody complained that it was
>>>> "magic": it just did what it was supposed to do. The fact that I cannot
>>>> configure properly the JUnit engine and that as a workaround you have
>> to
>>>> ask the _user_ to do it is a PITA. That's the same for the build
>>> directory:
>>>> I can of course use different timestamps, but that again puts the
>> burden
>>> to
>>>> the user when they shouldn't have to care: their builds should be
>> correct
>>>> _whatever configuration_ they use.
>>>>
>>>> Le jeu. 23 sept. 2021 à 15:48, Mantas Gridinas <mg...@gmail.com> a
>>>> écrit :
>>>>
>>>>>> This means, in practice, that IF the native maven plugin is
>> applied,
>>>> THEN
>>>>>> the surefire mojo needs to be configured to set this property. It's
>>> an
>>>>>> implementation detail that users shouldn't have to worry about. For
>>>>> Gradle
>>>>>> this was trivial to implement because we can just react to the
>>> presence
>>>>> of
>>>>>> the native plugin and reconfigure the test task to add this system
>>>>>> property. For Maven, this proves quite challenging.
>>>>>
>>>>> I'd argue otherwise. Users should be cognizant of what magical
>> changes
>>>> are
>>>>> applied to their build processes. But to each their own.
>>>>>
>>>>> As for unique directory, why not utilize project.build.directory
>>> property
>>>>> that maven provides[1]? A quick workaround would be overriding it in
>>>>> specific profile (or commandline) to include build timestamp. Ex
>>>>>
>>>>> ${project.basedir}/target-${maven.build.timestamp}[2]
>>>>>
>>>>> The above would ensure that every build is given a unique directory,
>>>>> regardless of goals that you run. Though I'd put that behind a
>> profile
>>>> or a
>>>>> commandline parameter, rather than encourage users to override the
>>>> default
>>>>> build directory. Not to mention this will probably break clean plugin
>>>> since
>>>>> it depends on project.build.directory. To fix that you could include
>>>>> fileSets property under clean plugin's goal configuration[3] and
>>>> configure
>>>>> it to delete all directories that have prefix of
>>>>> ${project.basedir)/target-.
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>>
>>>
>> https://maven.apache.org/pom.html#:~:text=%3Cdirectory%3E%24%7Bproject.basedir%7D/target%3C/directory%3E
>>>>> [2]
>>>>>
>>>>>
>>>>
>>>
>> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#available-variables
>>>>> [3]
>>>>>
>>>>>
>>>>
>>>
>> https://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 23, 2021 at 11:54 AM Cédric Champeau <
>>>>> cedric.champeau@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>> I'm the maintainer of the GraalVM native build tools plugins for
>>> Maven
>>>>> and
>>>>>> Gradle. In the next release, we're moving to JUnit Platform 5.8,
>>> which
>>>>> now
>>>>>> integrates a "unique test id tracker", which before used to be
>>>>> implemented
>>>>>> in this plugin suite.
>>>>>>
>>>>>> The goal of this ID tracker is to collect _unique_ test IDs for
>> every
>>>>> test,
>>>>>> so that we can build a native image which would execute the same
>>> tests
>>>> in
>>>>>> native mode. In other words, we first execute the tests in "JVM"
>>> mode,
>>>>>> using the surefire plugin, then there's a native image being built
>>>> which
>>>>>> includes the tests and uses the information from the JVM execution
>> to
>>>>> tell
>>>>>> which tests to execute in the native mode (that's because
>> traditional
>>>>> test
>>>>>> discovery mechanisms don't work in a native executable).
>>>>>>
>>>>>> Before JUnit 5.8, the listener which collects test ids used to live
>>> in
>>>>> the
>>>>>> "junit-platform-native" dependency, and because it did so, the sole
>>>> fact
>>>>> of
>>>>>> adding this dependency was enough to trigger the listener. That
>> was a
>>>>>> temporary solution until JUnit actually *bundles* this listener,
>> and
>>>>> that's
>>>>>> where things get more complicated.
>>>>>>
>>>>>> Starting with the 5.8 release, the listener is embedded into JUnit.
>>>> This
>>>>>> means we can remove it from the "junit-platform-native" dependency
>>> [1].
>>>>>> However, it also means that there must be a way to opt-in, because
>>> most
>>>>>> users don't need this listener active. Therefore, JUnit requires
>> the
>>>>>> "junit.platform.listeners.uid.tracking.enabled" system property to
>> be
>>>>> set.
>>>>>>
>>>>>> This means, in practice, that IF the native maven plugin is
>> applied,
>>>> THEN
>>>>>> the surefire mojo needs to be configured to set this property. It's
>>> an
>>>>>> implementation detail that users shouldn't have to worry about. For
>>>>> Gradle
>>>>>> this was trivial to implement because we can just react to the
>>> presence
>>>>> of
>>>>>> the native plugin and reconfigure the test task to add this system
>>>>>> property. For Maven, this proves quite challenging.
>>>>>>
>>>>>> Currently, the only way I found is to have the user explicitly add
>>> this
>>>>>> system property to the surefire mojo:
>>>>>>
>>>>>> <plugin>
>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>> <artifactId>maven-surefire-plugin</artifactId>
>>>>>> <version>3.0.0-M5</version>
>>>>>> <configuration>
>>>>>> <systemProperties>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> <junit.platform.listeners.uid.tracking.enabled>true</junit.platform.listeners.uid.tracking.enabled>
>>>>>> </systemProperties>
>>>>>> </configuration>
>>>>>> </plugin>
>>>>>>
>>>>>>
>>>>>> This is certainly not nice, because as I said, the user shouldn't
>>> care:
>>>>>> because we apply the native plugin, we *know* that we need that
>>>> listener.
>>>>>> Therefore I'm looking for ways to automatically alter the
>>> configuration
>>>>> of
>>>>>> the surefire plugin if the native plugin is applied. More
>>> importantly,
>>>>> this
>>>>>> is a breaking change since upgrading the plugin now requires a
>>>> redundant
>>>>>> system property to be set.
>>>>>>
>>>>>> I found that I could do this in the following situations:
>>>>>>
>>>>>> - if my mojo runs _before_ the tests: this is not possible, since I
>>>> need
>>>>>> the results of the test execution to get the list of tests
>>>>>> - using a lifecycle extension: it seems doable, but then I'm
>>> replacing
>>>>> one
>>>>>> problem with another: the user has to register the extension,
>> either
>>> by
>>>>>> updating the POM file or adding it to their extensions. This,
>> again,
>>>> is a
>>>>>> no-go since we want this to be transparent.
>>>>>>
>>>>>> Last but not least, I'm not mentioning that there's a 2d property
>>> which
>>>>>> would ideally need to be set too, which is the directory where
>> those
>>>> test
>>>>>> ids are dumped. By default it uses the target directory today, but
>>> this
>>>>> is
>>>>>> causing reliability issues, unless users do clean on every run. So
>> it
>>>>> would
>>>>>> be great to be able to configure a *unique* directory per session.
>>> One
>>>>>> problem at a time, though.
>>>>>>
>>>>>> All in all, is there any other way to do what I need that I'm
>>> missing?
>>>>>>
>>>>>> Thanks for your help,
>>>>>>
>>>>>> [1] https://github.com/graalvm/native-build-tools/issues/131
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> // Mantas
>>>>>
>>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Alter configuration of another mojo
Posted by Lasse Lindqvist <la...@gmail.com>.
They would need two executions yes, but they would not need to really know
about how surefire works with it. Native build tools plugin could in its
own docs explain that that execution is needed if junit tests are to be run
again, and the user would not have to touch the configurations of other
plugins.
to 23. syysk. 2021 klo 18.46 Cédric Champeau (cedric.champeau@gmail.com)
kirjoitti:
> Possibly, but as far as I understand it would just move the problem to a
> different location, since the user would have to declare the 2d execution,
> no? Something which is important is that I'm trying to avoid a breaking
> change, that is to say that there are existing POM files which work today
> that I don't want to break once they upgrade the plugin version.
>
> Le jeu. 23 sept. 2021 à 17:29, Lasse Lindqvist <
> lasse.k.lindqvist@gmail.com>
> a écrit :
>
> > Perhaps one way to make it so that users don't need to touch Surefire is
> to
> > have two executions for your plugin, the first one being in maybe
> > validation phase and doing
> >
> > // inject the project
> > @Parameter(defaultValue = "${project}")
> > private org.apache.maven.project.MavenProject project;
> >
> > ...
> >
> >
> project.getProperties().setProperty("junit.platform.listeners.uid.tracking.enabled",
> > "true");
> >
> > Not sure if this works, but if it does it would allow the users to
> > only configure one plugin.
> >
> >
> > to 23. syysk. 2021 klo 18.04 Cédric Champeau (cedric.champeau@gmail.com)
> > kirjoitti:
> >
> > > Thanks, but I totally disagree with you. The evidence that it's an
> > > implementation detail is that the previous version did NOT need any
> user
> > to
> > > configure anything: it just works and nobody complained that it was
> > > "magic": it just did what it was supposed to do. The fact that I cannot
> > > configure properly the JUnit engine and that as a workaround you have
> to
> > > ask the _user_ to do it is a PITA. That's the same for the build
> > directory:
> > > I can of course use different timestamps, but that again puts the
> burden
> > to
> > > the user when they shouldn't have to care: their builds should be
> correct
> > > _whatever configuration_ they use.
> > >
> > > Le jeu. 23 sept. 2021 à 15:48, Mantas Gridinas <mg...@gmail.com> a
> > > écrit :
> > >
> > > > > This means, in practice, that IF the native maven plugin is
> applied,
> > > THEN
> > > > > the surefire mojo needs to be configured to set this property. It's
> > an
> > > > > implementation detail that users shouldn't have to worry about. For
> > > > Gradle
> > > > > this was trivial to implement because we can just react to the
> > presence
> > > > of
> > > > > the native plugin and reconfigure the test task to add this system
> > > > > property. For Maven, this proves quite challenging.
> > > >
> > > > I'd argue otherwise. Users should be cognizant of what magical
> changes
> > > are
> > > > applied to their build processes. But to each their own.
> > > >
> > > > As for unique directory, why not utilize project.build.directory
> > property
> > > > that maven provides[1]? A quick workaround would be overriding it in
> > > > specific profile (or commandline) to include build timestamp. Ex
> > > >
> > > > ${project.basedir}/target-${maven.build.timestamp}[2]
> > > >
> > > > The above would ensure that every build is given a unique directory,
> > > > regardless of goals that you run. Though I'd put that behind a
> profile
> > > or a
> > > > commandline parameter, rather than encourage users to override the
> > > default
> > > > build directory. Not to mention this will probably break clean plugin
> > > since
> > > > it depends on project.build.directory. To fix that you could include
> > > > fileSets property under clean plugin's goal configuration[3] and
> > > configure
> > > > it to delete all directories that have prefix of
> > > > ${project.basedir)/target-.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://maven.apache.org/pom.html#:~:text=%3Cdirectory%3E%24%7Bproject.basedir%7D/target%3C/directory%3E
> > > > [2]
> > > >
> > > >
> > >
> >
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#available-variables
> > > > [3]
> > > >
> > > >
> > >
> >
> https://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html
> > > >
> > > >
> > > >
> > > > On Thu, Sep 23, 2021 at 11:54 AM Cédric Champeau <
> > > > cedric.champeau@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi folks,
> > > > >
> > > > > I'm the maintainer of the GraalVM native build tools plugins for
> > Maven
> > > > and
> > > > > Gradle. In the next release, we're moving to JUnit Platform 5.8,
> > which
> > > > now
> > > > > integrates a "unique test id tracker", which before used to be
> > > > implemented
> > > > > in this plugin suite.
> > > > >
> > > > > The goal of this ID tracker is to collect _unique_ test IDs for
> every
> > > > test,
> > > > > so that we can build a native image which would execute the same
> > tests
> > > in
> > > > > native mode. In other words, we first execute the tests in "JVM"
> > mode,
> > > > > using the surefire plugin, then there's a native image being built
> > > which
> > > > > includes the tests and uses the information from the JVM execution
> to
> > > > tell
> > > > > which tests to execute in the native mode (that's because
> traditional
> > > > test
> > > > > discovery mechanisms don't work in a native executable).
> > > > >
> > > > > Before JUnit 5.8, the listener which collects test ids used to live
> > in
> > > > the
> > > > > "junit-platform-native" dependency, and because it did so, the sole
> > > fact
> > > > of
> > > > > adding this dependency was enough to trigger the listener. That
> was a
> > > > > temporary solution until JUnit actually *bundles* this listener,
> and
> > > > that's
> > > > > where things get more complicated.
> > > > >
> > > > > Starting with the 5.8 release, the listener is embedded into JUnit.
> > > This
> > > > > means we can remove it from the "junit-platform-native" dependency
> > [1].
> > > > > However, it also means that there must be a way to opt-in, because
> > most
> > > > > users don't need this listener active. Therefore, JUnit requires
> the
> > > > > "junit.platform.listeners.uid.tracking.enabled" system property to
> be
> > > > set.
> > > > >
> > > > > This means, in practice, that IF the native maven plugin is
> applied,
> > > THEN
> > > > > the surefire mojo needs to be configured to set this property. It's
> > an
> > > > > implementation detail that users shouldn't have to worry about. For
> > > > Gradle
> > > > > this was trivial to implement because we can just react to the
> > presence
> > > > of
> > > > > the native plugin and reconfigure the test task to add this system
> > > > > property. For Maven, this proves quite challenging.
> > > > >
> > > > > Currently, the only way I found is to have the user explicitly add
> > this
> > > > > system property to the surefire mojo:
> > > > >
> > > > > <plugin>
> > > > > <groupId>org.apache.maven.plugins</groupId>
> > > > > <artifactId>maven-surefire-plugin</artifactId>
> > > > > <version>3.0.0-M5</version>
> > > > > <configuration>
> > > > > <systemProperties>
> > > > >
> > > > >
> > > >
> > >
> >
> <junit.platform.listeners.uid.tracking.enabled>true</junit.platform.listeners.uid.tracking.enabled>
> > > > > </systemProperties>
> > > > > </configuration>
> > > > > </plugin>
> > > > >
> > > > >
> > > > > This is certainly not nice, because as I said, the user shouldn't
> > care:
> > > > > because we apply the native plugin, we *know* that we need that
> > > listener.
> > > > > Therefore I'm looking for ways to automatically alter the
> > configuration
> > > > of
> > > > > the surefire plugin if the native plugin is applied. More
> > importantly,
> > > > this
> > > > > is a breaking change since upgrading the plugin now requires a
> > > redundant
> > > > > system property to be set.
> > > > >
> > > > > I found that I could do this in the following situations:
> > > > >
> > > > > - if my mojo runs _before_ the tests: this is not possible, since I
> > > need
> > > > > the results of the test execution to get the list of tests
> > > > > - using a lifecycle extension: it seems doable, but then I'm
> > replacing
> > > > one
> > > > > problem with another: the user has to register the extension,
> either
> > by
> > > > > updating the POM file or adding it to their extensions. This,
> again,
> > > is a
> > > > > no-go since we want this to be transparent.
> > > > >
> > > > > Last but not least, I'm not mentioning that there's a 2d property
> > which
> > > > > would ideally need to be set too, which is the directory where
> those
> > > test
> > > > > ids are dumped. By default it uses the target directory today, but
> > this
> > > > is
> > > > > causing reliability issues, unless users do clean on every run. So
> it
> > > > would
> > > > > be great to be able to configure a *unique* directory per session.
> > One
> > > > > problem at a time, though.
> > > > >
> > > > > All in all, is there any other way to do what I need that I'm
> > missing?
> > > > >
> > > > > Thanks for your help,
> > > > >
> > > > > [1] https://github.com/graalvm/native-build-tools/issues/131
> > > > >
> > > >
> > > >
> > > > --
> > > > // Mantas
> > > >
> > >
> >
>
Re: Alter configuration of another mojo
Posted by Cédric Champeau <ce...@gmail.com>.
Possibly, but as far as I understand it would just move the problem to a
different location, since the user would have to declare the 2d execution,
no? Something which is important is that I'm trying to avoid a breaking
change, that is to say that there are existing POM files which work today
that I don't want to break once they upgrade the plugin version.
Le jeu. 23 sept. 2021 à 17:29, Lasse Lindqvist <la...@gmail.com>
a écrit :
> Perhaps one way to make it so that users don't need to touch Surefire is to
> have two executions for your plugin, the first one being in maybe
> validation phase and doing
>
> // inject the project
> @Parameter(defaultValue = "${project}")
> private org.apache.maven.project.MavenProject project;
>
> ...
>
> project.getProperties().setProperty("junit.platform.listeners.uid.tracking.enabled",
> "true");
>
> Not sure if this works, but if it does it would allow the users to
> only configure one plugin.
>
>
> to 23. syysk. 2021 klo 18.04 Cédric Champeau (cedric.champeau@gmail.com)
> kirjoitti:
>
> > Thanks, but I totally disagree with you. The evidence that it's an
> > implementation detail is that the previous version did NOT need any user
> to
> > configure anything: it just works and nobody complained that it was
> > "magic": it just did what it was supposed to do. The fact that I cannot
> > configure properly the JUnit engine and that as a workaround you have to
> > ask the _user_ to do it is a PITA. That's the same for the build
> directory:
> > I can of course use different timestamps, but that again puts the burden
> to
> > the user when they shouldn't have to care: their builds should be correct
> > _whatever configuration_ they use.
> >
> > Le jeu. 23 sept. 2021 à 15:48, Mantas Gridinas <mg...@gmail.com> a
> > écrit :
> >
> > > > This means, in practice, that IF the native maven plugin is applied,
> > THEN
> > > > the surefire mojo needs to be configured to set this property. It's
> an
> > > > implementation detail that users shouldn't have to worry about. For
> > > Gradle
> > > > this was trivial to implement because we can just react to the
> presence
> > > of
> > > > the native plugin and reconfigure the test task to add this system
> > > > property. For Maven, this proves quite challenging.
> > >
> > > I'd argue otherwise. Users should be cognizant of what magical changes
> > are
> > > applied to their build processes. But to each their own.
> > >
> > > As for unique directory, why not utilize project.build.directory
> property
> > > that maven provides[1]? A quick workaround would be overriding it in
> > > specific profile (or commandline) to include build timestamp. Ex
> > >
> > > ${project.basedir}/target-${maven.build.timestamp}[2]
> > >
> > > The above would ensure that every build is given a unique directory,
> > > regardless of goals that you run. Though I'd put that behind a profile
> > or a
> > > commandline parameter, rather than encourage users to override the
> > default
> > > build directory. Not to mention this will probably break clean plugin
> > since
> > > it depends on project.build.directory. To fix that you could include
> > > fileSets property under clean plugin's goal configuration[3] and
> > configure
> > > it to delete all directories that have prefix of
> > > ${project.basedir)/target-.
> > >
> > > [1]
> > >
> > >
> >
> https://maven.apache.org/pom.html#:~:text=%3Cdirectory%3E%24%7Bproject.basedir%7D/target%3C/directory%3E
> > > [2]
> > >
> > >
> >
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#available-variables
> > > [3]
> > >
> > >
> >
> https://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html
> > >
> > >
> > >
> > > On Thu, Sep 23, 2021 at 11:54 AM Cédric Champeau <
> > > cedric.champeau@gmail.com>
> > > wrote:
> > >
> > > > Hi folks,
> > > >
> > > > I'm the maintainer of the GraalVM native build tools plugins for
> Maven
> > > and
> > > > Gradle. In the next release, we're moving to JUnit Platform 5.8,
> which
> > > now
> > > > integrates a "unique test id tracker", which before used to be
> > > implemented
> > > > in this plugin suite.
> > > >
> > > > The goal of this ID tracker is to collect _unique_ test IDs for every
> > > test,
> > > > so that we can build a native image which would execute the same
> tests
> > in
> > > > native mode. In other words, we first execute the tests in "JVM"
> mode,
> > > > using the surefire plugin, then there's a native image being built
> > which
> > > > includes the tests and uses the information from the JVM execution to
> > > tell
> > > > which tests to execute in the native mode (that's because traditional
> > > test
> > > > discovery mechanisms don't work in a native executable).
> > > >
> > > > Before JUnit 5.8, the listener which collects test ids used to live
> in
> > > the
> > > > "junit-platform-native" dependency, and because it did so, the sole
> > fact
> > > of
> > > > adding this dependency was enough to trigger the listener. That was a
> > > > temporary solution until JUnit actually *bundles* this listener, and
> > > that's
> > > > where things get more complicated.
> > > >
> > > > Starting with the 5.8 release, the listener is embedded into JUnit.
> > This
> > > > means we can remove it from the "junit-platform-native" dependency
> [1].
> > > > However, it also means that there must be a way to opt-in, because
> most
> > > > users don't need this listener active. Therefore, JUnit requires the
> > > > "junit.platform.listeners.uid.tracking.enabled" system property to be
> > > set.
> > > >
> > > > This means, in practice, that IF the native maven plugin is applied,
> > THEN
> > > > the surefire mojo needs to be configured to set this property. It's
> an
> > > > implementation detail that users shouldn't have to worry about. For
> > > Gradle
> > > > this was trivial to implement because we can just react to the
> presence
> > > of
> > > > the native plugin and reconfigure the test task to add this system
> > > > property. For Maven, this proves quite challenging.
> > > >
> > > > Currently, the only way I found is to have the user explicitly add
> this
> > > > system property to the surefire mojo:
> > > >
> > > > <plugin>
> > > > <groupId>org.apache.maven.plugins</groupId>
> > > > <artifactId>maven-surefire-plugin</artifactId>
> > > > <version>3.0.0-M5</version>
> > > > <configuration>
> > > > <systemProperties>
> > > >
> > > >
> > >
> >
> <junit.platform.listeners.uid.tracking.enabled>true</junit.platform.listeners.uid.tracking.enabled>
> > > > </systemProperties>
> > > > </configuration>
> > > > </plugin>
> > > >
> > > >
> > > > This is certainly not nice, because as I said, the user shouldn't
> care:
> > > > because we apply the native plugin, we *know* that we need that
> > listener.
> > > > Therefore I'm looking for ways to automatically alter the
> configuration
> > > of
> > > > the surefire plugin if the native plugin is applied. More
> importantly,
> > > this
> > > > is a breaking change since upgrading the plugin now requires a
> > redundant
> > > > system property to be set.
> > > >
> > > > I found that I could do this in the following situations:
> > > >
> > > > - if my mojo runs _before_ the tests: this is not possible, since I
> > need
> > > > the results of the test execution to get the list of tests
> > > > - using a lifecycle extension: it seems doable, but then I'm
> replacing
> > > one
> > > > problem with another: the user has to register the extension, either
> by
> > > > updating the POM file or adding it to their extensions. This, again,
> > is a
> > > > no-go since we want this to be transparent.
> > > >
> > > > Last but not least, I'm not mentioning that there's a 2d property
> which
> > > > would ideally need to be set too, which is the directory where those
> > test
> > > > ids are dumped. By default it uses the target directory today, but
> this
> > > is
> > > > causing reliability issues, unless users do clean on every run. So it
> > > would
> > > > be great to be able to configure a *unique* directory per session.
> One
> > > > problem at a time, though.
> > > >
> > > > All in all, is there any other way to do what I need that I'm
> missing?
> > > >
> > > > Thanks for your help,
> > > >
> > > > [1] https://github.com/graalvm/native-build-tools/issues/131
> > > >
> > >
> > >
> > > --
> > > // Mantas
> > >
> >
>
Re: Alter configuration of another mojo
Posted by Lasse Lindqvist <la...@gmail.com>.
Perhaps one way to make it so that users don't need to touch Surefire is to
have two executions for your plugin, the first one being in maybe
validation phase and doing
// inject the project
@Parameter(defaultValue = "${project}")
private org.apache.maven.project.MavenProject project;
...
project.getProperties().setProperty("junit.platform.listeners.uid.tracking.enabled",
"true");
Not sure if this works, but if it does it would allow the users to
only configure one plugin.
to 23. syysk. 2021 klo 18.04 Cédric Champeau (cedric.champeau@gmail.com)
kirjoitti:
> Thanks, but I totally disagree with you. The evidence that it's an
> implementation detail is that the previous version did NOT need any user to
> configure anything: it just works and nobody complained that it was
> "magic": it just did what it was supposed to do. The fact that I cannot
> configure properly the JUnit engine and that as a workaround you have to
> ask the _user_ to do it is a PITA. That's the same for the build directory:
> I can of course use different timestamps, but that again puts the burden to
> the user when they shouldn't have to care: their builds should be correct
> _whatever configuration_ they use.
>
> Le jeu. 23 sept. 2021 à 15:48, Mantas Gridinas <mg...@gmail.com> a
> écrit :
>
> > > This means, in practice, that IF the native maven plugin is applied,
> THEN
> > > the surefire mojo needs to be configured to set this property. It's an
> > > implementation detail that users shouldn't have to worry about. For
> > Gradle
> > > this was trivial to implement because we can just react to the presence
> > of
> > > the native plugin and reconfigure the test task to add this system
> > > property. For Maven, this proves quite challenging.
> >
> > I'd argue otherwise. Users should be cognizant of what magical changes
> are
> > applied to their build processes. But to each their own.
> >
> > As for unique directory, why not utilize project.build.directory property
> > that maven provides[1]? A quick workaround would be overriding it in
> > specific profile (or commandline) to include build timestamp. Ex
> >
> > ${project.basedir}/target-${maven.build.timestamp}[2]
> >
> > The above would ensure that every build is given a unique directory,
> > regardless of goals that you run. Though I'd put that behind a profile
> or a
> > commandline parameter, rather than encourage users to override the
> default
> > build directory. Not to mention this will probably break clean plugin
> since
> > it depends on project.build.directory. To fix that you could include
> > fileSets property under clean plugin's goal configuration[3] and
> configure
> > it to delete all directories that have prefix of
> > ${project.basedir)/target-.
> >
> > [1]
> >
> >
> https://maven.apache.org/pom.html#:~:text=%3Cdirectory%3E%24%7Bproject.basedir%7D/target%3C/directory%3E
> > [2]
> >
> >
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#available-variables
> > [3]
> >
> >
> https://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html
> >
> >
> >
> > On Thu, Sep 23, 2021 at 11:54 AM Cédric Champeau <
> > cedric.champeau@gmail.com>
> > wrote:
> >
> > > Hi folks,
> > >
> > > I'm the maintainer of the GraalVM native build tools plugins for Maven
> > and
> > > Gradle. In the next release, we're moving to JUnit Platform 5.8, which
> > now
> > > integrates a "unique test id tracker", which before used to be
> > implemented
> > > in this plugin suite.
> > >
> > > The goal of this ID tracker is to collect _unique_ test IDs for every
> > test,
> > > so that we can build a native image which would execute the same tests
> in
> > > native mode. In other words, we first execute the tests in "JVM" mode,
> > > using the surefire plugin, then there's a native image being built
> which
> > > includes the tests and uses the information from the JVM execution to
> > tell
> > > which tests to execute in the native mode (that's because traditional
> > test
> > > discovery mechanisms don't work in a native executable).
> > >
> > > Before JUnit 5.8, the listener which collects test ids used to live in
> > the
> > > "junit-platform-native" dependency, and because it did so, the sole
> fact
> > of
> > > adding this dependency was enough to trigger the listener. That was a
> > > temporary solution until JUnit actually *bundles* this listener, and
> > that's
> > > where things get more complicated.
> > >
> > > Starting with the 5.8 release, the listener is embedded into JUnit.
> This
> > > means we can remove it from the "junit-platform-native" dependency [1].
> > > However, it also means that there must be a way to opt-in, because most
> > > users don't need this listener active. Therefore, JUnit requires the
> > > "junit.platform.listeners.uid.tracking.enabled" system property to be
> > set.
> > >
> > > This means, in practice, that IF the native maven plugin is applied,
> THEN
> > > the surefire mojo needs to be configured to set this property. It's an
> > > implementation detail that users shouldn't have to worry about. For
> > Gradle
> > > this was trivial to implement because we can just react to the presence
> > of
> > > the native plugin and reconfigure the test task to add this system
> > > property. For Maven, this proves quite challenging.
> > >
> > > Currently, the only way I found is to have the user explicitly add this
> > > system property to the surefire mojo:
> > >
> > > <plugin>
> > > <groupId>org.apache.maven.plugins</groupId>
> > > <artifactId>maven-surefire-plugin</artifactId>
> > > <version>3.0.0-M5</version>
> > > <configuration>
> > > <systemProperties>
> > >
> > >
> >
> <junit.platform.listeners.uid.tracking.enabled>true</junit.platform.listeners.uid.tracking.enabled>
> > > </systemProperties>
> > > </configuration>
> > > </plugin>
> > >
> > >
> > > This is certainly not nice, because as I said, the user shouldn't care:
> > > because we apply the native plugin, we *know* that we need that
> listener.
> > > Therefore I'm looking for ways to automatically alter the configuration
> > of
> > > the surefire plugin if the native plugin is applied. More importantly,
> > this
> > > is a breaking change since upgrading the plugin now requires a
> redundant
> > > system property to be set.
> > >
> > > I found that I could do this in the following situations:
> > >
> > > - if my mojo runs _before_ the tests: this is not possible, since I
> need
> > > the results of the test execution to get the list of tests
> > > - using a lifecycle extension: it seems doable, but then I'm replacing
> > one
> > > problem with another: the user has to register the extension, either by
> > > updating the POM file or adding it to their extensions. This, again,
> is a
> > > no-go since we want this to be transparent.
> > >
> > > Last but not least, I'm not mentioning that there's a 2d property which
> > > would ideally need to be set too, which is the directory where those
> test
> > > ids are dumped. By default it uses the target directory today, but this
> > is
> > > causing reliability issues, unless users do clean on every run. So it
> > would
> > > be great to be able to configure a *unique* directory per session. One
> > > problem at a time, though.
> > >
> > > All in all, is there any other way to do what I need that I'm missing?
> > >
> > > Thanks for your help,
> > >
> > > [1] https://github.com/graalvm/native-build-tools/issues/131
> > >
> >
> >
> > --
> > // Mantas
> >
>
Re: Alter configuration of another mojo
Posted by Cédric Champeau <ce...@gmail.com>.
Thanks, but I totally disagree with you. The evidence that it's an
implementation detail is that the previous version did NOT need any user to
configure anything: it just works and nobody complained that it was
"magic": it just did what it was supposed to do. The fact that I cannot
configure properly the JUnit engine and that as a workaround you have to
ask the _user_ to do it is a PITA. That's the same for the build directory:
I can of course use different timestamps, but that again puts the burden to
the user when they shouldn't have to care: their builds should be correct
_whatever configuration_ they use.
Le jeu. 23 sept. 2021 à 15:48, Mantas Gridinas <mg...@gmail.com> a
écrit :
> > This means, in practice, that IF the native maven plugin is applied, THEN
> > the surefire mojo needs to be configured to set this property. It's an
> > implementation detail that users shouldn't have to worry about. For
> Gradle
> > this was trivial to implement because we can just react to the presence
> of
> > the native plugin and reconfigure the test task to add this system
> > property. For Maven, this proves quite challenging.
>
> I'd argue otherwise. Users should be cognizant of what magical changes are
> applied to their build processes. But to each their own.
>
> As for unique directory, why not utilize project.build.directory property
> that maven provides[1]? A quick workaround would be overriding it in
> specific profile (or commandline) to include build timestamp. Ex
>
> ${project.basedir}/target-${maven.build.timestamp}[2]
>
> The above would ensure that every build is given a unique directory,
> regardless of goals that you run. Though I'd put that behind a profile or a
> commandline parameter, rather than encourage users to override the default
> build directory. Not to mention this will probably break clean plugin since
> it depends on project.build.directory. To fix that you could include
> fileSets property under clean plugin's goal configuration[3] and configure
> it to delete all directories that have prefix of
> ${project.basedir)/target-.
>
> [1]
>
> https://maven.apache.org/pom.html#:~:text=%3Cdirectory%3E%24%7Bproject.basedir%7D/target%3C/directory%3E
> [2]
>
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#available-variables
> [3]
>
> https://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html
>
>
>
> On Thu, Sep 23, 2021 at 11:54 AM Cédric Champeau <
> cedric.champeau@gmail.com>
> wrote:
>
> > Hi folks,
> >
> > I'm the maintainer of the GraalVM native build tools plugins for Maven
> and
> > Gradle. In the next release, we're moving to JUnit Platform 5.8, which
> now
> > integrates a "unique test id tracker", which before used to be
> implemented
> > in this plugin suite.
> >
> > The goal of this ID tracker is to collect _unique_ test IDs for every
> test,
> > so that we can build a native image which would execute the same tests in
> > native mode. In other words, we first execute the tests in "JVM" mode,
> > using the surefire plugin, then there's a native image being built which
> > includes the tests and uses the information from the JVM execution to
> tell
> > which tests to execute in the native mode (that's because traditional
> test
> > discovery mechanisms don't work in a native executable).
> >
> > Before JUnit 5.8, the listener which collects test ids used to live in
> the
> > "junit-platform-native" dependency, and because it did so, the sole fact
> of
> > adding this dependency was enough to trigger the listener. That was a
> > temporary solution until JUnit actually *bundles* this listener, and
> that's
> > where things get more complicated.
> >
> > Starting with the 5.8 release, the listener is embedded into JUnit. This
> > means we can remove it from the "junit-platform-native" dependency [1].
> > However, it also means that there must be a way to opt-in, because most
> > users don't need this listener active. Therefore, JUnit requires the
> > "junit.platform.listeners.uid.tracking.enabled" system property to be
> set.
> >
> > This means, in practice, that IF the native maven plugin is applied, THEN
> > the surefire mojo needs to be configured to set this property. It's an
> > implementation detail that users shouldn't have to worry about. For
> Gradle
> > this was trivial to implement because we can just react to the presence
> of
> > the native plugin and reconfigure the test task to add this system
> > property. For Maven, this proves quite challenging.
> >
> > Currently, the only way I found is to have the user explicitly add this
> > system property to the surefire mojo:
> >
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-surefire-plugin</artifactId>
> > <version>3.0.0-M5</version>
> > <configuration>
> > <systemProperties>
> >
> >
> <junit.platform.listeners.uid.tracking.enabled>true</junit.platform.listeners.uid.tracking.enabled>
> > </systemProperties>
> > </configuration>
> > </plugin>
> >
> >
> > This is certainly not nice, because as I said, the user shouldn't care:
> > because we apply the native plugin, we *know* that we need that listener.
> > Therefore I'm looking for ways to automatically alter the configuration
> of
> > the surefire plugin if the native plugin is applied. More importantly,
> this
> > is a breaking change since upgrading the plugin now requires a redundant
> > system property to be set.
> >
> > I found that I could do this in the following situations:
> >
> > - if my mojo runs _before_ the tests: this is not possible, since I need
> > the results of the test execution to get the list of tests
> > - using a lifecycle extension: it seems doable, but then I'm replacing
> one
> > problem with another: the user has to register the extension, either by
> > updating the POM file or adding it to their extensions. This, again, is a
> > no-go since we want this to be transparent.
> >
> > Last but not least, I'm not mentioning that there's a 2d property which
> > would ideally need to be set too, which is the directory where those test
> > ids are dumped. By default it uses the target directory today, but this
> is
> > causing reliability issues, unless users do clean on every run. So it
> would
> > be great to be able to configure a *unique* directory per session. One
> > problem at a time, though.
> >
> > All in all, is there any other way to do what I need that I'm missing?
> >
> > Thanks for your help,
> >
> > [1] https://github.com/graalvm/native-build-tools/issues/131
> >
>
>
> --
> // Mantas
>
Re: Alter configuration of another mojo
Posted by Mantas Gridinas <mg...@gmail.com>.
> This means, in practice, that IF the native maven plugin is applied, THEN
> the surefire mojo needs to be configured to set this property. It's an
> implementation detail that users shouldn't have to worry about. For Gradle
> this was trivial to implement because we can just react to the presence of
> the native plugin and reconfigure the test task to add this system
> property. For Maven, this proves quite challenging.
I'd argue otherwise. Users should be cognizant of what magical changes are
applied to their build processes. But to each their own.
As for unique directory, why not utilize project.build.directory property
that maven provides[1]? A quick workaround would be overriding it in
specific profile (or commandline) to include build timestamp. Ex
${project.basedir}/target-${maven.build.timestamp}[2]
The above would ensure that every build is given a unique directory,
regardless of goals that you run. Though I'd put that behind a profile or a
commandline parameter, rather than encourage users to override the default
build directory. Not to mention this will probably break clean plugin since
it depends on project.build.directory. To fix that you could include
fileSets property under clean plugin's goal configuration[3] and configure
it to delete all directories that have prefix of ${project.basedir)/target-.
[1]
https://maven.apache.org/pom.html#:~:text=%3Cdirectory%3E%24%7Bproject.basedir%7D/target%3C/directory%3E
[2]
https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#available-variables
[3]
https://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html
On Thu, Sep 23, 2021 at 11:54 AM Cédric Champeau <ce...@gmail.com>
wrote:
> Hi folks,
>
> I'm the maintainer of the GraalVM native build tools plugins for Maven and
> Gradle. In the next release, we're moving to JUnit Platform 5.8, which now
> integrates a "unique test id tracker", which before used to be implemented
> in this plugin suite.
>
> The goal of this ID tracker is to collect _unique_ test IDs for every test,
> so that we can build a native image which would execute the same tests in
> native mode. In other words, we first execute the tests in "JVM" mode,
> using the surefire plugin, then there's a native image being built which
> includes the tests and uses the information from the JVM execution to tell
> which tests to execute in the native mode (that's because traditional test
> discovery mechanisms don't work in a native executable).
>
> Before JUnit 5.8, the listener which collects test ids used to live in the
> "junit-platform-native" dependency, and because it did so, the sole fact of
> adding this dependency was enough to trigger the listener. That was a
> temporary solution until JUnit actually *bundles* this listener, and that's
> where things get more complicated.
>
> Starting with the 5.8 release, the listener is embedded into JUnit. This
> means we can remove it from the "junit-platform-native" dependency [1].
> However, it also means that there must be a way to opt-in, because most
> users don't need this listener active. Therefore, JUnit requires the
> "junit.platform.listeners.uid.tracking.enabled" system property to be set.
>
> This means, in practice, that IF the native maven plugin is applied, THEN
> the surefire mojo needs to be configured to set this property. It's an
> implementation detail that users shouldn't have to worry about. For Gradle
> this was trivial to implement because we can just react to the presence of
> the native plugin and reconfigure the test task to add this system
> property. For Maven, this proves quite challenging.
>
> Currently, the only way I found is to have the user explicitly add this
> system property to the surefire mojo:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-surefire-plugin</artifactId>
> <version>3.0.0-M5</version>
> <configuration>
> <systemProperties>
>
> <junit.platform.listeners.uid.tracking.enabled>true</junit.platform.listeners.uid.tracking.enabled>
> </systemProperties>
> </configuration>
> </plugin>
>
>
> This is certainly not nice, because as I said, the user shouldn't care:
> because we apply the native plugin, we *know* that we need that listener.
> Therefore I'm looking for ways to automatically alter the configuration of
> the surefire plugin if the native plugin is applied. More importantly, this
> is a breaking change since upgrading the plugin now requires a redundant
> system property to be set.
>
> I found that I could do this in the following situations:
>
> - if my mojo runs _before_ the tests: this is not possible, since I need
> the results of the test execution to get the list of tests
> - using a lifecycle extension: it seems doable, but then I'm replacing one
> problem with another: the user has to register the extension, either by
> updating the POM file or adding it to their extensions. This, again, is a
> no-go since we want this to be transparent.
>
> Last but not least, I'm not mentioning that there's a 2d property which
> would ideally need to be set too, which is the directory where those test
> ids are dumped. By default it uses the target directory today, but this is
> causing reliability issues, unless users do clean on every run. So it would
> be great to be able to configure a *unique* directory per session. One
> problem at a time, though.
>
> All in all, is there any other way to do what I need that I'm missing?
>
> Thanks for your help,
>
> [1] https://github.com/graalvm/native-build-tools/issues/131
>
--
// Mantas
Re: Alter configuration of another mojo
Posted by Greg Chabala <gr...@gmail.com>.
This might be a better question for the dev list.
Thank you for your effort regardless. I would hate to see this become an
example of 'Maven is harder than Gradle'.
On Thu, Sep 23, 2021 at 3:55 AM Cédric Champeau <ce...@gmail.com>
wrote:
> Hi folks,
>
> I'm the maintainer of the GraalVM native build tools plugins for Maven and
> Gradle. In the next release, we're moving to JUnit Platform 5.8, which now
> integrates a "unique test id tracker", which before used to be implemented
> in this plugin suite.
>
> The goal of this ID tracker is to collect _unique_ test IDs for every test,
> so that we can build a native image which would execute the same tests in
> native mode. In other words, we first execute the tests in "JVM" mode,
> using the surefire plugin, then there's a native image being built which
> includes the tests and uses the information from the JVM execution to tell
> which tests to execute in the native mode (that's because traditional test
> discovery mechanisms don't work in a native executable).
>
> Before JUnit 5.8, the listener which collects test ids used to live in the
> "junit-platform-native" dependency, and because it did so, the sole fact of
> adding this dependency was enough to trigger the listener. That was a
> temporary solution until JUnit actually *bundles* this listener, and that's
> where things get more complicated.
>
> Starting with the 5.8 release, the listener is embedded into JUnit. This
> means we can remove it from the "junit-platform-native" dependency [1].
> However, it also means that there must be a way to opt-in, because most
> users don't need this listener active. Therefore, JUnit requires the
> "junit.platform.listeners.uid.tracking.enabled" system property to be set.
>
> This means, in practice, that IF the native maven plugin is applied, THEN
> the surefire mojo needs to be configured to set this property. It's an
> implementation detail that users shouldn't have to worry about. For Gradle
> this was trivial to implement because we can just react to the presence of
> the native plugin and reconfigure the test task to add this system
> property. For Maven, this proves quite challenging.
>
> Currently, the only way I found is to have the user explicitly add this
> system property to the surefire mojo:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-surefire-plugin</artifactId>
> <version>3.0.0-M5</version>
> <configuration>
> <systemProperties>
>
> <junit.platform.listeners.uid.tracking.enabled>true</junit.platform.listeners.uid.tracking.enabled>
> </systemProperties>
> </configuration>
> </plugin>
>
>
> This is certainly not nice, because as I said, the user shouldn't care:
> because we apply the native plugin, we *know* that we need that listener.
> Therefore I'm looking for ways to automatically alter the configuration of
> the surefire plugin if the native plugin is applied. More importantly, this
> is a breaking change since upgrading the plugin now requires a redundant
> system property to be set.
>
> I found that I could do this in the following situations:
>
> - if my mojo runs _before_ the tests: this is not possible, since I need
> the results of the test execution to get the list of tests
> - using a lifecycle extension: it seems doable, but then I'm replacing one
> problem with another: the user has to register the extension, either by
> updating the POM file or adding it to their extensions. This, again, is a
> no-go since we want this to be transparent.
>
> Last but not least, I'm not mentioning that there's a 2d property which
> would ideally need to be set too, which is the directory where those test
> ids are dumped. By default it uses the target directory today, but this is
> causing reliability issues, unless users do clean on every run. So it would
> be great to be able to configure a *unique* directory per session. One
> problem at a time, though.
>
> All in all, is there any other way to do what I need that I'm missing?
>
> Thanks for your help,
>
> [1] https://github.com/graalvm/native-build-tools/issues/131
>