That's odd. Let me run my test again.
On Mon, Oct 10, 2016 at 8:44 AM, Robert Patrick <robert.patr...@oracle.com> wrote: > I can confirm that it is not possible to override a project property in a > plugin with Maven 3.3.9. I am not sure what the expected behavior is but > trying to override a pre-initialized value (from command-line -Ds, > .mvn/maven.config, or the POM) from a plugin has no effect... > > > -----Original Message----- > From: M. Richey [mailto:mric...@gmx.de] > Sent: Monday, October 10, 2016 4:16 AM > To: users@maven.apache.org > Cc: Maven Users List > Subject: Aw: Re: Re: [Regression] Declared properties could not be modified > anymore within a plugin > > Thanks Benson, but it does not work for me. > > During the execution it says: > > [main] [DEBUG] define property osgi-version = "1.0.0.v20161010082844" > > But in the MANIFEST.MF it says: > > Manifest-Version: 1.0 > Built-By: maik > demo: bad > Created-By: Apache Maven 3.3.9 > Build-Jdk: 1.8.0_66 > > So, as I said before, during the execution the property gets set and the > pre-initialized value is used afterwards. > > Best regards, > > Maik > > >> Gesendet: Samstag, 08. Oktober 2016 um 16:45 Uhr >> Von: "Benson Margulies" <bimargul...@gmail.com> >> An: "Maven Users List" <users@maven.apache.org> >> Betreff: Re: Re: [Regression] Declared properties could not be >> modified anymore within a plugin >> >> https://github.com/benson-basis/prop-override-example >> >> Seems to be a demo that >> >> https://github.com/basis-technology-corp/basis-build-helper-maven-plug >> in >> >> 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 >> >> > > --------------------------------------------------------------------- > 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
