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.champ...@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.lindqv...@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.champ...@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 <mgridi...@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.champ...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
