[
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463231#comment-15463231
]
Robert Patrick edited comment on MNG-6083 at 9/4/16 5:31 PM:
-------------------------------------------------------------
In playing with the paths toolchain, I see how I can specify a location for my
shell scripts with it (this eliminates one of about a dozen variables I need
for my system-test. However, I cannot figure out how to reference a variable
defined in a toolset to pass as an argument to my executable. I tried the
normal ${xxx} but that doesn't work. Without this, it seems that the only
option is a custom toolchain *and* a custom plugin to process it (e.g., a
plugin that reads the toolchain and adds properties to the build so that they
can referenced in the pom). While I am not afraid of writing plugins, I am
concerned that I am missing something obvious.
For example, how do I make this work when the xxxv1-home is defined in the
toolchain?
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.5.0</version>
<extensions>true</extensions>
<configuration>
<toolchains>
<paths>
<id>jcs-las-system-test</id>
</paths>
</toolchains>
</configuration>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>echoMessage.cmd</executable>
<arguments>
<arg1>${xxxv1-home}</arg1>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
was (Author: rhpatrick00):
In playing with the paths toolchain, I see how I can specify a location for my
shell scripts with it (this eliminates one of about a dozen variables I need
for my system-test. However, I cannot figure out how to reference a variable
defined in a toolset to pass as an argument to my executable. I tried the
normal ${xxx} but that doesn't work. Without this, it seems that the only
option is a custom toolchain *and* a custom plugin to process it (e.g., a
plugin that reads the toolchain and adds properties to the build so that they
can referenced in the pom). While I am not afraid of writing plugins, I am
concerned that I am missing something obvious.
For example, how do I make this work when the xxxv1-home is defined in the
toolchain?
(quote)
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.5.0</version>
<extensions>true</extensions>
<configuration>
<toolchains>
<paths>
<id>jcs-las-system-test</id>
</paths>
</toolchains>
</configuration>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>echoMessage.cmd</executable>
<arguments>
<arg1>${xxxv1-home}</arg1>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
(quote)
> Maven 3.3.9 breaks release:perform by not including maven.config
> ----------------------------------------------------------------
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
> Issue Type: Bug
> Components: General
> Affects Versions: 3.3.9
> Reporter: Robert Patrick
> Priority: Blocker
>
> Our release process runs both our build and our integration tests. The
> integration tests rely on our project root directory's .mvn/maven.config file
> to run properly. The maven.config file is NOT checked into the source tree
> because it contains environment-specific values so each developer has their
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in
> another location and with Maven 3.3.9, the maven.config from the original
> location is not being used. The build specifies the release-plugin version
> so the difference seems to be in the core Maven distribution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
