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

Reply via email to