https://github.com/benson-basis/prop-override-example
Seems to be a demo that https://github.com/basis-technology-corp/basis-build-helper-maven-plugin overrides properties. Using: private void defineProperty(String name, String value) { if (getLog().isDebugEnabled()) { getLog().debug("define property " + name + " = \"" + value + "\""); } project.getProperties().put(name, value); } On Tue, Oct 4, 2016 at 4:03 PM, Benson Margulies <bimargul...@gmail.com> wrote: > On Tue, Oct 4, 2016 at 5:35 AM, 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. > > I'd better do a test to ensure that they are working as well as I > think they are and then get back to you. >> >> 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
