I tried the build-helper plugin and got the same problem.
Using this configuration
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.12</version>
<executions>
<execution>
<id>tsp</id>
<phase>validate</phase>
<goals>
<goal>timestamp-property</goal>
</goals>
<configuration>
<name>tsproperty</name>
</configuration>
</execution>
</executions>
</plugin>
will set tsproperty to
[echo] 'tsproperty': 04.10.16 11:16
for example.
But when there is a pre-initialized property like
<tsproperty>0</tsproperty>
before, the result is:
[echo] 'tsproperty': 0
Kind regards,
Maik
> Gesendet: Dienstag, 04. Oktober 2016 um 14:03 Uhr
> Von: "Stephen Connolly" <stephen.alan.conno...@gmail.com>
> An: "Maven Users List" <users@maven.apache.org>
> Cc: "i...@soebes.de" <i...@soebes.de>
> Betreff: Re: Re: [Regression] Declared properties could not be modified
> anymore within a plugin
>
> https://github.com/mojohaus/build-helper-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/buildhelper/AbstractDefinePropertyMojo.java#L47
>
> would be the recommended way to define a property... I would be interested
> to find out if there is an issue in build-helper... one should be able to
> create a test case using just build-helper to set properties and redefine
> them
>
> On 4 October 2016 at 10:35, M. Richey <mric...@gmx.de> wrote:
>
> > Thanks Benson to point that out, it's a good example.
> >
> > We have several use cases where we modify properties with our plugins. We
> > have a large variety of our software which to build for up to three brands.
> > For which brand a specific software is to build is defined outside the poms
> > and provided by our plugin. As we all know you can't loop inside the poms.
> > So we execute a plugin once for each brand to find out if this variant
> > should be build for the brand specified. Therefore we defined a property in
> > the pom.xml, pre-initialized with a default value, and if the software
> > should be build for one brand, the brand is appended to the list, i.e. the
> > value of the property, during the execution of our plugin. So the value of
> > the property may be something like "default,brand1,brand3" after the
> > executions of the plugin.
> >
> > So for us it is a blocker at the moment that one can't modify properties
> > during the execution of a plugin anymore.
> >
> > Benson, you said you have some of these working with 3.3.9. Can you give
> > an example of a plugin where this is working? I would like to see how they
> > are doing it in their code.
> >
> > Kind regards,
> >
> > Maik
> >
> >
> >
> > > Gesendet: Sonntag, 02. Oktober 2016 um 22:04 Uhr
> > > Von: "Benson Margulies" <bimargul...@gmail.com>
> > > An: "Maven Users List" <users@maven.apache.org>, i...@soebes.de
> > > Betreff: Re: [Regression] Declared properties could not be modified
> > anymore within a plugin
> > >
> > > On Fri, Sep 30, 2016 at 1:50 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
> > wrote:
> > > > Hi,
> > > >
> > > > On 30/09/16 15:20, mric...@gmx.de wrote:
> > > >>
> > > >> Hi all,
> > > >>
> > > >> we discovered a problem with properties defined in a pom.xml.
> > > >>
> > > >> Properties could be defined in a pom.xml like:
> > > >>
> > > >> <properties>
> > > >> <myProp>default</myProp>
> > > >> </properties>
> > > >>
> > > >> In a maven plugin we fetch all the properties by calling:
> > > >>
> > > >> Properties projectProps = project.getProperties();
> > > >>
> > > >> Running all this with maven 2 we were able to modify the value of
> > "myProp"
> > > >> within the plugin by:
> > > >>
> > > >> projectProps.put("myProp", "newValue");
> > > >>
> > > >> So after the execution of the plugin, the property <myProp> has the
> > value
> > > >> "newValue".
> > > >>
> > > >> Running all this with maven 3 that does not work anymore.
> > > >
> > > >
> > > >
> > > > First I would say this is by design wrong, cause if you define a
> > property in
> > > > the pom file I would like to be sure that it will be kept the value I
> > have
> > > > given and if a plugin (which could it be) will change that I will be
> > really
> > > > astonished.
> > > >
> > > >
> > > > Apart from that my question: Why do you need to change existing
> > properties
> > > > and why not changing the in the pom which is more clearer than
> > mysteriously
> > > > chaning a property by a plugin?...
> > > >
> > > > Can you give more details about your use case ? Best would be having a
> > real
> > > > workign example and what kind of problems you are trying to solve with
> > this
> > > > approach?
> > > >
> > > >
> > > > Kind regards
> > > > Karl Heinz Marbaise
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > > Here's why this is important.
> > >
> > > Consider a plugin with the job of setting a property, like many of the
> > > build-helper goals, or the build-number plugin.
> > >
> > > Now, consider an IDE. The IDEs don't, in general, know about these
> > > plugins. They get confused when they don't have a value at all. So,
> > > SOP is is to put a harmless default into the POM, and count on the
> > > plugin overwriting it. I have some of these working with 3.3.9, so
> > > there must be something more subtle going on.
> > >
> > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
