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