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-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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
