Re: Maven Pom Property replacement - possible bug?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Maven Pom Property replacement - possible bug?

Bernd Eckenfels
Hello,

I don't think it's expected that those properties are replaced as it is not documented. But I think it's specific to some known suffixes (GoupId). If you can add a "Custom" or similar keyword it might help.

I think the expansion can be avoided with ${dollar}{someGroupID} but it might depend on how often the plugin interpolates it. Haven't tried it, though.

Bernd


--
http://bernd.eckenfels.net
________________________________
Von: Nick Stolwijk <[hidden email]>
Gesendet: Wednesday, February 5, 2020 2:32:28 AM
An: Maven Developers List <[hidden email]>
Betreff: Fwd: Maven Pom Property replacement - possible bug?

Hi list,

I send this e-mail last week to the userlist, but haven't heard back yet.

Do you think this is a bug or a user error?

With regards,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell


---------- Forwarded message ---------
From: Nick Stolwijk <[hidden email]>
Date: Fri, Jan 31, 2020 at 4:01 PM
Subject: Maven Pom Property replacement - possible bug?
To: Maven Users List <[hidden email]>


Hi list,

I've seen some strange behavior with pom property replacement and I was
wondering if this is a bug or expected behaviour.

I have a sample project[1] with the build-helper-maven-plugin which I try
to configure to use the regex-property goal.

Since Java 7 the Regexp matcher of Java understands named groups, but they
use the same notation as Maven properties, i.e. ${name}

I tried:
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>build-helper-maven-plugin</artifactId>
    <configuration>
      <replacement>${regexVersion}${regexGroupId}</replacement>
    </configuration>
</plugin>

I expected Maven to not touch my variables if it couldn't replace them. So
I was a little confused when I executed mvn -X and saw the following output:

[DEBUG]   (f) replacement = ${regexVersion}null

It looks like Maven didn't touch the first variable but it replaced the
second with null.

First question: is this expected behaviour?
Second question: how can I escape variables so that Maven doesn't try to
escape them?

[1] https://github.com/nickstolwijk/MavenPropReplacement.git

With regards,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell