Fwd: Maven Pom Property replacement - possible bug?

[Nick Stolwijk <ni...@gmail.com>]

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 <ni...@gmail.com>
Date: Fri, Jan 31, 2020 at 4:01 PM
Subject: Maven Pom Property replacement - possible bug?
To: Maven Users List <us...@maven.apache.org>


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

Re: Maven Pom Property replacement - possible bug?

[Bernd Eckenfels <ec...@zusammenkunft.net>]

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 <ni...@gmail.com>
Gesendet: Wednesday, February 5, 2020 2:32:28 AM
An: Maven Developers List <de...@maven.apache.org>
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 <ni...@gmail.com>
Date: Fri, Jan 31, 2020 at 4:01 PM
Subject: Maven Pom Property replacement - possible bug?
To: Maven Users List <us...@maven.apache.org>


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