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