Hi Stefan,
On Friday, 25. September 2020, 14:54:13 CEST S. John wrote:
Thank you, Jörg.
I already assumed that controlling the plugins specified in the parent pom
would not be possible following a pure pom-less build.
For the pluginManagement solution you mentioned to use it within a profile.
The profile can contain also contain a build section with defined profiles. No
problem with that.
I never used Maven profiles (intentionally), yet, but I had a look at them
now.
You should never manipulate runtime related stuff in a profile, e.g. by
changing/adding dependencies. Profile usage to control the build time are fine.
Just keep in mind how profiles work. Maven basically selects in the very first
step all active profiles (based on the module's location), merges internally
all poms (also the inherited ones) into one "builder" pom and then it starts
to do interpolation.
I am not sure I get that correctly. In my understanding I would still have
to specify the respective plugins I want to use in the POMs of the modules
(without the need to configure them there, as this can be done in the
parent).
You can also add those in a parent's profile.
So I guess the only difference between using pluginManagement within a
profile-environment instead of directly within the build-environment of the
parent is that you get even more flexibility?
As said, you're not limited to pluginManagement. It depends on the use case. A
task for the dependency plugin is typically seldom preconfigurable the global
build environment, but can be specific in a profile. OTOH it can make sense to
configure something like the xtend-plugin globally and activate it individually
using profiles.
Your hint about checking for existence of empty files is a nice-to-know
trick. I'll keep that in mind.
Yery useful, indeed.
Maybe you want to formulate an answer on stackoverflow so I can accept it. If
you do, it would probably be good to mention clearly that my goal cannot be
reached with a pure pom-less setup if you feel confident about that fact.
Depends. We use a pom-less build (non-public) and for ~10% of our modules we
have an extra pom.xml added, typically to copy some stuff.
Two examples, just to get you an idea, how these profiles can be used:
1/ We trigger the Kotlin compiler with a profile in the global parent just
based on the existence of a src/main/kotlin folder:
=============== %< =================
<profile>
<id>kotlin</id>
<activation>
<file>
<exists>src/main/kotlin</exists>
</file>
</activation>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>io.wcm.devops.maven.plugins</groupId>
<artifactId>eclipse-maven-plugin</artifactId>
<configuration>
<additionalProjectnatures>
<projectnature>org.jetbrains.kotlin.core.kotlinNature</
projectnature>
</additionalProjectnatures>
<additionalBuildcommands>
<buildcommand>org.jetbrains.kotlin.ui.kotlinBuilder</
buildcommand>
</additionalBuildcommands>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-kotlin-sources</id>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${basedir}/src/main/kotlin</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-maven-plugin</artifactId>
<executions>
<execution>
<id>compile</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<sourceDirs>
<sourceDir>${basedir}/src/main/kotlin</sourceDir>
<sourceDir>${basedir}/src/main/java</sourceDir>
</sourceDirs>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-compile</id>
<phase>none</phase>
</execution>
<execution>
<id>java-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
</plugin>
</plugins>
</build>
</profile>
=============== %< =================
and have another profile triggered by existence of 'profiles/kotlin-
experimental' to enable experimental stuff for Kotlin:
=============== %< =================
<profile>
<id>kotlin-experimental</id>
<activation>
<file>
<exists>profiles/kotlin-experimental</exists>
</file>
</activation>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-maven-plugin</artifactId>
<configuration>
<args combine.children="append">
<arg>-Xopt-in=kotlin.ExperimentalStdlibApi</arg>
</args>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
=============== %< =================
A module using Kotlin will add nothing special to its pom to activate its
compiler (based on the fact of the default location for the source) and a
simple empty file in a module can individually activate the experimental stuff.
Regards,
Jörg
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tycho-user
