On Thursday 27 October 2016, Robert Scholte <rfscho...@apache.org> wrote:
> In my opinion it is a good choice to make the MavenProject immutable. This > way the content of the pom.xml will always match the model, no magic. > To adjust properties you could use MavenSession.userProperties instead, > and I would expect that this would result in the same behavior as changing > it in the project directly. Except IIUC those will be available to subsequent projects in the reactor :-( > Will this work for you? > > Robert > > On Thu, 27 Oct 2016 09:12:46 +0200, M. Richey <mric...@gmx.de> wrote: > > Are there any news regarding this topic? >> >> Kind regards, >> >> Maik >> >> Gesendet: Montag, 10. Oktober 2016 um 16:01 Uhr >>> Von: "Benson Margulies" <bimargul...@gmail.com> >>> An: "Maven Users List" <users@maven.apache.org> >>> Betreff: Re: Aw: Re: Re: [Regression] Declared properties could not be >>> modified anymore within a plugin >>> >>> Now I get the same thing you do. I better see what's broken in my builds. >>> >>> >>> On Mon, Oct 10, 2016 at 10:00 AM, Benson Margulies >>> <bimargul...@gmail.com> wrote: >>> > 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-unsubscribe@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 >>> >>> >>> >> --------------------------------------------------------------------- >> 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 > > -- Sent from my phone
