2

I'm trying to use the build-helper-maven-plugin regex to convert a default property before it is used in the dependency section.

My pom.xml file property sections looks like this...

<properties>
    <some.version>114.6.9</some.version>
</properties>

My pom.xml file build plugin section looks like...

    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>build-helper-maven-plugin</artifactId>
            <version>1.9</version>
            <executions>
                <execution>
                    <id>regex-property</id>
                    <goals>
                        <goal>regex-property</goal>
                    </goals>
                    <configuration>
                        <name>some.version</name>
                        <value>${P_SOME_VERSION_AS_PASSED_BY_JENKINS}</value>
                        <regex>^dirtyPrefix-(\S*)</regex>
                        <replacement>$1</replacement>
                        <failIfNoMatch>false</failIfNoMatch>
                    </configuration>
                </execution>
            </executions>
        </plugin>

My pom.xml dependency version looks like...

<dependencies>
    <dependency>
        <groupId>someArtifactGroup</groupId>
        <artifactId>someArtifact</artifactId>
        <version>${some.version}</version>
    </dependency>
</dependencies>

The idea being that if Jenkins is used and passes a dependency override it will be stripped of its pre-fix and used instead of the default value.
However it appears that this plugin does not run before the dependencies are validated - is it possible to get this working or is there a better way?

Chris
  • 161
  • 1
  • 5
  • The properties replacement is done before the build-helper-mavne-plugin is running. Apart from that why do you want to override an dependency within the jenkins job? – khmarbaise Aug 25 '14 at 10:17
  • Sounds like this plugin can't be used if it runs after. The reason why I want to do this is, the particular project wraps another project (that builds multiple versions). We have a Jenkins build job that allows selecting the wrapped project via its subversion tag. Unfortunately that tag has a prefix. I can't use shell in Jenkins to remove it due to the bug in the maven release plugin so thought that I could remove it in the pom.xml instead. – Chris Aug 25 '14 at 10:23
  • What do you mean by `bug in maven release plugin` in relationship with using a shell script? And where is the relationship between svn tag and the version of an artifact in Maven? – khmarbaise Aug 25 '14 at 12:15
  • The release plugin allows an arguments section - it is here I want to pass that argument in... -Dbuild.number=${BUILD_NUMBER} -Dbuild.id=${BUILD_ID} -Dresume=false release:prepare release:perform -Darguments="-DP_SOME_VERSION_AS_PASSED_BY_JENKINS=${P_SOME_VERSION}" However in the "pre-steps" version of the Jenkins job I create P_SOME_VERSION by parsing a user input to strip of the subversion tag pre-fix...or at least that was my first attempt. It appears a known issue means that expansion is not performed within the "arguments" section of the release plugin. – Chris Aug 25 '14 at 12:19
  • khmarbaise - to answer your other question. In the Jenkins job the user input is selected using the drop-down populated by subversion param plug-in "List Subversion tags (and more)". This lists the release tags of the dependent project. I can see a way of doing this using a parent Jenkins job that gets this tag version, uses a shell script to parse out the pre-fix and then pass it the main Jenkins job. Thus I can rule out using Maven to parse out the pre-fix at all as by this point it'll be correct. But I was hoping to avoid a parent Jenkins job. – Chris Aug 25 '14 at 16:04

1 Answers1

0

I was kind of in a similar situation, but an override with -D is no solution (just don't ask) and since I've got a few variables, profiles are none either.

In my case it's like this: The fabric8 docker maven plugin uses a variable. That variable is generated by the "build-helper-maven-plugin" regex-property.

If "mvn docker:build" is invoked, the validate phase is not used and the variable is not there (so I get a "${blabla}" literal) and the build fails. If I invoke the usual build, the variable gets created.

I took the strategy to run "mvn validate docker:build" instead of "mvn docker:build" to force the validation step, so the variable gets created.

Brixomatic
  • 381
  • 4
  • 16