Aw: Re: Re: Re: [Regression] Declared properties could not be modified anymore within a plugin
Are there any news regarding this topic?
Kind regards,
Maik
> Gesendet: Montag, 10. Oktober 2016 um 16:01 Uhr
> Von: "Benson Margulies"
> An: "Maven Users List"
> 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
> wrote:
> > That's odd. Let me run my test again.
> >
> >
> > On Mon, Oct 10, 2016 at 8:44 AM, Robert Patrick
> > 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"
> >>> An: "Maven Users List"
> >>> 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
> >>> wrote:
> >>> > On Tue, Oct 4, 2016 at 5:35 AM, M. Richey 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
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"
> An: "Maven Users List"
> 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
> wrote:
> > On Tue, Oct 4, 2016 at 5:35 AM, M. Richey 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"
> >>> An: "Maven Users List" , 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
> >>> 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:
> >>> >>
> >>> >>
> >>> >> default
> >>> >>
> >>> >>
> >>> >> 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 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
> >&
Aw: Re: Re: [Regression] Declared properties could not be modified anymore within a plugin
I tried the build-helper plugin and got the same problem.
Using this configuration
org.codehaus.mojo
build-helper-maven-plugin
1.12
tsp
validate
timestamp-property
tsproperty
will set tsproperty to
[echo] 'tsproperty': 04.10.16 11:16
for example.
But when there is a pre-initialized property like
0
before, the result is:
[echo] 'tsproperty': 0
Kind regards,
Maik
> Gesendet: Dienstag, 04. Oktober 2016 um 14:03 Uhr
> Von: "Stephen Connolly"
> An: "Maven Users List"
> Cc: "i...@soebes.de"
> Betreff: Re: Re: [Regression] Declared properties could not be modified
> anymore within a plugin
>
> https://github.com/mojohaus/build-helper-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/buildhelper/AbstractDefinePropertyMojo.java#L47
>
> would be the recommended way to define a property... I would be interested
> to find out if there is an issue in build-helper... one should be able to
> create a test case using just build-helper to set properties and redefine
> them
>
> On 4 October 2016 at 10:35, M. Richey 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.
> >
> > Kind regards,
> >
> > Maik
> >
> >
> >
> > > Gesendet: Sonntag, 02. Oktober 2016 um 22:04 Uhr
> > > Von: "Benson Margulies"
> > > An: "Maven Users List" , 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
> > 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:
> > > >>
> > > >>
> > > >> default
> > > >>
> > > >>
> > > >> 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 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.
> > > >
> > > >
> > >
Aw: Re: [Regression] Declared properties could not be modified anymore within a plugin
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.
Kind regards,
Maik
> Gesendet: Sonntag, 02. Oktober 2016 um 22:04 Uhr
> Von: "Benson Margulies"
> An: "Maven Users List" , 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
> 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:
> >>
> >>
> >> default
> >>
> >>
> >> 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 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
[Regression] Declared properties could not be modified anymore within a plugin
Hi all,
we discovered a problem with properties defined in a pom.xml.
Properties could be defined in a pom.xml like:
default
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 has the value
"newValue".
Running all this with maven 3 that does not work anymore. One can set the value
of "myProp" to "newValue" in the (same) plugin, but after the execution of the
plugin the value is "default" again. :(
With maven 3 it is working only if the property was not defined in the pom.xml
before - so it is added during the execution of the plugin. But that is not an
option. We do need properties with default values which can be modified
eventually during the build.
Anyone else stumbled upon this problem? Is there a way to get it working again
in maven 3? In my opinion this is a bug, but I couldn't find anything in JIRA.
Thanks in advance.
Best regards,
Maik
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: (Re-)Deploy artifacts to (different) repositories
Thanks Wayne. I'm asking for it because Manfred mentioned that it works with the OSS version as well, just without Smart Proxy. And I would like to get that up and running as soon as possible not waiting until it did it's way through the purchasing department... /Maik Original-Nachricht > Datum: Sun, 11 Mar 2012 19:39:16 -0500 > Von: Wayne Fay > An: Maven Users List > Betreff: Re: (Re-)Deploy artifacts to (different) repositories > > And how to get it done with the OSS version (i.e. without Smart Proxy) > plz? > > Things like this are why some companies choose to pay for Nexus Pro > and how Sonatype chooses to differentiate the OSS from the Pro > versions. > > Wayne > > - > 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
Re: (Re-)Deploy artifacts to (different) repositories
And how to get it done with the OSS version (i.e. without Smart Proxy) plz? Thanks! /Maik Original-Nachricht > Datum: Fri, 09 Mar 2012 18:45:32 -0800 > Von: Manfred Moser > An: users@maven.apache.org > Betreff: Re: (Re-)Deploy artifacts to (different) repositories > Thanks Tamas. You beat me to it ;-) > > On 12-03-09 02:35 AM, Tamás Cservenák wrote: > > For Smart Proxy, see here: > > http://sonatype.com/books/nexus-book/reference/_introduction.html > > > > On Fri, Mar 9, 2012 at 11:21 AM, M. Richey wrote: > >> Hi Manfred, can you please support us with a link to the corresponding > parts in the book? > >> > >> Thanks in advance! > >> > >> /Maik > >> > >> > >> Original-Nachricht > >>> Datum: Thu, 8 Mar 2012 13:27:44 -0800 > >>> Von: "Manfred Moser" > >>> An: "Maven Users List" > >>> Betreff: Re: (Re-)Deploy artifacts to (different) repositories > >>> With the oss version you have to optimize the Expiration Setting for > each > >>> repository Configuration > >>> > >>> However setting those expiration times to low values will result in > >>> additional chatter between the instances and impact performance a bit. > >>> > >>> If you have a multi instance corporate deployment I would definitely > >>> recommend the Pro version > >>> > >>> Manfred > >>> > >>> PS: Disclaimer.. I am currently the trainer for the Sonatype Nexus > online > >>> trainings, have created the material and updated the book with the 2.0 > >>> features.. > >>> > >>> On Thu, March 8, 2012 1:11 pm, M. Richey wrote: > >>>> Thank you all for your replies. Propagating artifacts using Smart > Proxy > >>> is > >>>> a feature only available in the pro version of nexus, right? Is it > also > >>>> possible with the "normal" version somehow? > >>>> > >>>> /Maik > >>>> > >>>> Original-Nachricht > >>>>> Datum: Thu, 8 Mar 2012 10:07:59 -0800 > >>>>> Von: "Manfred Moser" > >>>>> An: "Maven Users List" > >>>>> Betreff: Re: (Re-)Deploy artifacts to (different) repositories > >>>>> Deploy to one repository server and set up proxy repository servers > for > >>>>> the different teams. > >>>>> > >>>>> With Nexus you would use a P2P setup of multiple servers with Smart > >>>>> Proxy > >>>>> .. I am sure other repo servers offer something similar. > >>>>> > >>>>> manfred > >>>>> > >>>>> On Thu, March 8, 2012 6:13 am, M. Richey wrote: > >>>>>> Hi everyone, > >>>>>> > >>>>>> we would like to make our artifacts available for our teams being > >>>>> spread > >>>>>> across different locations. > >>>>>> > >>>>>> So what would be the best way to do that? > >>>>>> > >>>>>> We did a mvn install before. So all projects are build already. > >>>>> Therefore > >>>>>> it would be great if we could use the projects artifacts (or the > ones > >>>>> from > >>>>>> the local repository) and deploy it to the different repositories. > >>> But > >>>>>> executing mvn deploy more than once, will cause maven to reassemble > >>>>> all > >>>>>> the artifacts which is just wasting time. And afaik the is no way > to > >>>>>> deploy to different repositories in one go. > >>>>>> > >>>>>> Is there a way to do it like that? Can you use the local repository > >>> to > >>>>>> deploy from there? Any other ideas on how to get this done? > >>>>>> > >>>>>> Thanks in advance! > >>>>>> > >>>>>> Kind regards, > >>>>>> > >>>>>> Maik > >>>>>> > >>>>>> > - > >>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >>>>>> For additional commands,
Re: (Re-)Deploy artifacts to (different) repositories
Hi Manfred, can you please support us with a link to the corresponding parts in the book? Thanks in advance! /Maik Original-Nachricht > Datum: Thu, 8 Mar 2012 13:27:44 -0800 > Von: "Manfred Moser" > An: "Maven Users List" > Betreff: Re: (Re-)Deploy artifacts to (different) repositories > With the oss version you have to optimize the Expiration Setting for each > repository Configuration > > However setting those expiration times to low values will result in > additional chatter between the instances and impact performance a bit. > > If you have a multi instance corporate deployment I would definitely > recommend the Pro version > > Manfred > > PS: Disclaimer.. I am currently the trainer for the Sonatype Nexus online > trainings, have created the material and updated the book with the 2.0 > features.. > > On Thu, March 8, 2012 1:11 pm, M. Richey wrote: > > > > Thank you all for your replies. Propagating artifacts using Smart Proxy > is > > a feature only available in the pro version of nexus, right? Is it also > > possible with the "normal" version somehow? > > > > /Maik > > > > Original-Nachricht > >> Datum: Thu, 8 Mar 2012 10:07:59 -0800 > >> Von: "Manfred Moser" > >> An: "Maven Users List" > >> Betreff: Re: (Re-)Deploy artifacts to (different) repositories > > > >> Deploy to one repository server and set up proxy repository servers for > >> the different teams. > >> > >> With Nexus you would use a P2P setup of multiple servers with Smart > >> Proxy > >> .. I am sure other repo servers offer something similar. > >> > >> manfred > >> > >> On Thu, March 8, 2012 6:13 am, M. Richey wrote: > >> > > >> > Hi everyone, > >> > > >> > we would like to make our artifacts available for our teams being > >> spread > >> > across different locations. > >> > > >> > So what would be the best way to do that? > >> > > >> > We did a mvn install before. So all projects are build already. > >> Therefore > >> > it would be great if we could use the projects artifacts (or the ones > >> from > >> > the local repository) and deploy it to the different repositories. > But > >> > executing mvn deploy more than once, will cause maven to reassemble > >> all > >> > the artifacts which is just wasting time. And afaik the is no way to > >> > deploy to different repositories in one go. > >> > > >> > Is there a way to do it like that? Can you use the local repository > to > >> > deploy from there? Any other ideas on how to get this done? > >> > > >> > Thanks in advance! > >> > > >> > Kind regards, > >> > > >> > Maik > >> > > >> > - > >> > 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
Re: (Re-)Deploy artifacts to (different) repositories
Thank you all for your replies. Propagating artifacts using Smart Proxy is a feature only available in the pro version of nexus, right? Is it also possible with the "normal" version somehow? /Maik Original-Nachricht > Datum: Thu, 8 Mar 2012 10:07:59 -0800 > Von: "Manfred Moser" > An: "Maven Users List" > Betreff: Re: (Re-)Deploy artifacts to (different) repositories > Deploy to one repository server and set up proxy repository servers for > the different teams. > > With Nexus you would use a P2P setup of multiple servers with Smart Proxy > .. I am sure other repo servers offer something similar. > > manfred > > On Thu, March 8, 2012 6:13 am, M. Richey wrote: > > > > Hi everyone, > > > > we would like to make our artifacts available for our teams being spread > > across different locations. > > > > So what would be the best way to do that? > > > > We did a mvn install before. So all projects are build already. > Therefore > > it would be great if we could use the projects artifacts (or the ones > from > > the local repository) and deploy it to the different repositories. But > > executing mvn deploy more than once, will cause maven to reassemble all > > the artifacts which is just wasting time. And afaik the is no way to > > deploy to different repositories in one go. > > > > Is there a way to do it like that? Can you use the local repository to > > deploy from there? Any other ideas on how to get this done? > > > > Thanks in advance! > > > > Kind regards, > > > > Maik > > > > - > > 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
Re: RE: (Re-)Deploy artifacts to (different) repositories
Thanks for your reply Roy. Could you please explain how this propagation works? Thanks! Maik Original-Nachricht > Datum: Thu, 8 Mar 2012 08:25:41 -0600 > Von: "Lyons, Roy" > An: Maven Users List > Betreff: RE: (Re-)Deploy artifacts to (different) repositories > Most distributed teams would use nexus for that. deploy once, propagate > many. > > -----Original Message- > From: M. Richey [mailto:mric...@gmx.de] > Sent: Thursday, March 08, 2012 8:14 AM > To: Maven Users List > Subject: (Re-)Deploy artifacts to (different) repositories > > > Hi everyone, > > we would like to make our artifacts available for our teams being spread > across different locations. > > So what would be the best way to do that? > > We did a mvn install before. So all projects are build already. Therefore > it would be great if we could use the projects artifacts (or the ones from > the local repository) and deploy it to the different repositories. But > executing mvn deploy more than once, will cause maven to reassemble all the > artifacts which is just wasting time. And afaik the is no way to deploy to > different repositories in one go. > > Is there a way to do it like that? Can you use the local repository to > deploy from there? Any other ideas on how to get this done? > > Thanks in advance! > > Kind regards, > > Maik > > - > 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
(Re-)Deploy artifacts to (different) repositories
Hi everyone, we would like to make our artifacts available for our teams being spread across different locations. So what would be the best way to do that? We did a mvn install before. So all projects are build already. Therefore it would be great if we could use the projects artifacts (or the ones from the local repository) and deploy it to the different repositories. But executing mvn deploy more than once, will cause maven to reassemble all the artifacts which is just wasting time. And afaik the is no way to deploy to different repositories in one go. Is there a way to do it like that? Can you use the local repository to deploy from there? Any other ideas on how to get this done? Thanks in advance! Kind regards, Maik - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Adding modules from within a plugin?
We are generating some views for different devices. For each device we got a XML with the configuration for that device. What is generated then and how is configured in some poms and inherited into the views project. So, the profiles we are using already and the properties for skipping the execution of one or another plugin are therefore the same. That is why I said that I can't imagine how this should be put into poms. Best regards, Maik Original-Nachricht > Datum: Wed, 14 Sep 2011 08:52:50 -0500 > Von: Wayne Fay > An: Maven Users List > Betreff: Re: Adding modules from within a plugin? > >> Maybe you could convert your configuration data into a tailored > aggregator > >> pom, containing the optional modules depending on this data. The > > > Unfortunately that is not an option and won't work either. Thanks for > the idea anyway. Let me know if you got another one. > > Again, I have to ask, why not? You need to tell us specifics if you > want better answers. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Modifying the reactor from within a plugin
Hello everybody, I would like to summarize what we got in the first thread (see http://maven.40175.n5.nabble.com/Adding-modules-from-within-a-plugin-tt4799710.html#none). Problem: We do read some configuration from a XML file using a plugin. Depending on that configuration some other build steps should be executed or skipped. Solution 1: During the execution of the plugin some properties are set which are used in the skip configuration of the following build steps. Unfortunately that doesn't work. The plugins get executed even when the property used is set to true. Another problem is, that not all plugins support the skip configuration. Solution 2: During the execution of the plugin a module is added to the reactor. I tried that by adding that module to the list of modules and setting it using project.getModel().setModules( list ) which has no effect. Solution 3: During the execution of the plugin a profile in the reactor is activated. To be honest I have no idea how to do that. I wasn't able to get the list with the profiles already activated so far. Can someone more experienced with plugin development than me comment please. Your ideas are highly appreciated. Best regards, Maik Richey -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Adding modules from within a plugin?
Unfortunately that is not an option and won't work either. Thanks for the idea anyway. Let me know if you got another one. Regards, Maik Original-Nachricht > Datum: Wed, 14 Sep 2011 07:44:34 +0200 > Von: Ansgar Konermann > An: Maven Users List > Betreff: Re: Adding modules from within a plugin? > Maybe you could convert your configuration data into a tailored aggregator > pom, containing the optional modules depending on this data. The > aggregator > POM could then be used to fire off a maven build. > > Not sure if this fits your use case, but it's at least an idea. > > Best regards > > Ansgar > Am 13.09.2011 21:16 schrieb "M. Richey" : > > > > Hello everybody, > > > > we have some configuration information in XML files I wrote a plugin > for. > The problem is, that depending on that configuration some modules should > be > included in that build. Because activating a profile by properties is not > working properly I would like to either add the modules to the current > build > from within my plugin or activate a profile defining these modules. > > > > Is this possible? How can it be done? Can modules be added to the > current > build or profiles being activated from a plugin? Any help is appreciated! > > > > Thanks in advance! > > > > Regards, > > > > Maik > > > > -- > > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Adding modules from within a plugin?
No worries, we do not think about using the maven-release-plugin... :) Using the skip configuration does not work either. First of all not all plugins do support skip configuration. The second problem is that setting the appropriate property in my plugin does not skip the execution. So at the moment I have no chance to handle my problem? :( Regards, Maik Original-Nachricht > Datum: Tue, 13 Sep 2011 17:21:37 -0400 > Von: Benson Margulies > An: Maven Users List > Betreff: Re: Adding modules from within a plugin? > On Tue, Sep 13, 2011 at 4:12 PM, M. Richey wrote: > > > > Thanks for your reply Benson but what do you mean by saying "using the > maven-release-plugin"? It is too hard changing the module list, right? > > > In a multi-module project, when you run the release plugin, you need > to have *all* of your modules working. Otherwise, the pom versions > won't get updated properly. So having modules appear and disappear in > profiles breaks that. You can get around this by making sure that all > of your profiles are activated whenever you use the release plugin, > but I find that fragile. > > > > > What about activating a profile directly (without properties) from > within the execution of my plugin then? > > I am nearly certain that no plugin can change the reactor content. No > calls to plugins happen before the reactor is all set up. > > > > > Regards, > > > > Maik > > > > > > Original-Nachricht > >> Datum: Tue, 13 Sep 2011 15:46:16 -0400 > >> Von: Benson Margulies > >> An: Maven Users List > >> Betreff: Re: Adding modules from within a plugin? > > > >> On Tue, Sep 13, 2011 at 3:37 PM, Wayne Fay wrote: > >> >> Because activating a profile by properties is not working properly I > >> would > >> >> like to either add the modules to the current build from within my > >> plugin > >> >> or activate a profile defining these modules. > >> > > >> > Can you provide more details about what exactly is not working > properly? > >> > >> There are documented limitations: I think that the relevant one is > >> that you can't activate a profile based on a property value set > >> *inside* a POM, only from a -D from command level. > >> > >> Maik, if you have any idea of ever using the maven-release-plugin, I > >> strongly encourage you to find some solution other than changing the > >> module list. You can use 'skip' configuration parameters to neutralize > >> what happens in unwanted child modules instead. > >> > >> > >> > > >> > >> > Wayne > >> > > >> > - > >> > 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 > >> > > > > -- > > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > > > > - > > 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 > -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Adding modules from within a plugin?
Thanks for your reply Benson but what do you mean by saying "using the maven-release-plugin"? It is too hard changing the module list, right? What about activating a profile directly (without properties) from within the execution of my plugin then? Regards, Maik Original-Nachricht > Datum: Tue, 13 Sep 2011 15:46:16 -0400 > Von: Benson Margulies > An: Maven Users List > Betreff: Re: Adding modules from within a plugin? > On Tue, Sep 13, 2011 at 3:37 PM, Wayne Fay wrote: > >> Because activating a profile by properties is not working properly I > would > >> like to either add the modules to the current build from within my > plugin > >> or activate a profile defining these modules. > > > > Can you provide more details about what exactly is not working properly? > > There are documented limitations: I think that the relevant one is > that you can't activate a profile based on a property value set > *inside* a POM, only from a -D from command level. > > Maik, if you have any idea of ever using the maven-release-plugin, I > strongly encourage you to find some solution other than changing the > module list. You can use 'skip' configuration parameters to neutralize > what happens in unwanted child modules instead. > > > > > > > Wayne > > > > - > > 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 > -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Adding modules from within a plugin?
Setting a property in the plugin which is defined to activate a profile won't activate it because profiles get activated before executing plugins and it is still problematic activating profiles by properties not getting set via -D at the beginning. So I couldn't set a property during the execution of my plugin which activates a profile then. Regards, Maik Original-Nachricht > Datum: Tue, 13 Sep 2011 14:37:42 -0500 > Von: Wayne Fay > An: Maven Users List > Betreff: Re: Adding modules from within a plugin? > > Because activating a profile by properties is not working properly I > would > > like to either add the modules to the current build from within my > plugin > > or activate a profile defining these modules. > > Can you provide more details about what exactly is not working properly? > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Adding modules from within a plugin?
Hello everybody, we have some configuration information in XML files I wrote a plugin for. The problem is, that depending on that configuration some modules should be included in that build. Because activating a profile by properties is not working properly I would like to either add the modules to the current build from within my plugin or activate a profile defining these modules. Is this possible? How can it be done? Can modules be added to the current build or profiles being activated from a plugin? Any help is appreciated! Thanks in advance! Regards, Maik -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-assembly-plugin] Using binaries from submodule instead of executing assembly again
Hi Anders, when moving C outside A how to assemble B and C using the assembly plugin and without installing the artifact before? And why not binding the assembly plugin in project A (which is also an aggregating project)? Thanks for your help! Regards, Maik Original-Nachricht > Datum: Sun, 12 Sep 2010 18:40:40 +0200 > Von: Anders Hammar > An: Maven Users List > Betreff: Re: [maven-assembly-plugin] Using binaries from submodule instead of > executing assembly again > If you execute "mvn package" on the aggregating project, all the modules > will be built. That's how it works. If you don't want that, you need to > move > C outside of the aggregating project. > You shouldn't bind the m-assembly-p in the A projects, but rather put it > in > a module of its own instead. That's best-practice and it will keep you > away > from some issues. > > /Anders > > On Sun, Sep 12, 2010 at 18:02, M. Richey wrote: > > > Hi all, > > > > I've got a question regarding the assembly plugin. Assume we have three > > projetcs called A, B, C. Project B and C are modules of A. C is a multi > > module project itself. Both A and C uses the assembly plugin bind to the > > package phase. My problem is that each time executing mvn package on A > to > > assemble B and C together, module C is rebuild. Instead of rebuilding C > each > > time I would like to use the artifact attached to C (assuming that mvn > > package has been executed on C before). Do anyone know how that can be > done? > > How to avoid rebuilding C again and again? Any ideas? > > > > Thanks in advance! > > > > Kind regards, > > > > Maik > > > > > > -- > > Achtung Sicherheitswarnung: GMX warnt vor Phishing-Attacken! > > http://portal.gmx.net/de/go/sicherheitspaket > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > -- GRATIS: Spider-Man 1-3 sowie 300 weitere Videos! Jetzt freischalten! http://portal.gmx.net/de/go/maxdome - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[maven-assembly-plugin] Using binaries from submodule instead of executing assembly again
Hi all, I've got a question regarding the assembly plugin. Assume we have three projetcs called A, B, C. Project B and C are modules of A. C is a multi module project itself. Both A and C uses the assembly plugin bind to the package phase. My problem is that each time executing mvn package on A to assemble B and C together, module C is rebuild. Instead of rebuilding C each time I would like to use the artifact attached to C (assuming that mvn package has been executed on C before). Do anyone know how that can be done? How to avoid rebuilding C again and again? Any ideas? Thanks in advance! Kind regards, Maik -- Achtung Sicherheitswarnung: GMX warnt vor Phishing-Attacken! http://portal.gmx.net/de/go/sicherheitspaket - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
