Profile activation depending on presence of toolchains file
Hi,
Maven allows the user to specify a toolchains file via its --toolchains
parameter (defaulting to ~/.m2/toolchains.xml).
While useful, this ability to override the file's location is
unfortunately a problem if one wants to make the use of the
maven-toolchains-plugin *conditional* upon the presence of said file:
toolchains
${user.home}/.m2/toolchains.xml
... use maven-toolchains-plugin ...
The above should really check for the presence of the file given via
--toolchains; instead, it *always* checks the *default* file location.
So my question is this: Does Maven set (e.g., during toolchain
initialization [1]) a property that can be queried in a profile?
Best wishes,
Andreas
[1]
signature.asc
Description: OpenPGP digital signature
File based profile activation expanded to full path in original model
Hi all, I am looking at an issue I encountered while using a Maven plugin that uses model returned by MavenProject.getOriginalModel(). I noticed that it returns a Model that is not interpolated (what I expected), with the exception to paths related to file based profile activation. Both when the referenced file is a relative path or when a property is used, the full path is referenced in the original model, rather then the relative path/property related path used in the actual pom file. When this original model is subsequently used to replace the pom file from the file system, it no longer contains the correct activation paths for the profiles. Did a run into an issue here or is it expected that the original model may contain interpolated properties in relation to profile activation? During debugging I noticed that where the model is loaded (DefaultModelBuilder) two Model objects are maintained (tmpModel and rawModel), and that the 'rawModel' is used to determine the active profiles. It is in that logic the profile activation gets updated with expanded paths. Would it be possible to use tmpModel for the purpose of determining the active profiles instead? Best regards, Arnoud Glimmerveen Disclaimer: If you are not the intended recipient of this email, please notify the sender and delete it. Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
RE: [EXTERNAL] Re: project.basedir in file-based profile activation
If I recall correctly, in this specific place you are still supposed to use
${basedir} instead of project.basedir
Am 23.06.2017 3:02 nachm. schrieb "Justin Georgeson" :
> -Original Message-
> From: Jörg Schaible [mailto:joerg.schai...@bpm-inspire.com]
> Sent: Friday, June 23, 2017 1:03 AM
> To: users@maven.apache.org
> Subject: [EXTERNAL] Re: project.basedir in file-based profile activation
>
> External Sender: Use caution with links/attachments.
>
>
>
> Justin Georgeson wrote:
>
> > With 3.3.9 and 3.5.0 When I use this
> >
> >
> >
> > my-profile-id
> >
> >
> > ${project.basedir}${file.separator}somefile.txt
> >
> >
> >
> >
> >
> >
> > I see this warning
> >
> > [WARNING] Some problems were encountered while building the effective
> > [model for com.example:basedir:jar:1.0-SNAPSHOT WARNING]
> > ['profiles.profile[my-profile-id].activation.file.exists' Failed to
> > [interpolate file location
> > ${project.basedir}${file.separator}somefile.txt
> > [for profile jacoco-read-manifest: ${project.basedir} expression not
> > [supported during profile activation, use ${basedir} instead
> >
> > I was under the impression that ${basedir} is deprecated in favor of
> > ${project.basedir}, many years ago at that.
>
> That won't help, because string substitution did not happen yet at the
time
> profiles are activated. There's only a special support for ${user.home}
and
> ${env.HOME}, but that's it. Anything else cannot not work.
So it's a bad message in that the problem is having used a property at all,
rather than having used that specific property?
> > Side note, is it actually worthwhile to use ${file.separator} like
> > this, or is that generally only useful when you're outputting stuff to
> > the user and want it to look pretty?
>
> Use normal slashes.
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
--
This e-mail, including any attached files, may contain confidential and
privileged information for the sole use of the intended recipient. Any
review, use, distribution, or disclosure by others is strictly prohibited.
If you are not the intended recipient (or authorized to receive information
for the intended recipient), please contact the sender by reply e-mail and
delete all copies of this message.
RE: [EXTERNAL] Re: project.basedir in file-based profile activation
> -Original Message-
> From: Jörg Schaible [mailto:joerg.schai...@bpm-inspire.com]
> Sent: Friday, June 23, 2017 1:03 AM
> To: users@maven.apache.org
> Subject: [EXTERNAL] Re: project.basedir in file-based profile activation
>
> External Sender: Use caution with links/attachments.
>
>
>
> Justin Georgeson wrote:
>
> > With 3.3.9 and 3.5.0 When I use this
> >
> >
> >
> > my-profile-id
> >
> >
> > ${project.basedir}${file.separator}somefile.txt
> >
> >
> >
> >
> >
> >
> > I see this warning
> >
> > [WARNING] Some problems were encountered while building the effective
> > [model for com.example:basedir:jar:1.0-SNAPSHOT WARNING]
> > ['profiles.profile[my-profile-id].activation.file.exists' Failed to
> > [interpolate file location
> > ${project.basedir}${file.separator}somefile.txt
> > [for profile jacoco-read-manifest: ${project.basedir} expression not
> > [supported during profile activation, use ${basedir} instead
> >
> > I was under the impression that ${basedir} is deprecated in favor of
> > ${project.basedir}, many years ago at that.
>
> That won't help, because string substitution did not happen yet at the time
> profiles are activated. There's only a special support for ${user.home} and
> ${env.HOME}, but that's it. Anything else cannot not work.
So it's a bad message in that the problem is having used a property at all,
rather than having used that specific property?
> > Side note, is it actually worthwhile to use ${file.separator} like
> > this, or is that generally only useful when you're outputting stuff to
> > the user and want it to look pretty?
>
> Use normal slashes.
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
--
This e-mail, including any attached files, may contain confidential and
privileged information for the sole use of the intended recipient. Any review,
use, distribution, or disclosure by others is strictly prohibited. If you are
not the intended recipient (or authorized to receive information for the
intended recipient), please contact the sender by reply e-mail and delete all
copies of this message.
Re: project.basedir in file-based profile activation
Justin Georgeson wrote:
> With 3.3.9 and 3.5.0 When I use this
>
>
>
> my-profile-id
>
>
> ${project.basedir}${file.separator}somefile.txt
>
>
>
>
>
>
> I see this warning
>
> [WARNING] Some problems were encountered while building the effective
> [model for com.example:basedir:jar:1.0-SNAPSHOT WARNING]
> ['profiles.profile[my-profile-id].activation.file.exists' Failed to
> [interpolate file location ${project.basedir}${file.separator}somefile.txt
> [for profile jacoco-read-manifest: ${project.basedir} expression not
> [supported during profile activation, use ${basedir} instead
>
> I was under the impression that ${basedir} is deprecated in favor of
> ${project.basedir}, many years ago at that.
That won't help, because string substitution did not happen yet at the time
profiles are activated. There's only a special support for ${user.home} and
${env.HOME}, but that's it. Anything else cannot not work.
> Side note, is it actually worthwhile to use ${file.separator} like this,
> or is that generally only useful when you're outputting stuff to the user
> and want it to look pretty?
Use normal slashes.
Cheers,
Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
project.basedir in file-based profile activation
With 3.3.9 and 3.5.0 When I use this
my-profile-id
${project.basedir}${file.separator}somefile.txt
I see this warning
[WARNING] Some problems were encountered while building the effective model for
com.example:basedir:jar:1.0-SNAPSHOT
[WARNING] 'profiles.profile[my-profile-id].activation.file.exists' Failed to
interpolate file location ${project.basedir}${file.separator}somefile.txt for
profile jacoco-read-manifest: ${project.basedir} expression not supported
during profile activation, use ${basedir} instead
I was under the impression that ${basedir} is deprecated in favor of
${project.basedir}, many years ago at that.
Side note, is it actually worthwhile to use ${file.separator} like this, or is
that generally only useful when you're outputting stuff to the user and want it
to look pretty?
--
This e-mail, including any attached files, may contain confidential and
privileged information for the sole use of the intended recipient. Any review,
use, distribution, or disclosure by others is strictly prohibited. If you are
not the intended recipient (or authorized to receive information for the
intended recipient), please contact the sender by reply e-mail and delete all
copies of this message.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: profile activation on property set but !value vs property not set
Hi,
platform!all
means that the profile will be active when the system property
"platform" is not defined, or is defined with a value different than
"all". Put another way, it is always active unless "platform" is equal
to "all". This explains your observations, where both platform-reactor
and default-reactor are active when the system property isn't set.
There was the JIRA MNGSITE-293, in which the documentation was clarified
to reflect this.
Guillaume
Le 12/03/2017 à 05:00, Justin Georgeson a écrit :
Seeing that I can ! the property value in a profile activation, I assumed there
were three states to consider when evaluating the property activation:
1. Property not set
2. Property set and value does not match
3. Property set and value does match
With this assumption I thought that with profiles such as these
default-reactor
!platform
platform-reactor
platform!all
all-platforms-reactor
platformall
I would only see one of the three profiles active at a time. However when I run
Maven 'mvn help:active-profiles' with no 'platform' property then both the
'default-reactor' and 'platform-reactor' are active. When I set the 'platform'
property then I see the behavior I expected. Looking at the source
https://github.com/apache/maven/blob/38300cf2832e9a40198091aa9e0bf6d3dbc3268d/maven-model-builder/src/main/java/org/apache/maven/model/profile/activation/PropertyProfileActivator.java#L95
It's doing a string compare of the activation's declared property value against the
context's property value, but it's not checking the context has a property set. But I
would infer from the comment on L94 ("we have a value, so it has to match the system
value...") that an unset property should not match a !value activation.
Should I open a JIRA issue as a bug, or as a feature request?
--
This e-mail, including any attached files, may contain confidential and
privileged information for the sole use of the intended recipient. Any review,
use, distribution, or disclosure by others is strictly prohibited. If you are
not the intended recipient (or authorized to receive information for the
intended recipient), please contact the sender by reply e-mail and delete all
copies of this message.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
profile activation on property set but !value vs property not set
Seeing that I can ! the property value in a profile activation, I assumed there
were three states to consider when evaluating the property activation:
1. Property not set
2. Property set and value does not match
3. Property set and value does match
With this assumption I thought that with profiles such as these
default-reactor
!platform
platform-reactor
platform!all
all-platforms-reactor
platformall
I would only see one of the three profiles active at a time. However when I run
Maven 'mvn help:active-profiles' with no 'platform' property then both the
'default-reactor' and 'platform-reactor' are active. When I set the 'platform'
property then I see the behavior I expected. Looking at the source
https://github.com/apache/maven/blob/38300cf2832e9a40198091aa9e0bf6d3dbc3268d/maven-model-builder/src/main/java/org/apache/maven/model/profile/activation/PropertyProfileActivator.java#L95
It's doing a string compare of the activation's declared property value against
the context's property value, but it's not checking the context has a property
set. But I would infer from the comment on L94 ("we have a value, so it has to
match the system value...") that an unset property should not match a !value
activation.
Should I open a JIRA issue as a bug, or as a feature request?
--
This e-mail, including any attached files, may contain confidential and
privileged information for the sole use of the intended recipient. Any review,
use, distribution, or disclosure by others is strictly prohibited. If you are
not the intended recipient (or authorized to receive information for the
intended recipient), please contact the sender by reply e-mail and delete all
copies of this message.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: [EXTERNAL] RE: profile activation with multiple conditions
Hi Justin, Justin Georgeson wrote: > Thanks. I was hoping that it would evaluate the file-based activation per > project. I was treating it as a separate issue than the multiple > conditions. But I think what you're saying is that the profile activation > happens once for the whole reactor, and not per project within the > reactor. I gather that you're saying if the keystore file doesn't exist > when I first run maven, then the keystore profile will be activated for > all projects in the reactor. Is that correct? Yes. I've verified this with 3.3.9 and 3.2.5. Fails for 3.1.1, i.e. 3.1.1 implements OR. > I'm still seeing the > keystore profile activate from the property alone even if the keystore > file already exists before I run the mvn command. So that still suggests > that it's doing an or of the conditions rather than an and. Running 'mvn > -N -X help:active-profiles -Djarsigner.keystore.scm.url' isn't giving any > debug info on the profile activation unfortunately. Keep in mind, that activation is resolved on base of the location of the current project's POM, i.e. if your file-based activation uses a relative path that is only valid from the parent POM's directory, it does not work for the projects inheriting that parent. E.g. a profile declared in a parent POM activated on existence of src/main/java will be active for any current project compiling Java sources for the main artifact. > My goal here is to have as much of the build process as possible > self-contained in the POM files and executed from a single mvn command. Why don't you simply activate the profile based on the property only and declare in this profile the keystore as (provided) dependency, copying it with the dependency plugin somewhere to target and configure the jarsigner plugin to use it from that location (plugins also defined in this' profile settings)? Cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: [EXTERNAL] RE: profile activation with multiple conditions
Thanks. I was hoping that it would evaluate the file-based activation per project. I was treating it as a separate issue than the multiple conditions. But I think what you're saying is that the profile activation happens once for the whole reactor, and not per project within the reactor. I gather that you're saying if the keystore file doesn't exist when I first run maven, then the keystore profile will be activated for all projects in the reactor. Is that correct? I'm still seeing the keystore profile activate from the property alone even if the keystore file already exists before I run the mvn command. So that still suggests that it's doing an or of the conditions rather than an and. Running 'mvn -N -X help:active-profiles -Djarsigner.keystore.scm.url' isn't giving any debug info on the profile activation unfortunately. My goal here is to have as much of the build process as possible self-contained in the POM files and executed from a single mvn command. > -Original Message- > From: Jörg Schaible [mailto:joerg.schai...@gmx.de] > Sent: Tuesday, November 10, 2015 4:26 PM > To: users@maven.apache.org > Subject: [EXTERNAL] RE: profile activation with multiple conditions > > Justin Georgeson wrote: > > > So here's a minimal parent pom.xml, which lists 2 child modules that I > > created with 'mvn archetype:generate' choosing the > > 'maven-archetype-quickstart' archetype. My goal was that if I > > > > mvn package > > > > Then the compile/test/package occurs with no attempt to sign. But then > > by changing the command to > > > > mvn package -Djarsigner.keystore.scm.url=... > > -Djarsigner.keystore.scm.user=... -Djarsigner.keystore.scm.password=... \ > > -Djarsigner.storepass=... > > > > Then it checks out a single copy of the keystore during the package > > phase of the parent project, and the jarsigner profile automatically > > activates during each of the modules due to the presence of the keystore > > file. > > > > Instead it's deleting the keystore and checking out the keystore file > > during every project (or instead of and of profile activation > > conditions), and the jarsigner profile is not automatically activated. > > Profile activation is quite the first thing Maven does. So, the file has to be > already there when Maven starts. > > Form your description I got the impression that you "create" somehow the file > during the build and expects then that Maven takes it into consideration for > profile activation. That will never happen. And this has nothing to do with > multiple profile conditions. > > Cheers, > Jörg > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org
RE: profile activation with multiple conditions
Justin Georgeson wrote: > So here's a minimal parent pom.xml, which lists 2 child modules that I > created with 'mvn archetype:generate' choosing the > 'maven-archetype-quickstart' archetype. My goal was that if I > > mvn package > > Then the compile/test/package occurs with no attempt to sign. But then by > changing the command to > > mvn package -Djarsigner.keystore.scm.url=... > -Djarsigner.keystore.scm.user=... -Djarsigner.keystore.scm.password=... \ > -Djarsigner.storepass=... > > Then it checks out a single copy of the keystore during the package phase > of the parent project, and the jarsigner profile automatically activates > during each of the modules due to the presence of the keystore file. > > Instead it's deleting the keystore and checking out the keystore file > during every project (or instead of and of profile activation conditions), > and the jarsigner profile is not automatically activated. Profile activation is quite the first thing Maven does. So, the file has to be already there when Maven starts. Form your description I got the impression that you "create" somehow the file during the build and expects then that Maven takes it into consideration for profile activation. That will never happen. And this has nothing to do with multiple profile conditions. Cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: profile activation with multiple conditions
So here's a minimal parent pom.xml, which lists 2 child modules that I created
with 'mvn archetype:generate' choosing the 'maven-archetype-quickstart'
archetype. My goal was that if I
mvn package
Then the compile/test/package occurs with no attempt to sign. But then by
changing the command to
mvn package -Djarsigner.keystore.scm.url=...
-Djarsigner.keystore.scm.user=... -Djarsigner.keystore.scm.password=... \
-Djarsigner.storepass=...
Then it checks out a single copy of the keystore during the package phase of
the parent project, and the jarsigner profile automatically activates during
each of the modules due to the presence of the keystore file.
Instead it's deleting the keystore and checking out the keystore file during
every project (or instead of and of profile activation conditions), and the
jarsigner profile is not automatically activated.
> -Original Message-
> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
> Sent: Friday, November 06, 2015 9:39 AM
> To: Maven Users List
> Subject: [EXTERNAL] RE: profile activation with multiple conditions
>
> Sorry about that crazy URL, I think that's a network security service my
> employer just signed up with.
>
> > -Original Message-
> > From: Justin Georgeson [mailto:jgeorge...@lgc.com]
> > Sent: Friday, November 06, 2015 9:34 AM
> > To: users@maven.apache.org
> > Subject: [EXTERNAL] profile activation with multiple conditions
> >
> > I have a profile defined in my parent POM which I'm trying to activate
> > like this
> >
> >
> >
> > jarsigner.keystore.scm.url
> >
> >
> > ${keystore.dir}
> >
> >
> >
> > The goal is that when run with -Djarsigner.keystore.scm.url the
> > keystore will be checked out from SCM, but I don't want it to do that
> > for every module in a multi-module build. I thought that activation
> > was switched from OR to AND in 3.2.2[1] but I'm using 3.2.5 and I'm
> > seeing this profile as active when the property is set even though the
> > path exists. I thought maybe it's because ${keystore.dir} is a folder
> > instead of a file, so I tried it with a file but that had no effect. I
> > can work around it by having an extra checkout in the CI configuration
> > but I'd prefer to keep it self-contained in the 'mvn package' lifecycle of
> > the
> build.
> >
> > [1] https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__issues.apache.org_jira_browse_MNG-
> > 2D4565&d=CwIFAg&c=PskvixtEUDK7wuWU-
> >
> tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm
> >
> BCjCmEiTk&m=qSnekx007UIfFuC5Su7wwnAxDOG6yBCpBC5PyZFv2d0&s=ypg5E
> > ApiZkSAidXlZV394CNaIG3j8JF9HTM0DLm3rRQ&e=
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
com.lgc
parent
1.0.0-SNAPSHOT
pom
module1
module2
keystore
jarsigner.keystore.scm.url
${user.dir}/target/keystore/iacode.keystore
maven-scm-plugin
1.9.1
scm-get-keystore
prepare-package
export
${jarsigner.keystore.scm.url}
${user.dir}/target/keystore
${jarsigner.keystore.scm.user}
${jarsigner.keystore.scm.password}
jarsigner
${user.dir}/target/keystore
RE: profile activation with multiple conditions
Sorry about that crazy URL, I think that's a network security service my
employer just signed up with.
> -Original Message-
> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
> Sent: Friday, November 06, 2015 9:34 AM
> To: users@maven.apache.org
> Subject: [EXTERNAL] profile activation with multiple conditions
>
> I have a profile defined in my parent POM which I'm trying to activate like
> this
>
>
>
> jarsigner.keystore.scm.url
>
>
> ${keystore.dir}
>
>
>
> The goal is that when run with -Djarsigner.keystore.scm.url the keystore will
> be
> checked out from SCM, but I don't want it to do that for every module in a
> multi-module build. I thought that activation was switched from OR to AND in
> 3.2.2[1] but I'm using 3.2.5 and I'm seeing this profile as active when the
> property is set even though the path exists. I thought maybe it's because
> ${keystore.dir} is a folder instead of a file, so I tried it with a file but
> that had no
> effect. I can work around it by having an extra checkout in the CI
> configuration
> but I'd prefer to keep it self-contained in the 'mvn package' lifecycle of the
> build.
>
> [1] https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__issues.apache.org_jira_browse_MNG-
> 2D4565&d=CwIFAg&c=PskvixtEUDK7wuWU-
> tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm
> BCjCmEiTk&m=qSnekx007UIfFuC5Su7wwnAxDOG6yBCpBC5PyZFv2d0&s=ypg5E
> ApiZkSAidXlZV394CNaIG3j8JF9HTM0DLm3rRQ&e=
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
profile activation with multiple conditions
I have a profile defined in my parent POM which I'm trying to activate like this
jarsigner.keystore.scm.url
${keystore.dir}
The goal is that when run with -Djarsigner.keystore.scm.url the keystore will
be checked out from SCM, but I don't want it to do that for every module in a
multi-module build. I thought that activation was switched from OR to AND in
3.2.2[1] but I'm using 3.2.5 and I'm seeing this profile as active when the
property is set even though the path exists. I thought maybe it's because
${keystore.dir} is a folder instead of a file, so I tried it with a file but
that had no effect. I can work around it by having an extra checkout in the CI
configuration but I'd prefer to keep it self-contained in the 'mvn package'
lifecycle of the build.
[1] https://issues.apache.org/jira/browse/MNG-4565
RE: Work-around to the Maven restriction on AND condition profile activation?
Thanks for that ingenious solution. It worked perfectly. -- View this message in context: http://maven.40175.n5.nabble.com/Work-around-to-the-Maven-restriction-on-AND-condition-profile-activation-tp5782919p5783107.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Work-around to the Maven restriction on AND condition profile activation?
Hi Dave,
I don't what is the purpose of your double activation profile but I did
something that could help you.
I implement 2 profiles: "should-i-do-something" and "do-something".
- The "should-i-do-something" profile is automatically activated by the
existence of a file in a project, but the phase of all plugins involved was set
to "none" (that's the trick)
- The "do-something" profile is activated on demand and just set the phase(s)
of the plugins involved in the previous profile
Hope this help,
Benoît.
-Message d'origine-
De : laredotornado-3 [mailto:laredotorn...@gmail.com]
Envoyé : vendredi 31 janvier 2014 22:19
À : users@maven.apache.org
Objet : Work-around to the Maven restriction on AND condition profile
activation?
Hi,
I’m using Maven 3.1.1 and Java 1.6. From reading over posts online, it seems a
profile cannot be activated based on two conditions (i.e. there is no such
thing as logical AND in Maven profile activation). So I was wondering if
someone knows of a work-around for what I want to do. I want to run a plugin
if a flag is given on the command line (“-DdeployWars”) and a file is present
in my module, e.g.
${basedir}/src/main/webapp/WEB-INF/web.xml
Unfortunately, its not an option to include the AND profile activation
extension (https://github.com/johnjcool/and-activation-profile-selector) in our
Maven installation, unless there is some way to reference that extension from
the Maven project itself.
Thanks for your thoughts, - Dave
--
View this message in context:
http://maven.40175.n5.nabble.com/Work-around-to-the-Maven-restriction-on-AND-condition-profile-activation-tp5782919.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
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
Work-around to the Maven restriction on AND condition profile activation?
Hi,
I’m using Maven 3.1.1 and Java 1.6. From reading over posts online, it
seems a profile cannot be activated based on two conditions (i.e. there is
no such thing as logical AND in Maven profile activation). So I was
wondering if someone knows of a work-around for what I want to do. I want
to run a plugin if a flag is given on the command line (“-DdeployWars”) and
a file is present in my module, e.g.
${basedir}/src/main/webapp/WEB-INF/web.xml
Unfortunately, its not an option to include the AND profile activation
extension (https://github.com/johnjcool/and-activation-profile-selector) in
our Maven installation, unless there is some way to reference that extension
from the Maven project itself.
Thanks for your thoughts, - Dave
--
View this message in context:
http://maven.40175.n5.nabble.com/Work-around-to-the-Maven-restriction-on-AND-condition-profile-activation-tp5782919.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.1 profile activation
Hi,
you don't need to add a new profile. the new plugin is still compatible
with maven 3.0.x (See comment [1])
[1] http://jira.codehaus.org/browse/MSONAR-22
Vincent
2013/8/9 Lyons, Roy
>
> So... They released sonar-maven-plugin 2.1... and my corporate pom is
> nice enough to developers to choose the right sonar plugin based on maven
> version...
>
>
> maven-2
>
>
>
> ${basedir}
>
>
> ...
>
> maven-3
>
>
>
> ${basedir}
>
>
>
> Now I have a problem...
>
> The profile maven-3 will be activated for 3.1, and I have no currently
> known way to determine if it is 3.1 or not.
>
>
> I am looking to get some suggestions from the community as to the best way
> to compensate for this issue. I don't see any new variables I can test,
> and I dont see any properties which show the maven version...
>
>
>
>
> Thanks,
>
> Roy Lyons
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Maven 3.1 profile activation
So... They released sonar-maven-plugin 2.1... and my corporate pom is nice
enough to developers to choose the right sonar plugin based on maven version...
maven-2
${basedir}
...
maven-3
${basedir}
Now I have a problem...
The profile maven-3 will be activated for 3.1, and I have no currently known
way to determine if it is 3.1 or not.
I am looking to get some suggestions from the community as to the best way to
compensate for this issue. I don't see any new variables I can test, and I
dont see any properties which show the maven version...
Thanks,
Roy Lyons
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Profile activation for mac and linux
I know this is an old thread, but for the lurkers of the internets, I might post a possible answer. In stead of using "family" as the identifier, one could use "name" - either in stead of or in addition to "family". The following should thus be an unambigious activation unix Linux You can get the os name by running "mvn help:system |grep os.name" -- View this message in context: http://maven.40175.n5.nabble.com/Profile-activation-for-mac-and-linux-tp3263043p5661715.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Combining profile activation parameters doesn't work
Well my builds are working on every machine ;-) That's why I used profiles, the way it was described in the settings reference, to simplify testing on several different machines (Windows, Linux, 32bit, 64bit ...) And they work fine as long as I use only one condition for every profile. The problem is, that they don't work as described in the settings reference, when I use more than one condition. -- View this message in context: http://maven.40175.n5.nabble.com/Combining-profile-activation-parameters-doesn-t-work-tp5154834p5157799.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Combining profile activation parameters doesn't work
It appears that profiles are intrinsically evil and more people misuse profiles than any other part of Maven. I suspect that there are valid use cases for profiles but most of the time, they seem to cause people a lot more problems than they fix and they seem to encourage software development patterns that are the opposite of best practices. Profile use seems to be a black hole that attracts new users and previous Ant users. Until you have your build working properly without profiles, my advice is to stay away from them. Once you have your build working, then take a look at profiles to see if you can consolidate or simplify your builds with them. Free advice and worth every penny. Ron On 19/01/2012 3:58 AM, gorgophol wrote: If anybody is interested. This Bug can be found here ... And it seems nobody really wants to fix it. http://jira.codehaus.org/browse/MNG-4565 http://jira.codehaus.org/browse/MNG-4516 http://jira.codehaus.org/browse/MNG-3328 -- View this message in context: http://maven.40175.n5.nabble.com/Combining-profile-activation-parameters-doesn-t-work-tp5154834p5157134.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Combining profile activation parameters doesn't work
If anybody is interested. This Bug can be found here ... And it seems nobody really wants to fix it. http://jira.codehaus.org/browse/MNG-4565 http://jira.codehaus.org/browse/MNG-4516 http://jira.codehaus.org/browse/MNG-3328 -- View this message in context: http://maven.40175.n5.nabble.com/Combining-profile-activation-parameters-doesn-t-work-tp5154834p5157134.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Combining profile activation parameters doesn't work
http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-activation.html "5.3.1. Activation Configuration Activations can contain one of more selectors including JDK versions, Operating System parameters, files, and properties. A profile is activated when all activation criteria has been satisfied. For example, a profile could list an Operating System family of Windows, and a JDK version of 1.4, this profile will only be activated when the build is executed on a Windows machine running Java 1.4." That means my profiles should work ... Anybody else had similar problems? I definitaly can activate Windows and Unix profiles at the same time on the same machine, just by adding a property. -- View this message in context: http://maven.40175.n5.nabble.com/Combining-profile-activation-parameters-doesn-t-work-tp5154834p5156971.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Profile activation by OS/Arch and by Property doesn't work
Ok. I mastered it :-) I have to use the to combine them. -- View this message in context: http://maven.40175.n5.nabble.com/Profile-activation-by-OS-Arch-and-by-Property-doesn-t-work-tp5154834p5154899.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Profile activation by OS/Arch and by Property doesn't work
Hi, I'm using Maven to install two pieces of Software on several testing machines. I defined a profile in the settings.xml of every machine for every Software-OS-Arch combination I try to test. If the correct profile is activated, several properties are set, to identify the correct artifact to download from the nexus repository, to set the correct setup-executable and the correct installation directory, which are used later by a POM to install the right version of the right software to the specified directory. All with one POM and just different profiles in settings.xml. My profiles look like the following: win_32_cadenza Windows x86 environment CadenzaCD WIN32 response_win32.varfile Setup-Windows.exe Cadenza autodeploy The other profiles are nearly identical, but they are activated by amd64 (or x64) for example and a different environment value (GISterm) for the other software. My problem is, that more than one of these profiles is activated. Even the profile with unix is activated on a Windows-machine! I test it, with mvn help:active-profiles -Denvironment=CadenzaCD. Response is: - nexus (source: settings.xml) - win_32_cadenza (source: settings.xml) - win_32_gisterm (source: settings.xml) - win_amd64_cadenza (source: settings.xml) - win_x64_cadenza (source: settings.xml) - linux_cadenza (source: settings.xml) An interesting thing is, that on the win-32bit-machine both software-profiles (Cadenza and GISterm) are activated (even I set the property to CadenzaCD and NOT GIStermCD), while the other profiles (which should definitely not run on a windows-32-bit machine) only list the Cadenza-Profiles. Can anybody explain this behaviour to me? Thanks. Benjamin -- View this message in context: http://maven.40175.n5.nabble.com/Profile-activation-by-OS-Arch-and-by-Property-doesn-t-work-tp5154834p5154834.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Profile activation based on property absence OR property value of "false"
Yes you can, try: !true See http://svn.codehaus.org/mojo/trunk/mojo/sql-maven-plugin/pom.xml > Date: Mon, 24 Oct 2011 17:30:24 -0400 > Subject: Profile activation based on property absence OR property value of > "false" > From: ljnel...@gmail.com > To: users@maven.apache.org > > It looks like activating a profile based on EITHER the absence of a property > OR the presence of that property with a particular value is not possible. > Is that correct? > > For example, suppose I wanted to add in a bunch of plugins if the > "skipTests" property was (a) specified with a value of "false" or (b) not > specified at all. It looks like I cannot activate a profile that takes (a) > and (b) into account. > > Best, > Laird > > -- > http://about.me/lairdnelson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Profile activation based on property absence OR property value of "false"
It looks like activating a profile based on EITHER the absence of a property OR the presence of that property with a particular value is not possible. Is that correct? For example, suppose I wanted to add in a bunch of plugins if the "skipTests" property was (a) specified with a value of "false" or (b) not specified at all. It looks like I cannot activate a profile that takes (a) and (b) into account. Best, Laird -- http://about.me/lairdnelson
inherited profile activation
To start, I've searched the archives and JIRA and read through a lot
of the background on this issue. For instance,
http://jira.codehaus.org/browse/MNG-2363
With that said, I'm still wondering what the current capability is for
profile activation and what the future direction, if any, is planned
for this feature. In my example setup, a Parent POM has a profile
defined with an activation rule of
${basedir}/somefile
If the child project has this file, the profile is still not activated.
If the parent project has this file, the profile will be activated for
the parent, but not for the child.
If I move the profile and activation rule to the child project, I can
then run the mvn reactor on the parent and the profile will be
activated for the child if the file exists. I think this last point
is what mng-2363 addresses.
So, with that said, I'd really like to be able to define the profiles
and activation rules in a parent pom, and have the profile activation
triggered within a child pom if the rules are met within the context
of that child pom. Further, I don't want to have to specifiy a system
property or explicit profile on the command line.
Anyone know what the future direction of the profile activation is
going to be? Are there any plans to change this behavior?
Thanks,
Dave
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
profile activation
Hello,
I like to activate profiles from within a profile. (Or is there an other way
to achieve my goal ?)
For example I have multiple profiles which are activated in different
circumstances. Sometimes none of them are activated and sometimes more are
activated:
- integration-test-tomcat-profile
- integration-test-jetty-profile
- my-personal-special-profile
- company-special-profile
- exotic-verry-unknown-profile
- buildserver-profile
Our buildserver manager doesn't know any details about these profiles, he
just knows our buildserver-profile should be trigger when the buildserver
builds the project.
Normally I would use a property to activate the profile, but these profile
already have property activation. When I add a second property I have to set
both of them (or can I use OR somehow?), but my buildadmin only knows about
one. I don't wan't hem to know about the other properties.
It is up to the developer of the project to correctly configure the
'buildserver-profile'. This is why would like to configure (add) active
profiles from the 'buildserver-profile'.
I tried something like (in MyMojo):
public void execute() throws MojoExecutionException {
...
Profile p = getProfile(allProfiles, profileId);
p.setActivation(new AlwaysOnActivation());
project.setActiveProfiles(updatedActiveProfiles);
But the added profiles aren't executed.
I don't feel this is the way to go, but I can't think of an alternative.
Any tips please ?
Best regards,
Raymond
--
View this message in context:
http://maven.40175.n5.nabble.com/profile-activation-tp4315068p4315068.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Known bugs in profile activation in Maven 3.0.1?
I have default properties listed in my pom like this: false create drop-and-create-tables buildSchema(foreignKeys=true) I have a profile that is activated like this: liquibase src/main/resources/META-INF/liquibase/changelog.xml liquibaseTestingEnabled true false none validate When I run help:effective-pom without any command line arguments, and with an existing src/main/resources/META-INF/liquibase/changelog.xml file, the properties section of the effective pom contains this: false false none validate Note that although I have not specified one of the conditions for profile activation, that profile's property settings have been applied. It's like the profile was activated, even though one of its conditions for activation--namely the presence of a liquibaseTestingEnabled property whose value is true--is not in fact true. mvn help:active-profiles does not list the liquibase profile in its output. The output of effective pom also doesn't list a section at all. Um, what on earth is going on here? Thanks, Laird
Re: File profile activation
It appeared to exhibit the same behavior for me in 3.0.0 and 2.1.0, which are the versions I keep around. I see that the JIRA is marked fixed in 3, so either it's not so fixed, or I made some methodological experiment in trying it in 3 as well as 2.1. On Sun, Dec 12, 2010 at 2:46 PM, Wendy Smoak wrote: > On Sun, Dec 12, 2010 at 1:57 PM, Benson Margulies > wrote: >> In a parent profile, I have a profile that is supposed to activate >> based on the presence of a file in the tree of the child that uses the >> parent. It does not, and -X is not helping me ... since it seems to >> contradict itself. I must be missing something simple here, no? > > What version of Maven? Sounds like: http://jira.codehaus.org/browse/MNG-2363 > > -- > Wendy > > - > 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: File profile activation
On Sun, Dec 12, 2010 at 1:57 PM, Benson Margulies wrote: > In a parent profile, I have a profile that is supposed to activate > based on the presence of a file in the tree of the child that uses the > parent. It does not, and -X is not helping me ... since it seems to > contradict itself. I must be missing something simple here, no? What version of Maven? Sounds like: http://jira.codehaus.org/browse/MNG-2363 -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
File profile activation
In a parent profile, I have a profile that is supposed to activate
based on the presence of a file in the tree of the child that uses the
parent. It does not, and -X is not helping me ... since it seems to
contradict itself. I must be missing something simple here, no?
[DEBUG] Profile with id: 'package-daemon' has been explicitly activated.
[INFO] Listing Profiles for Project: com.basistech.jug:jdd-server:jar:2-SNAPSHOT
Profile Id: package-daemon (Active: false , Source: pom)
package-daemon
${basedir}/src/main/jsw/wrapper.conf
...
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Profile activation by properties
Hi, is there any possibility to activate a Maven profile if a system property has either value "A" OR value "B" but NOT if it has value "C"? Unfortunately it is neither allowed to specify multiple "value" entries like this: playground myProp A B Nor to specify more than one "property" element like this: playground myProp A myProp B I also tried all kind of separators in the "value" value (e.g. A,B or A;B), however, nothing seems to work. If it is not supported now, is there any chance that it will be supported in a future Maven version? Thanks in advance, Jörn - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Profile activation for mac and linux
Hi! I would like to have a bunch of properties set differently for Mac, Linux and Windows. So I have inserted this linux unix mac mac windows windows This works because on Linux only unix is activated and on the mac unix AND mac are activated but the mac profile overrides the unix/linux values. Now imho this is kind of error prone. With the wrong order it would not work or if the order in a Maven version becomes random it might or might not work. So my question is if there is a better way and if I should file a bug around this? Any thoughts? manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: profile activation confusion
On Wed, Oct 27, 2010 at 11:41 AM, Anders Hammar wrote: > You either need to separate the configuration from the binaries, or have > different artifacts. > The configuration is separated from the binaries for the most part. however some artifacts (like a war file) have environment specific class path names in them. But an integral part of our build process is to generate the config files read by the binary artifacts at runtime. Add to that some of the "almost source" files like wsdl endup having server names embedded in them (compliments of oracle). But what do you mean by different artifacts? Its not practical to have the build create artifacts for every environment due to our parallel releases process. if Im testing the 3.0 release in the QA2 environment, thats all I want to build. Creating artifacts for an environment that will never be used is a waste of time and resources. > > Your current solution does not work if you do deploys to a repo and adhere > to the very important Maven rule that a release may NEVER be altered. > Unfortunately I cant change that. The only thing that doesnt change between environments is the source code.
Re: profile activation confusion
You either need to separate the configuration from the binaries, or have different artifacts. Your current solution does not work if you do deploys to a repo and adhere to the very important Maven rule that a release may NEVER be altered. /Anders On Wed, Oct 27, 2010 at 18:52, Jon Paynter wrote: > On Wed, Oct 27, 2010 at 5:51 AM, Jörg Schaible >wrote: > > > Anders Hammar wrote: > > > > > You need Maven 3.0 to be able to activate profiles in the pom by > > > properties set in a profile in settings.xml. > > > > The point is that this functionality is superfluous. If you want a > profile > > be activated based on properties in settings.xml, you may as well simply > > add > > it there to your activeProfiles section. Works also for M2. > > im using maven 3.0. I ended up defining a property inside an already > alwaysActive profile in the settings.xml. Rather a kludge - but it works. > > > On Wed, Oct 27, 2010 at 5:44 AM, Ron Wheeler < > rwhee...@artifact-software.com > > wrote: > > > On 27/10/2010 1:51 AM, Anders Hammar wrote: > > > >> While on the topic, I'd like to mention that having a different build > >> (through profiles for example) for each environment is not good. In > Maven, > >> there can only be one flavor of a released artifact. So if you build > v1.0 > >> of > >> your war, cannot rebuild it with a different content. > >> > >> What you should do is build different artifacts for each environment. > Use > >> classifiers or, in my opinion even better, different Maven projects. > This > >> have been discussed several times on this list about a month ago or so. > >> > >> And should be in the "Best Practices" section of the documentation so > > that people know that this is settled law. > > > I need something that supports parallel releases. We have 3 QA > environments, 1 or more of which can have a release that is being tested to > go into production. So for example: QA1 would have v3.0 currently under > test with a scheduled release date in september, and then QA2 would have > v3.1 under test with a scheduled release date in November. Currently each > environment has a properties fie containing environment specific values and > the build. So based on the target environment for a given build, the > appropiate properties file is used for filtering. While this doesnt seem > to > fit well with the maven way - it works for us. > > What would you suggest as an alternative? >
Re: profile activation confusion
Anders Hammar wrote: > You need Maven 3.0 to be able to activate profiles in the pom by > properties set in a profile in settings.xml. The point is that this functionality is superfluous. If you want a profile be activated based on properties in settings.xml, you may as well simply add it there to your activeProfiles section. Works also for M2. - Jörg > > /Anders > > On Wed, Oct 27, 2010 at 01:44, Jörg Schaible > wrote: > >> Jon Paynter wrote: >> >> > On Tue, Oct 26, 2010 at 4:12 PM, Jörg Schaible >> > wrote: >> > >> >> Hi Jon, >> >> >> >> >> >> > what am I missing here? >> >> >> >> It does simply not work this way. You cannot activate a profile by a >> >> property defined in the current or parent POM. Profiles are resolved >> >> first to build the final POM in use. See help:effective-pom. >> >> >> >> - Jörg >> >> >> >> Well that explains the source of my confusion. I'll just find another >> >> way >> > to accomplish the same thing. >> >> You can set system properties calling Maven or define properties in your >> settings.xml (IIRC). Those are respected for the profile activation. >> >> >> >> - >> 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: profile activation confusion
On 27/10/2010 1:51 AM, Anders Hammar wrote: While on the topic, I'd like to mention that having a different build (through profiles for example) for each environment is not good. In Maven, there can only be one flavor of a released artifact. So if you build v1.0 of your war, cannot rebuild it with a different content. What you should do is build different artifacts for each environment. Use classifiers or, in my opinion even better, different Maven projects. This have been discussed several times on this list about a month ago or so. And should be in the "Best Practices" section of the documentation so that people know that this is settled law. /Anders On Tue, Oct 26, 2010 at 23:42, Jon Paynter wrote: Im trying to setup some build profiles for our various build environments (dev, qa, prod, etc). but I cant get the 'dev' profile to be active. The envType property is set to a default value of 'dev' in my top level pom, but it will sometimes be given on the command line, and in that case, activate the appropiate profile for qa, or production. The problem is I cant get the dev profile to activate by just setting property values inside my pom. Fragment from my pom: dev UTF-8 UTF-8 SFP401 and then the profiles: dev envType dev based on the documentation I would think the dev profile would be active all the time. but when I run 'mvn help:active-profiles' I see: Active Profiles for Project 'myCompoany:app:pom:2.1': The following profiles are active: - nexus (source: settings.xml) however if I run: 'mvn help:active-profiles -DenvType=dev' then I see: Active Profiles for Project 'myCompany:app:pom:2.1': The following profiles are active: - nexus (source: settings.xml) - dev (source: settings.xml) what am I missing here? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: profile activation confusion
While on the topic, I'd like to mention that having a different build (through profiles for example) for each environment is not good. In Maven, there can only be one flavor of a released artifact. So if you build v1.0 of your war, cannot rebuild it with a different content. What you should do is build different artifacts for each environment. Use classifiers or, in my opinion even better, different Maven projects. This have been discussed several times on this list about a month ago or so. /Anders On Tue, Oct 26, 2010 at 23:42, Jon Paynter wrote: > Im trying to setup some build profiles for our various build environments > (dev, qa, prod, etc). but I cant get the 'dev' profile to be active. The > envType property is set to a default value of 'dev' in my top level pom, > but > it will sometimes be given on the command line, and in that case, activate > the appropiate profile for qa, or production. The problem is I cant get > the > dev profile to activate by just setting property values inside my pom. > > Fragment from my pom: > >dev >UTF-8 > > UTF-8 >SFP401 > > > and then the profiles: > >dev > > >envType >dev > > > > based on the documentation I would think the dev profile would be active > all > the time. but when I run 'mvn help:active-profiles' I see: > Active Profiles for Project 'myCompoany:app:pom:2.1': > > The following profiles are active: > > - nexus (source: settings.xml) > > however if I run: 'mvn help:active-profiles -DenvType=dev' then I see: > Active Profiles for Project 'myCompany:app:pom:2.1': > > The following profiles are active: > > - nexus (source: settings.xml) > - dev (source: settings.xml) > > > what am I missing here? >
Re: profile activation confusion
You need Maven 3.0 to be able to activate profiles in the pom by properties set in a profile in settings.xml. /Anders On Wed, Oct 27, 2010 at 01:44, Jörg Schaible wrote: > Jon Paynter wrote: > > > On Tue, Oct 26, 2010 at 4:12 PM, Jörg Schaible > > wrote: > > > >> Hi Jon, > >> > >> > >> > what am I missing here? > >> > >> It does simply not work this way. You cannot activate a profile by a > >> property defined in the current or parent POM. Profiles are resolved > >> first to build the final POM in use. See help:effective-pom. > >> > >> - Jörg > >> > >> Well that explains the source of my confusion. I'll just find another > >> way > > to accomplish the same thing. > > You can set system properties calling Maven or define properties in your > settings.xml (IIRC). Those are respected for the profile activation. > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: profile activation confusion
Jon Paynter wrote: > On Tue, Oct 26, 2010 at 4:12 PM, Jörg Schaible > wrote: > >> Hi Jon, >> >> >> > what am I missing here? >> >> It does simply not work this way. You cannot activate a profile by a >> property defined in the current or parent POM. Profiles are resolved >> first to build the final POM in use. See help:effective-pom. >> >> - Jörg >> >> Well that explains the source of my confusion. I'll just find another >> way > to accomplish the same thing. You can set system properties calling Maven or define properties in your settings.xml (IIRC). Those are respected for the profile activation. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: profile activation confusion
On Tue, Oct 26, 2010 at 4:12 PM, Jörg Schaible wrote: > Hi Jon, > > > > what am I missing here? > > It does simply not work this way. You cannot activate a profile by a > property defined in the current or parent POM. Profiles are resolved first > to build the final POM in use. See help:effective-pom. > > - Jörg > > Well that explains the source of my confusion. I'll just find another way to accomplish the same thing.
Re: profile activation confusion
Hi Jon, Jon Paynter wrote: > Im trying to setup some build profiles for our various build environments > (dev, qa, prod, etc). but I cant get the 'dev' profile to be active. The > envType property is set to a default value of 'dev' in my top level pom, > but it will sometimes be given on the command line, and in that case, > activate > the appropiate profile for qa, or production. The problem is I cant get > the dev profile to activate by just setting property values inside my pom. > > Fragment from my pom: > > dev > UTF-8 > > UTF-8 > SFP401 > > > and then the profiles: > > dev > > > envType > dev > > > > based on the documentation I would think the dev profile would be active > all > the time. but when I run 'mvn help:active-profiles' I see: > Active Profiles for Project 'myCompoany:app:pom:2.1': > > The following profiles are active: > > - nexus (source: settings.xml) > > however if I run: 'mvn help:active-profiles -DenvType=dev' then I see: > Active Profiles for Project 'myCompany:app:pom:2.1': > > The following profiles are active: > > - nexus (source: settings.xml) > - dev (source: settings.xml) > > > what am I missing here? It does simply not work this way. You cannot activate a profile by a property defined in the current or parent POM. Profiles are resolved first to build the final POM in use. See help:effective-pom. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
profile activation confusion
Im trying to setup some build profiles for our various build environments (dev, qa, prod, etc). but I cant get the 'dev' profile to be active. The envType property is set to a default value of 'dev' in my top level pom, but it will sometimes be given on the command line, and in that case, activate the appropiate profile for qa, or production. The problem is I cant get the dev profile to activate by just setting property values inside my pom. Fragment from my pom: dev UTF-8 UTF-8 SFP401 and then the profiles: dev envType dev based on the documentation I would think the dev profile would be active all the time. but when I run 'mvn help:active-profiles' I see: Active Profiles for Project 'myCompoany:app:pom:2.1': The following profiles are active: - nexus (source: settings.xml) however if I run: 'mvn help:active-profiles -DenvType=dev' then I see: Active Profiles for Project 'myCompany:app:pom:2.1': The following profiles are active: - nexus (source: settings.xml) - dev (source: settings.xml) what am I missing here?
Re: maven3 profile activation by absense of property
Thanks everybody, it is now fixed.
Joachim
On 10/21/2010 01:57 PM, Frederic Camblor wrote:
Hi !
With!key I don't reproduce the problem with maven 3, but I
reproduce it with mvnsh 0.10 (based on maven 3.0-alpha6) context history.
myprofile
!blah
[mvn 2.2.1]
- mvn help:active-profiles
shows myprofile is activated
- mvn help:active-profiles -Dblah
shows myprofile is deactivated
- mvn help:active-profiles -Dblah=blah
shows myprofile is deactivated
[mvnsh (based on mvn 3.0-alpha6]
- mvn help:active-profiles
shows myprofile is activated
- mvn help:active-profiles -Dblah
shows myprofile is deactivated
- mvn help:active-profiles -Dblah=blah
shows myprofile is deactivated
... re-running mvn help:active-profiles shows myprofile is de-activated !
[mvn 3.0]
- mvn help:active-profiles
shows myprofile is activated
- mvn help:active-profiles -Dblah
shows myprofile is deactivated
- mvn help:active-profiles -Dblah=blah
shows myprofile is deactivated
Frédéric
On Wed, Oct 20, 2010 at 8:15 PM, Kees van Dierenwrote:
Joachim,
Profiles can be activated by a property not having a certain value. This
includes the absence of a property. For you the profile would become:
documentation
skipDocs
!true
...
Profile activation can easily be checked with:
mvn help:active-profiles -DskipDocs
mvn help:active-profiles -DskipDocs=true
mvn help:active-profiles -DskipDocs=false
(not specifying a value makes it true).
Regards,
Kees
--
Squins | IT, Honestly
Oranjestraat 23
2983 HL Ridderkerk
The Netherlands
Phone: +31 (0)180 415559
Mobile: +31 (0)6 30413841
www.squins.com
http://twitter.com/keesvandieren
Chamber of commerce Rotterdam: 22048547
Boeken voor school en werk bestel je op studieboekencenter.nl
2010/10/20 Joachim Van der Auwera
On 10/20/2010 12:35 PM, Wendy Smoak wrote:
On Wed, Oct 20, 2010 at 5:32 AM, Joachim Van der Auwera
wrote:
However, since the switch to maven3 this does not worka anymore and
"mvn
-DskipDocs install" will still include the "documentation" module.
Do I have to do something different to make this work in maven3?
What happens if you do "-DskipDocs=abc" ? That will test the
difference between 'present but empty' and 'present (with a value)'.
That doesn't seem to make a difference.
I haven't seen this mentioned in the compatibility notes, so I guess it
is
a bug (though it admittedly is a little documented feature).
Thanks for the help,
Joachim
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Joachim Van der Auwera
PROGS bvba, progs.be
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven3 profile activation by absense of property
Hi ! With !key I don't reproduce the problem with maven 3, but I reproduce it with mvnsh 0.10 (based on maven 3.0-alpha6) context history. myprofile !blah [mvn 2.2.1] - mvn help:active-profiles >> shows myprofile is activated - mvn help:active-profiles -Dblah >> shows myprofile is deactivated - mvn help:active-profiles -Dblah=blah >> shows myprofile is deactivated [mvnsh (based on mvn 3.0-alpha6] - mvn help:active-profiles >> shows myprofile is activated - mvn help:active-profiles -Dblah >> shows myprofile is deactivated - mvn help:active-profiles -Dblah=blah >> shows myprofile is deactivated ... re-running mvn help:active-profiles shows myprofile is de-activated ! [mvn 3.0] - mvn help:active-profiles >> shows myprofile is activated - mvn help:active-profiles -Dblah >> shows myprofile is deactivated - mvn help:active-profiles -Dblah=blah >> shows myprofile is deactivated Frédéric On Wed, Oct 20, 2010 at 8:15 PM, Kees van Dieren wrote: > Joachim, > > Profiles can be activated by a property not having a certain value. This > includes the absence of a property. For you the profile would become: > > > >documentation > > > skipDocs > !true > > > ... > > > > Profile activation can easily be checked with: > mvn help:active-profiles -DskipDocs > mvn help:active-profiles -DskipDocs=true > mvn help:active-profiles -DskipDocs=false > > (not specifying a value makes it true). > > Regards, > > Kees > > -- > Squins | IT, Honestly > Oranjestraat 23 > 2983 HL Ridderkerk > The Netherlands > Phone: +31 (0)180 415559 > Mobile: +31 (0)6 30413841 > www.squins.com > http://twitter.com/keesvandieren > Chamber of commerce Rotterdam: 22048547 > Boeken voor school en werk bestel je op studieboekencenter.nl > 2010/10/20 Joachim Van der Auwera > > > On 10/20/2010 12:35 PM, Wendy Smoak wrote: > > > >> On Wed, Oct 20, 2010 at 5:32 AM, Joachim Van der Auwera > >> wrote: > >> > >> > >>> However, since the switch to maven3 this does not worka anymore and > "mvn > >>> -DskipDocs install" will still include the "documentation" module. > >>> Do I have to do something different to make this work in maven3? > >>> > >>> > >> What happens if you do "-DskipDocs=abc" ? That will test the > >> difference between 'present but empty' and 'present (with a value)'. > >> > >> > > That doesn't seem to make a difference. > > > > I haven't seen this mentioned in the compatibility notes, so I guess it > is > > a bug (though it admittedly is a little documented feature). > > > > > > Thanks for the help, > > Joachim > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: maven3 profile activation by absense of property
Joachim, Profiles can be activated by a property not having a certain value. This includes the absence of a property. For you the profile would become: documentation skipDocs !true ... Profile activation can easily be checked with: mvn help:active-profiles -DskipDocs mvn help:active-profiles -DskipDocs=true mvn help:active-profiles -DskipDocs=false (not specifying a value makes it true). Regards, Kees -- Squins | IT, Honestly Oranjestraat 23 2983 HL Ridderkerk The Netherlands Phone: +31 (0)180 415559 Mobile: +31 (0)6 30413841 www.squins.com http://twitter.com/keesvandieren Chamber of commerce Rotterdam: 22048547 Boeken voor school en werk bestel je op studieboekencenter.nl 2010/10/20 Joachim Van der Auwera > On 10/20/2010 12:35 PM, Wendy Smoak wrote: > >> On Wed, Oct 20, 2010 at 5:32 AM, Joachim Van der Auwera >> wrote: >> >> >>> However, since the switch to maven3 this does not worka anymore and "mvn >>> -DskipDocs install" will still include the "documentation" module. >>> Do I have to do something different to make this work in maven3? >>> >>> >> What happens if you do "-DskipDocs=abc" ? That will test the >> difference between 'present but empty' and 'present (with a value)'. >> >> > That doesn't seem to make a difference. > > I haven't seen this mentioned in the compatibility notes, so I guess it is > a bug (though it admittedly is a little documented feature). > > > Thanks for the help, > Joachim > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven3 profile activation by absense of property
On 10/20/2010 12:35 PM, Wendy Smoak wrote: On Wed, Oct 20, 2010 at 5:32 AM, Joachim Van der Auwera wrote: However, since the switch to maven3 this does not worka anymore and "mvn -DskipDocs install" will still include the "documentation" module. Do I have to do something different to make this work in maven3? What happens if you do "-DskipDocs=abc" ? That will test the difference between 'present but empty' and 'present (with a value)'. That doesn't seem to make a difference. I haven't seen this mentioned in the compatibility notes, so I guess it is a bug (though it admittedly is a little documented feature). Thanks for the help, Joachim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven3 profile activation by absense of property
On Wed, Oct 20, 2010 at 5:32 AM, Joachim Van der Auwera wrote: > However, since the switch to maven3 this does not worka anymore and "mvn > -DskipDocs install" will still include the "documentation" module. > Do I have to do something different to make this work in maven3? What happens if you do "-DskipDocs=abc" ? That will test the difference between 'present but empty' and 'present (with a value)'. That may give you a workaround, and if it worked as 'present but empty' in Maven 2, a JIRA issue with a sample project would be the next step (assuming this isn't called out in the release/compatibility notes, I haven't checked.) -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven3 profile activation by absense of property
Could be a regression then. Create a test project and file a ticket. /Anders On Wed, Oct 20, 2010 at 11:32, Joachim Van der Auwera < joac...@triathlon98.com> wrote: > I am using the following profile > > > > documentation > > > !skipDocs > > > > documentation > > > > > However, since the switch to maven3 this does not worka anymore and "mvn > -DskipDocs install" will still include the "documentation" module. > Do I have to do something different to make this work in maven3? > > Thanks for the help, > Joachim > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
maven3 profile activation by absense of property
I am using the following profile documentation !skipDocs documentation However, since the switch to maven3 this does not worka anymore and "mvn -DskipDocs install" will still include the "documentation" module. Do I have to do something different to make this work in maven3? Thanks for the help, Joachim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Cascading profile activation
On Sat, Oct 2, 2010 at 1:33 PM, Géraud wrote: > Thanks for your answer. So, for the same reason, when "server.type" is > defined as a global property in my pom file, the "type1" profile is not > active. > > But is there a way to automaticallly activate "type1" profile when "env1" > profile is active ? I believe that the answer to this is 'no'. > Géraud > > > 2010/10/1 Anders Hammar > >> Yes, profiles can only be activated by a system property. server.type is a >> maven property, hence it will not activate another profile. >> >> /Anders >> >> On Fri, Oct 1, 2010 at 02:56, Géraud wrote: >> >> > Hi >> > >> > I'm trying to activate a profile inside another profile : >> > here is an example : >> > >> > >> > >> > >> > env1 >> > >> > >> > env >> > 1 >> > >> > >> > >> > type1 >> > >> > >> > >> > >> > >> > >> > >> > type1 >> > >> > >> > server.type >> > type1 >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > when I try to run a maven command, activating "env1" profile, "type1" >> > profile is never activated >> > e.g.: mvn help:active-profiles -Denv=1 >> > >> > I tried with differents configurations : >> > OS: windows XP and Vista >> > Maven: 2.0.9 and 2.2.1 >> > >> > Did I miss something ? >> > >> > Géraud >> > >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Cascading profile activation
Thanks for your answer. So, for the same reason, when "server.type" is defined as a global property in my pom file, the "type1" profile is not active. But is there a way to automaticallly activate "type1" profile when "env1" profile is active ? Géraud 2010/10/1 Anders Hammar > Yes, profiles can only be activated by a system property. server.type is a > maven property, hence it will not activate another profile. > > /Anders > > On Fri, Oct 1, 2010 at 02:56, Géraud wrote: > > > Hi > > > > I'm trying to activate a profile inside another profile : > > here is an example : > > > > > > > > > > env1 > > > > > > env > > 1 > > > > > > > > type1 > > > > > > > > > > > > > > > > type1 > > > > > > server.type > > type1 > > > > > > > > > > > > > > > > > > > > > > > > when I try to run a maven command, activating "env1" profile, "type1" > > profile is never activated > > e.g.: mvn help:active-profiles -Denv=1 > > > > I tried with differents configurations : > > OS: windows XP and Vista > > Maven: 2.0.9 and 2.2.1 > > > > Did I miss something ? > > > > Géraud > > >
Re: Cascading profile activation
Yes, profiles can only be activated by a system property. server.type is a maven property, hence it will not activate another profile. /Anders On Fri, Oct 1, 2010 at 02:56, Géraud wrote: > Hi > > I'm trying to activate a profile inside another profile : > here is an example : > > > > > env1 > > > env > 1 > > > > type1 > > > > > > > > type1 > > > server.type > type1 > > > > > > > > > > > > when I try to run a maven command, activating "env1" profile, "type1" > profile is never activated > e.g.: mvn help:active-profiles -Denv=1 > > I tried with differents configurations : > OS: windows XP and Vista > Maven: 2.0.9 and 2.2.1 > > Did I miss something ? > > Géraud >
Cascading profile activation
Hi I'm trying to activate a profile inside another profile : here is an example : env1 env 1 type1 type1 server.type type1 when I try to run a maven command, activating "env1" profile, "type1" profile is never activated e.g.: mvn help:active-profiles -Denv=1 I tried with differents configurations : OS: windows XP and Vista Maven: 2.0.9 and 2.2.1 Did I miss something ? Géraud
Re: profile activation not detected in a parent pom.xml
This appears to be a bug that has been re-introduced into mvn 2.2.1: http://jira.codehaus.org/browse/MPH-16 I've tried it on two different maven installs using the helptest.zip file attached. On 16 September 2010 16:33, Xavier D. wrote: > I am executing a project's pom.xml directly. It has a parent "common.pom" > (common to many projects). The project is executed directly by mvn. > > Profile details were added into the pom.xml and detected automatically and > when specifying the -P on the command line. > Moving the profile details to the parent, causes the profile not to be > detected automatically or through -P usage. > > I have been testing using: mvn help:active-profiles and mvn -P > developer help:active-profiles > > Am I doing something wrong? >
profile activation not detected in a parent pom.xml
I am executing a project's pom.xml directly. It has a parent "common.pom" (common to many projects). The project is executed directly by mvn. Profile details were added into the pom.xml and detected automatically and when specifying the -P on the command line. Moving the profile details to the parent, causes the profile not to be detected automatically or through -P usage. I have been testing using: mvn help:active-profiles and mvn -P developer help:active-profiles Am I doing something wrong?
Profile activation with file exists using ant pattern
Hello, Judging from http://docs.codehaus.org/display/MAVENUSER/Profiles, I can't use properties in the element of profile activation. Can I use ant pattern ? example : src/main/resources/**/*.gwt.xml regards dom -- View this message in context: http://maven.40175.n5.nabble.com/Profile-activation-with-file-exists-using-ant-pattern-tp510409p510409.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Use profile to define property which is used in another profile activation
profile activation by properties is activation by _SYSTEM_PROPERTIES_ (i.e. -Dname=value on the CLI) so properties defined in the pom will never trigger the profile activation. so profile b being active will never trigger profile A. -Stephen On 19 May 2010 16:48, sebb wrote: > A profile (A) can be automatically activated by a property (P). > > A profile (B) can also define a property (P). > > So if profile B is activated it will define property P. > > Will this then always activate profile A? > > Seems to me that this will depend on the order in which profiles are > processed. > > Is this order documented and guaranteed, or might it change? > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Use profile to define property which is used in another profile activation
A profile (A) can be automatically activated by a property (P). A profile (B) can also define a property (P). So if profile B is activated it will define property P. Will this then always activate profile A? Seems to me that this will depend on the order in which profiles are processed. Is this order documented and guaranteed, or might it change? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: Profile activation with maven & subsystems
Ok thanks a lot for your help! I'll move on with this solution. I'd still be interested in the versions:use-latest-snapshots call, though. -Ursprüngliche Nachricht- Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im Auftrag von Anders Hammar Gesendet: Dienstag, 16. Februar 2010 15:09 An: Maven Users List Betreff: Re: Profile activation with maven & subsystems The the answer is yes, he/she needs to create a new version of the parent. But, I think you're just making things too complicated. A developer just don't all of a sudden want to work with a new version. This is a bigger decision. Also, why don't you start simple without the import poms and then work it from there. Keep all the depMgmt info as far down the chain as possibel to start with and then move it upwards (to a parent) when you've gotten used to how you work. /Anders On Tue, Feb 16, 2010 at 14:58, Moser, Christian wrote: > I think you misunderstood me. I won't put dependency depmgmt-x into the > parent of Z(what would be mnet-parent). I will put it into component Z. > > -Ursprüngliche Nachricht- > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > Auftrag von Anders Hammar > Gesendet: Dienstag, 16. Februar 2010 14:47 > An: Maven Users List > Betreff: Re: Profile activation with maven & subsystems > > If I understand you correctly, the reason for putting this in the parent of > Z is that a developer of Z shouldn't change this. If it's local to Z, it > shouldnit go in the parent... > Having said that, it is always possible to override in a childs > dependencies > section. > > /Anders > > On Tue, Feb 16, 2010 at 14:26, Moser, Christian wrote: > > > Ok I agree with your solution, it will make it less complicated and more > > maintainable. > > > > Ok if I go ahead and add depmgmt-x:1.0.0 to the dependencyManagement > > section of Z(Parent), subsystem X (with released components) is going to > be > > properly referenced by project Z. But what if a developer want's to work > > with subsystem x? Isn't there any other way than editing and installing > pom > > Z(parent) with depmgmt-x-SNAPSHOT? Or is this the procedure in the > fields? > > > > Stephen, could you be more specific on this, please? > > "If you are working locally on two subsystems, you will do > > > > cd subsys1 > > mvn clean install > > cd ../subsys2 > > mvn versions:use-latest-snapshots > > > > to pull in the subsys1 -SNAPSHOTs" > > > > It sounds interesting but I don't get the point of it. Will this load > > depmgmt-x-SNAPSHOT into Z(parent), only local? How does it work? > > > > > http://mojo.codehaus.org/versions-maven-plugin/use-latest-snapshots-mojo.htmlcouldbe > more instructive. > > > > > > > > -Ursprüngliche Nachricht- > > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > > Auftrag von Anders Hammar > > Gesendet: Dienstag, 16. Februar 2010 12:42 > > An: Maven Users List > > Betreff: Re: Profile activation with maven & subsystems > > > > Yes. So you'll have different version of this pom, but it's still just > one > > import pom (artifact). The version will determine if it's a released > > version > > of the dep mgmt set or a dev version (SNAPSHOT). > > > > /Anders > > > > On Tue, Feb 16, 2010 at 10:51, Moser, Christian wrote: > > > > > Every component in a subsystem has a different version. > > > What do you mean with: "ONE import pom per subsystem"? > > > e.g. replacing depmgmt-rel-x & depmgmt-dev-x with depmgmt-x ? If so, > how > > > can I handle different subsystem component-versions in depmgmt-x > without > > > profiles? > > > > > > -Ursprüngliche Nachricht- > > > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > > > Auftrag von Anders Hammar > > > Gesendet: Dienstag, 16. Februar 2010 08:58 > > > An: Maven Users List > > > Betreff: Re: Profile activation with maven & subsystems > > > > > > Don't use profiles, as I said in my previous post. > > > > > > What's the release idea of a subsystem's components - will they all > have > > > the > > > same version number? If so, you could skip the import pom and just > define > > a > > > property for each subsystem's version and use that in your > > > dependencyManagement section. > > > > > > If not, just have ONE import pom per subsystem. The
Re: Profile activation with maven & subsystems
The the answer is yes, he/she needs to create a new version of the parent. But, I think you're just making things too complicated. A developer just don't all of a sudden want to work with a new version. This is a bigger decision. Also, why don't you start simple without the import poms and then work it from there. Keep all the depMgmt info as far down the chain as possibel to start with and then move it upwards (to a parent) when you've gotten used to how you work. /Anders On Tue, Feb 16, 2010 at 14:58, Moser, Christian wrote: > I think you misunderstood me. I won't put dependency depmgmt-x into the > parent of Z(what would be mnet-parent). I will put it into component Z. > > -Ursprüngliche Nachricht- > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > Auftrag von Anders Hammar > Gesendet: Dienstag, 16. Februar 2010 14:47 > An: Maven Users List > Betreff: Re: Profile activation with maven & subsystems > > If I understand you correctly, the reason for putting this in the parent of > Z is that a developer of Z shouldn't change this. If it's local to Z, it > shouldnit go in the parent... > Having said that, it is always possible to override in a childs > dependencies > section. > > /Anders > > On Tue, Feb 16, 2010 at 14:26, Moser, Christian wrote: > > > Ok I agree with your solution, it will make it less complicated and more > > maintainable. > > > > Ok if I go ahead and add depmgmt-x:1.0.0 to the dependencyManagement > > section of Z(Parent), subsystem X (with released components) is going to > be > > properly referenced by project Z. But what if a developer want's to work > > with subsystem x? Isn't there any other way than editing and installing > pom > > Z(parent) with depmgmt-x-SNAPSHOT? Or is this the procedure in the > fields? > > > > Stephen, could you be more specific on this, please? > > "If you are working locally on two subsystems, you will do > > > > cd subsys1 > > mvn clean install > > cd ../subsys2 > > mvn versions:use-latest-snapshots > > > > to pull in the subsys1 -SNAPSHOTs" > > > > It sounds interesting but I don't get the point of it. Will this load > > depmgmt-x-SNAPSHOT into Z(parent), only local? How does it work? > > > > > http://mojo.codehaus.org/versions-maven-plugin/use-latest-snapshots-mojo.htmlcouldbe > more instructive. > > > > > > > > -Ursprüngliche Nachricht- > > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > > Auftrag von Anders Hammar > > Gesendet: Dienstag, 16. Februar 2010 12:42 > > An: Maven Users List > > Betreff: Re: Profile activation with maven & subsystems > > > > Yes. So you'll have different version of this pom, but it's still just > one > > import pom (artifact). The version will determine if it's a released > > version > > of the dep mgmt set or a dev version (SNAPSHOT). > > > > /Anders > > > > On Tue, Feb 16, 2010 at 10:51, Moser, Christian wrote: > > > > > Every component in a subsystem has a different version. > > > What do you mean with: "ONE import pom per subsystem"? > > > e.g. replacing depmgmt-rel-x & depmgmt-dev-x with depmgmt-x ? If so, > how > > > can I handle different subsystem component-versions in depmgmt-x > without > > > profiles? > > > > > > -Ursprüngliche Nachricht- > > > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > > > Auftrag von Anders Hammar > > > Gesendet: Dienstag, 16. Februar 2010 08:58 > > > An: Maven Users List > > > Betreff: Re: Profile activation with maven & subsystems > > > > > > Don't use profiles, as I said in my previous post. > > > > > > What's the release idea of a subsystem's components - will they all > have > > > the > > > same version number? If so, you could skip the import pom and just > define > > a > > > property for each subsystem's version and use that in your > > > dependencyManagement section. > > > > > > If not, just have ONE import pom per subsystem. The version of that pom > > > defines if it's a release or dev (SNAPSHOT). > > > > > > /Anders > > > On Tue, Feb 16, 2010 at 08:44, Moser, Christian > wrote: > > > > > > > Thanks a lot for your fast response! > > > > The file can be found here: > > > > http://www.christian-moser.ch/fx/subsystems.pdf > > &
AW: Profile activation with maven & subsystems
I think you misunderstood me. I won't put dependency depmgmt-x into the parent of Z(what would be mnet-parent). I will put it into component Z. -Ursprüngliche Nachricht- Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im Auftrag von Anders Hammar Gesendet: Dienstag, 16. Februar 2010 14:47 An: Maven Users List Betreff: Re: Profile activation with maven & subsystems If I understand you correctly, the reason for putting this in the parent of Z is that a developer of Z shouldn't change this. If it's local to Z, it shouldnit go in the parent... Having said that, it is always possible to override in a childs dependencies section. /Anders On Tue, Feb 16, 2010 at 14:26, Moser, Christian wrote: > Ok I agree with your solution, it will make it less complicated and more > maintainable. > > Ok if I go ahead and add depmgmt-x:1.0.0 to the dependencyManagement > section of Z(Parent), subsystem X (with released components) is going to be > properly referenced by project Z. But what if a developer want's to work > with subsystem x? Isn't there any other way than editing and installing pom > Z(parent) with depmgmt-x-SNAPSHOT? Or is this the procedure in the fields? > > Stephen, could you be more specific on this, please? > "If you are working locally on two subsystems, you will do > > cd subsys1 > mvn clean install > cd ../subsys2 > mvn versions:use-latest-snapshots > > to pull in the subsys1 -SNAPSHOTs" > > It sounds interesting but I don't get the point of it. Will this load > depmgmt-x-SNAPSHOT into Z(parent), only local? How does it work? > > http://mojo.codehaus.org/versions-maven-plugin/use-latest-snapshots-mojo.htmlcould > be more instructive. > > > > -Ursprüngliche Nachricht- > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > Auftrag von Anders Hammar > Gesendet: Dienstag, 16. Februar 2010 12:42 > An: Maven Users List > Betreff: Re: Profile activation with maven & subsystems > > Yes. So you'll have different version of this pom, but it's still just one > import pom (artifact). The version will determine if it's a released > version > of the dep mgmt set or a dev version (SNAPSHOT). > > /Anders > > On Tue, Feb 16, 2010 at 10:51, Moser, Christian wrote: > > > Every component in a subsystem has a different version. > > What do you mean with: "ONE import pom per subsystem"? > > e.g. replacing depmgmt-rel-x & depmgmt-dev-x with depmgmt-x ? If so, how > > can I handle different subsystem component-versions in depmgmt-x without > > profiles? > > > > -Ursprüngliche Nachricht- > > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > > Auftrag von Anders Hammar > > Gesendet: Dienstag, 16. Februar 2010 08:58 > > An: Maven Users List > > Betreff: Re: Profile activation with maven & subsystems > > > > Don't use profiles, as I said in my previous post. > > > > What's the release idea of a subsystem's components - will they all have > > the > > same version number? If so, you could skip the import pom and just define > a > > property for each subsystem's version and use that in your > > dependencyManagement section. > > > > If not, just have ONE import pom per subsystem. The version of that pom > > defines if it's a release or dev (SNAPSHOT). > > > > /Anders > > On Tue, Feb 16, 2010 at 08:44, Moser, Christian wrote: > > > > > Thanks a lot for your fast response! > > > The file can be found here: > > > http://www.christian-moser.ch/fx/subsystems.pdf > > > > > > Yes im using depmgmt poms with import. Every of the five subsystems can > > be > > > used by any project(in diagram project Z) with different versions, this > > > would mean I had to set 5 project dependent version properties in > project > > > parent pom? (in diagram Z(parent))? > > > Currently Z(parent) contains five profiles, every profile contains the > > > project dependent subsystem versions (4 released subsystems & 1 > snapshot > > > subsystem version). How can i activate those profiles and make the > maven > > > embedder notice that in the (IDE)? > > > > > > Thanks in advance > > > Chris > > > > > > > > > -Ursprüngliche Nachricht- > > > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > > > Auftrag von Anders Hammar > > > Gesendet: Dienstag, 16. Februar 2010 08:04 > > > An: Maven Users List > > > Betreff: Re: Profile activation with
Re: Profile activation with maven & subsystems
If I understand you correctly, the reason for putting this in the parent of Z is that a developer of Z shouldn't change this. If it's local to Z, it shouldnit go in the parent... Having said that, it is always possible to override in a childs dependencies section. /Anders On Tue, Feb 16, 2010 at 14:26, Moser, Christian wrote: > Ok I agree with your solution, it will make it less complicated and more > maintainable. > > Ok if I go ahead and add depmgmt-x:1.0.0 to the dependencyManagement > section of Z(Parent), subsystem X (with released components) is going to be > properly referenced by project Z. But what if a developer want's to work > with subsystem x? Isn't there any other way than editing and installing pom > Z(parent) with depmgmt-x-SNAPSHOT? Or is this the procedure in the fields? > > Stephen, could you be more specific on this, please? > "If you are working locally on two subsystems, you will do > > cd subsys1 > mvn clean install > cd ../subsys2 > mvn versions:use-latest-snapshots > > to pull in the subsys1 -SNAPSHOTs" > > It sounds interesting but I don't get the point of it. Will this load > depmgmt-x-SNAPSHOT into Z(parent), only local? How does it work? > > http://mojo.codehaus.org/versions-maven-plugin/use-latest-snapshots-mojo.htmlcould > be more instructive. > > > > -Ursprüngliche Nachricht- > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > Auftrag von Anders Hammar > Gesendet: Dienstag, 16. Februar 2010 12:42 > An: Maven Users List > Betreff: Re: Profile activation with maven & subsystems > > Yes. So you'll have different version of this pom, but it's still just one > import pom (artifact). The version will determine if it's a released > version > of the dep mgmt set or a dev version (SNAPSHOT). > > /Anders > > On Tue, Feb 16, 2010 at 10:51, Moser, Christian wrote: > > > Every component in a subsystem has a different version. > > What do you mean with: "ONE import pom per subsystem"? > > e.g. replacing depmgmt-rel-x & depmgmt-dev-x with depmgmt-x ? If so, how > > can I handle different subsystem component-versions in depmgmt-x without > > profiles? > > > > -Ursprüngliche Nachricht- > > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > > Auftrag von Anders Hammar > > Gesendet: Dienstag, 16. Februar 2010 08:58 > > An: Maven Users List > > Betreff: Re: Profile activation with maven & subsystems > > > > Don't use profiles, as I said in my previous post. > > > > What's the release idea of a subsystem's components - will they all have > > the > > same version number? If so, you could skip the import pom and just define > a > > property for each subsystem's version and use that in your > > dependencyManagement section. > > > > If not, just have ONE import pom per subsystem. The version of that pom > > defines if it's a release or dev (SNAPSHOT). > > > > /Anders > > On Tue, Feb 16, 2010 at 08:44, Moser, Christian wrote: > > > > > Thanks a lot for your fast response! > > > The file can be found here: > > > http://www.christian-moser.ch/fx/subsystems.pdf > > > > > > Yes im using depmgmt poms with import. Every of the five subsystems can > > be > > > used by any project(in diagram project Z) with different versions, this > > > would mean I had to set 5 project dependent version properties in > project > > > parent pom? (in diagram Z(parent))? > > > Currently Z(parent) contains five profiles, every profile contains the > > > project dependent subsystem versions (4 released subsystems & 1 > snapshot > > > subsystem version). How can i activate those profiles and make the > maven > > > embedder notice that in the (IDE)? > > > > > > Thanks in advance > > > Chris > > > > > > > > > -Ursprüngliche Nachricht- > > > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > > > Auftrag von Anders Hammar > > > Gesendet: Dienstag, 16. Februar 2010 08:04 > > > An: Maven Users List > > > Betreff: Re: Profile activation with maven & subsystems > > > > > > First, the pdf is missing. Without that I'm not sure I fully understand > > > your > > > thoughts. > > > > > > In general, having your dependencies defined by a profile being active > is > > > IMHO bad practice. The biggest reason for this, however possible not so > > > important f
AW: Profile activation with maven & subsystems
Ok I agree with your solution, it will make it less complicated and more maintainable. Ok if I go ahead and add depmgmt-x:1.0.0 to the dependencyManagement section of Z(Parent), subsystem X (with released components) is going to be properly referenced by project Z. But what if a developer want's to work with subsystem x? Isn't there any other way than editing and installing pom Z(parent) with depmgmt-x-SNAPSHOT? Or is this the procedure in the fields? Stephen, could you be more specific on this, please? "If you are working locally on two subsystems, you will do cd subsys1 mvn clean install cd ../subsys2 mvn versions:use-latest-snapshots to pull in the subsys1 -SNAPSHOTs" It sounds interesting but I don't get the point of it. Will this load depmgmt-x-SNAPSHOT into Z(parent), only local? How does it work? http://mojo.codehaus.org/versions-maven-plugin/use-latest-snapshots-mojo.html could be more instructive. -Ursprüngliche Nachricht- Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im Auftrag von Anders Hammar Gesendet: Dienstag, 16. Februar 2010 12:42 An: Maven Users List Betreff: Re: Profile activation with maven & subsystems Yes. So you'll have different version of this pom, but it's still just one import pom (artifact). The version will determine if it's a released version of the dep mgmt set or a dev version (SNAPSHOT). /Anders On Tue, Feb 16, 2010 at 10:51, Moser, Christian wrote: > Every component in a subsystem has a different version. > What do you mean with: "ONE import pom per subsystem"? > e.g. replacing depmgmt-rel-x & depmgmt-dev-x with depmgmt-x ? If so, how > can I handle different subsystem component-versions in depmgmt-x without > profiles? > > -Ursprüngliche Nachricht- > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > Auftrag von Anders Hammar > Gesendet: Dienstag, 16. Februar 2010 08:58 > An: Maven Users List > Betreff: Re: Profile activation with maven & subsystems > > Don't use profiles, as I said in my previous post. > > What's the release idea of a subsystem's components - will they all have > the > same version number? If so, you could skip the import pom and just define a > property for each subsystem's version and use that in your > dependencyManagement section. > > If not, just have ONE import pom per subsystem. The version of that pom > defines if it's a release or dev (SNAPSHOT). > > /Anders > On Tue, Feb 16, 2010 at 08:44, Moser, Christian wrote: > > > Thanks a lot for your fast response! > > The file can be found here: > > http://www.christian-moser.ch/fx/subsystems.pdf > > > > Yes im using depmgmt poms with import. Every of the five subsystems can > be > > used by any project(in diagram project Z) with different versions, this > > would mean I had to set 5 project dependent version properties in project > > parent pom? (in diagram Z(parent))? > > Currently Z(parent) contains five profiles, every profile contains the > > project dependent subsystem versions (4 released subsystems & 1 snapshot > > subsystem version). How can i activate those profiles and make the maven > > embedder notice that in the (IDE)? > > > > Thanks in advance > > Chris > > > > > > -Ursprüngliche Nachricht- > > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > > Auftrag von Anders Hammar > > Gesendet: Dienstag, 16. Februar 2010 08:04 > > An: Maven Users List > > Betreff: Re: Profile activation with maven & subsystems > > > > First, the pdf is missing. Without that I'm not sure I fully understand > > your > > thoughts. > > > > In general, having your dependencies defined by a profile being active is > > IMHO bad practice. The biggest reason for this, however possible not so > > important for you if you have a "subsystem", is that if some other > artifact > > has a dependency to your artifact, they will not the get the correct > > transitive dependencies (or different ones dependending on whatever). > This > > is not portability or reproducibility. > > > > I'm wondering why you just don't simply keep the version of the depmgmt > pom > > (I guess you use import scope for this one?) as a property and update > this > > property as you need. If you want to try a different version it is > possible > > to override a property value from CLI. However, NEVER override for a > > release! The pom should then always contain the correct config. > > > > /Anders > > On Tue, Feb 16, 2010 at 07:33, Moser, Christian wrote: > > > &
Re: Profile activation with maven & subsystems
Yes. So you'll have different version of this pom, but it's still just one import pom (artifact). The version will determine if it's a released version of the dep mgmt set or a dev version (SNAPSHOT). /Anders On Tue, Feb 16, 2010 at 10:51, Moser, Christian wrote: > Every component in a subsystem has a different version. > What do you mean with: "ONE import pom per subsystem"? > e.g. replacing depmgmt-rel-x & depmgmt-dev-x with depmgmt-x ? If so, how > can I handle different subsystem component-versions in depmgmt-x without > profiles? > > -Ursprüngliche Nachricht- > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > Auftrag von Anders Hammar > Gesendet: Dienstag, 16. Februar 2010 08:58 > An: Maven Users List > Betreff: Re: Profile activation with maven & subsystems > > Don't use profiles, as I said in my previous post. > > What's the release idea of a subsystem's components - will they all have > the > same version number? If so, you could skip the import pom and just define a > property for each subsystem's version and use that in your > dependencyManagement section. > > If not, just have ONE import pom per subsystem. The version of that pom > defines if it's a release or dev (SNAPSHOT). > > /Anders > On Tue, Feb 16, 2010 at 08:44, Moser, Christian wrote: > > > Thanks a lot for your fast response! > > The file can be found here: > > http://www.christian-moser.ch/fx/subsystems.pdf > > > > Yes im using depmgmt poms with import. Every of the five subsystems can > be > > used by any project(in diagram project Z) with different versions, this > > would mean I had to set 5 project dependent version properties in project > > parent pom? (in diagram Z(parent))? > > Currently Z(parent) contains five profiles, every profile contains the > > project dependent subsystem versions (4 released subsystems & 1 snapshot > > subsystem version). How can i activate those profiles and make the maven > > embedder notice that in the (IDE)? > > > > Thanks in advance > > Chris > > > > > > -Ursprüngliche Nachricht- > > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > > Auftrag von Anders Hammar > > Gesendet: Dienstag, 16. Februar 2010 08:04 > > An: Maven Users List > > Betreff: Re: Profile activation with maven & subsystems > > > > First, the pdf is missing. Without that I'm not sure I fully understand > > your > > thoughts. > > > > In general, having your dependencies defined by a profile being active is > > IMHO bad practice. The biggest reason for this, however possible not so > > important for you if you have a "subsystem", is that if some other > artifact > > has a dependency to your artifact, they will not the get the correct > > transitive dependencies (or different ones dependending on whatever). > This > > is not portability or reproducibility. > > > > I'm wondering why you just don't simply keep the version of the depmgmt > pom > > (I guess you use import scope for this one?) as a property and update > this > > property as you need. If you want to try a different version it is > possible > > to override a property value from CLI. However, NEVER override for a > > release! The pom should then always contain the correct config. > > > > /Anders > > On Tue, Feb 16, 2010 at 07:33, Moser, Christian wrote: > > > > > We've trouble creating a concept for maven using subsystems. > > > > > > > > > > > > In the attached pdf you can see a maven/subsystem concept. In short, > > we've > > > got a component based software which is based on quiet a lot of > > components > > > (each component is a maven project). Those components are bundled in > > > subsystems. Every subsystem features a parent pom which contains all > > > components of this subsystem as a snapshot version. > > > > > > The snapshot versions are managed by the pom depmgmt-*dev*-*x* in all > > > subsystems. > > > > > > The release versions are managed by the pom depmgmt-*rel*-*x* in all > > > subsystems. > > > > > > > > > > > > As you can see project Z retrieves dependecy versions from > > depmgmt-*dev*-x > > > & depmgmt-*rel*-x from the subsystems *X* & *Y*. Our plan is that we > only > > > want the subsystem a developer currently is working with snapshot > > versions, > > > all other needed subsystems by the project, in th
AW: Profile activation with maven & subsystems
Every component in a subsystem has a different version. What do you mean with: "ONE import pom per subsystem"? e.g. replacing depmgmt-rel-x & depmgmt-dev-x with depmgmt-x ? If so, how can I handle different subsystem component-versions in depmgmt-x without profiles? -Ursprüngliche Nachricht- Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im Auftrag von Anders Hammar Gesendet: Dienstag, 16. Februar 2010 08:58 An: Maven Users List Betreff: Re: Profile activation with maven & subsystems Don't use profiles, as I said in my previous post. What's the release idea of a subsystem's components - will they all have the same version number? If so, you could skip the import pom and just define a property for each subsystem's version and use that in your dependencyManagement section. If not, just have ONE import pom per subsystem. The version of that pom defines if it's a release or dev (SNAPSHOT). /Anders On Tue, Feb 16, 2010 at 08:44, Moser, Christian wrote: > Thanks a lot for your fast response! > The file can be found here: > http://www.christian-moser.ch/fx/subsystems.pdf > > Yes im using depmgmt poms with import. Every of the five subsystems can be > used by any project(in diagram project Z) with different versions, this > would mean I had to set 5 project dependent version properties in project > parent pom? (in diagram Z(parent))? > Currently Z(parent) contains five profiles, every profile contains the > project dependent subsystem versions (4 released subsystems & 1 snapshot > subsystem version). How can i activate those profiles and make the maven > embedder notice that in the (IDE)? > > Thanks in advance > Chris > > > -Ursprüngliche Nachricht- > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > Auftrag von Anders Hammar > Gesendet: Dienstag, 16. Februar 2010 08:04 > An: Maven Users List > Betreff: Re: Profile activation with maven & subsystems > > First, the pdf is missing. Without that I'm not sure I fully understand > your > thoughts. > > In general, having your dependencies defined by a profile being active is > IMHO bad practice. The biggest reason for this, however possible not so > important for you if you have a "subsystem", is that if some other artifact > has a dependency to your artifact, they will not the get the correct > transitive dependencies (or different ones dependending on whatever). This > is not portability or reproducibility. > > I'm wondering why you just don't simply keep the version of the depmgmt pom > (I guess you use import scope for this one?) as a property and update this > property as you need. If you want to try a different version it is possible > to override a property value from CLI. However, NEVER override for a > release! The pom should then always contain the correct config. > > /Anders > On Tue, Feb 16, 2010 at 07:33, Moser, Christian wrote: > > > We've trouble creating a concept for maven using subsystems. > > > > > > > > In the attached pdf you can see a maven/subsystem concept. In short, > we've > > got a component based software which is based on quiet a lot of > components > > (each component is a maven project). Those components are bundled in > > subsystems. Every subsystem features a parent pom which contains all > > components of this subsystem as a snapshot version. > > > > The snapshot versions are managed by the pom depmgmt-*dev*-*x* in all > > subsystems. > > > > The release versions are managed by the pom depmgmt-*rel*-*x* in all > > subsystems. > > > > > > > > As you can see project Z retrieves dependecy versions from > depmgmt-*dev*-x > > & depmgmt-*rel*-x from the subsystems *X* & *Y*. Our plan is that we only > > want the subsystem a developer currently is working with snapshot > versions, > > all other needed subsystems by the project, in this case project Z, are > only > > available with their released components. > > > > > > > > e.g for working with subystem *X*, you need to set in user settings.xml: > > > > subsystem-*x* > > > > > > > > In this case profile subsystem-x gets activated in Z(parent) and resolves > > the snapshot dependencies versions from depmgmt-*dev*-*x* & the released > > dependencies versions from depmgmt-*rel*-*y *by dependency management. > > > > > > > > This is simular to the "reproduce example project" I've uploaded in > > http://jira.codehaus.org/browse/MNG-4538. Not exactely the same, though. > > > > > > > > I was told activating dependen
Re: Profile activation with maven & subsystems
Don't use profile activation to control what dependencies are used There are all sorts of subtle ways in which your build will break if you do that. The simplest way is to accept that you will change your pom.xml files during development. I would keep release versions of dependencies in release versions of your depmgmt poms I would keep -SNAPSHOT versions of dependencies in the -SNAPSHOT versions of your depmgmt poms. If you are working locally on two subsystems, you will do cd subsys1 mvn clean install cd ../subsys2 mvn versions:use-latest-snapshots to pull in the subsys1 -SNAPSHOTs -Stephen On 16 February 2010 07:44, Moser, Christian wrote: > Thanks a lot for your fast response! > The file can be found here: http://www.christian-moser.ch/fx/subsystems.pdf > > Yes im using depmgmt poms with import. Every of the five subsystems can be > used by any project(in diagram project Z) with different versions, this would > mean I had to set 5 project dependent version properties in project parent > pom? (in diagram Z(parent))? > Currently Z(parent) contains five profiles, every profile contains the > project dependent subsystem versions (4 released subsystems & 1 snapshot > subsystem version). How can i activate those profiles and make the maven > embedder notice that in the (IDE)? > > Thanks in advance > Chris > > > -Ursprüngliche Nachricht- > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im Auftrag > von Anders Hammar > Gesendet: Dienstag, 16. Februar 2010 08:04 > An: Maven Users List > Betreff: Re: Profile activation with maven & subsystems > > First, the pdf is missing. Without that I'm not sure I fully understand your > thoughts. > > In general, having your dependencies defined by a profile being active is > IMHO bad practice. The biggest reason for this, however possible not so > important for you if you have a "subsystem", is that if some other artifact > has a dependency to your artifact, they will not the get the correct > transitive dependencies (or different ones dependending on whatever). This > is not portability or reproducibility. > > I'm wondering why you just don't simply keep the version of the depmgmt pom > (I guess you use import scope for this one?) as a property and update this > property as you need. If you want to try a different version it is possible > to override a property value from CLI. However, NEVER override for a > release! The pom should then always contain the correct config. > > /Anders > On Tue, Feb 16, 2010 at 07:33, Moser, Christian wrote: > >> We've trouble creating a concept for maven using subsystems. >> >> >> >> In the attached pdf you can see a maven/subsystem concept. In short, we've >> got a component based software which is based on quiet a lot of components >> (each component is a maven project). Those components are bundled in >> subsystems. Every subsystem features a parent pom which contains all >> components of this subsystem as a snapshot version. >> >> The snapshot versions are managed by the pom depmgmt-*dev*-*x* in all >> subsystems. >> >> The release versions are managed by the pom depmgmt-*rel*-*x* in all >> subsystems. >> >> >> >> As you can see project Z retrieves dependecy versions from depmgmt-*dev*-x >> & depmgmt-*rel*-x from the subsystems *X* & *Y*. Our plan is that we only >> want the subsystem a developer currently is working with snapshot versions, >> all other needed subsystems by the project, in this case project Z, are only >> available with their released components. >> >> >> >> e.g for working with subystem *X*, you need to set in user settings.xml: >> >> subsystem-*x* >> >> >> >> In this case profile subsystem-x gets activated in Z(parent) and resolves >> the snapshot dependencies versions from depmgmt-*dev*-*x* & the released >> dependencies versions from depmgmt-*rel*-*y *by dependency management. >> >> >> >> This is simular to the "reproduce example project" I've uploaded in >> http://jira.codehaus.org/browse/MNG-4538. Not exactely the same, though. >> >> >> >> I was told activating dependencies by settings.xml isn't a good idea and >> like the issue above demonstrates, it doesn't work properly, either. So I >> could go ahead and activate the profile "subsystem-x" by a CLI property. >> This would also work, but isn't really comfortable to working with in IDE's >> because you had to set this for every component by hand or the IDE won't >> find any dependency v
Re: Profile activation with maven & subsystems
Don't use profiles, as I said in my previous post. What's the release idea of a subsystem's components - will they all have the same version number? If so, you could skip the import pom and just define a property for each subsystem's version and use that in your dependencyManagement section. If not, just have ONE import pom per subsystem. The version of that pom defines if it's a release or dev (SNAPSHOT). /Anders On Tue, Feb 16, 2010 at 08:44, Moser, Christian wrote: > Thanks a lot for your fast response! > The file can be found here: > http://www.christian-moser.ch/fx/subsystems.pdf > > Yes im using depmgmt poms with import. Every of the five subsystems can be > used by any project(in diagram project Z) with different versions, this > would mean I had to set 5 project dependent version properties in project > parent pom? (in diagram Z(parent))? > Currently Z(parent) contains five profiles, every profile contains the > project dependent subsystem versions (4 released subsystems & 1 snapshot > subsystem version). How can i activate those profiles and make the maven > embedder notice that in the (IDE)? > > Thanks in advance > Chris > > > -Ursprüngliche Nachricht- > Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im > Auftrag von Anders Hammar > Gesendet: Dienstag, 16. Februar 2010 08:04 > An: Maven Users List > Betreff: Re: Profile activation with maven & subsystems > > First, the pdf is missing. Without that I'm not sure I fully understand > your > thoughts. > > In general, having your dependencies defined by a profile being active is > IMHO bad practice. The biggest reason for this, however possible not so > important for you if you have a "subsystem", is that if some other artifact > has a dependency to your artifact, they will not the get the correct > transitive dependencies (or different ones dependending on whatever). This > is not portability or reproducibility. > > I'm wondering why you just don't simply keep the version of the depmgmt pom > (I guess you use import scope for this one?) as a property and update this > property as you need. If you want to try a different version it is possible > to override a property value from CLI. However, NEVER override for a > release! The pom should then always contain the correct config. > > /Anders > On Tue, Feb 16, 2010 at 07:33, Moser, Christian wrote: > > > We've trouble creating a concept for maven using subsystems. > > > > > > > > In the attached pdf you can see a maven/subsystem concept. In short, > we've > > got a component based software which is based on quiet a lot of > components > > (each component is a maven project). Those components are bundled in > > subsystems. Every subsystem features a parent pom which contains all > > components of this subsystem as a snapshot version. > > > > The snapshot versions are managed by the pom depmgmt-*dev*-*x* in all > > subsystems. > > > > The release versions are managed by the pom depmgmt-*rel*-*x* in all > > subsystems. > > > > > > > > As you can see project Z retrieves dependecy versions from > depmgmt-*dev*-x > > & depmgmt-*rel*-x from the subsystems *X* & *Y*. Our plan is that we only > > want the subsystem a developer currently is working with snapshot > versions, > > all other needed subsystems by the project, in this case project Z, are > only > > available with their released components. > > > > > > > > e.g for working with subystem *X*, you need to set in user settings.xml: > > > > subsystem-*x* > > > > > > > > In this case profile subsystem-x gets activated in Z(parent) and resolves > > the snapshot dependencies versions from depmgmt-*dev*-*x* & the released > > dependencies versions from depmgmt-*rel*-*y *by dependency management. > > > > > > > > This is simular to the "reproduce example project" I've uploaded in > > http://jira.codehaus.org/browse/MNG-4538. Not exactely the same, though. > > > > > > > > I was told activating dependencies by settings.xml isn't a good idea and > > like the issue above demonstrates, it doesn't work properly, either. So I > > could go ahead and activate the profile "subsystem-x" by a CLI property. > > This would also work, but isn't really comfortable to working with in > IDE's > > because you had to set this for every component by hand or the IDE won't > > find any dependency version. Setting these properties in the settings.xml > >
AW: Profile activation with maven & subsystems
Thanks a lot for your fast response! The file can be found here: http://www.christian-moser.ch/fx/subsystems.pdf Yes im using depmgmt poms with import. Every of the five subsystems can be used by any project(in diagram project Z) with different versions, this would mean I had to set 5 project dependent version properties in project parent pom? (in diagram Z(parent))? Currently Z(parent) contains five profiles, every profile contains the project dependent subsystem versions (4 released subsystems & 1 snapshot subsystem version). How can i activate those profiles and make the maven embedder notice that in the (IDE)? Thanks in advance Chris -Ursprüngliche Nachricht- Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im Auftrag von Anders Hammar Gesendet: Dienstag, 16. Februar 2010 08:04 An: Maven Users List Betreff: Re: Profile activation with maven & subsystems First, the pdf is missing. Without that I'm not sure I fully understand your thoughts. In general, having your dependencies defined by a profile being active is IMHO bad practice. The biggest reason for this, however possible not so important for you if you have a "subsystem", is that if some other artifact has a dependency to your artifact, they will not the get the correct transitive dependencies (or different ones dependending on whatever). This is not portability or reproducibility. I'm wondering why you just don't simply keep the version of the depmgmt pom (I guess you use import scope for this one?) as a property and update this property as you need. If you want to try a different version it is possible to override a property value from CLI. However, NEVER override for a release! The pom should then always contain the correct config. /Anders On Tue, Feb 16, 2010 at 07:33, Moser, Christian wrote: > We've trouble creating a concept for maven using subsystems. > > > > In the attached pdf you can see a maven/subsystem concept. In short, we've > got a component based software which is based on quiet a lot of components > (each component is a maven project). Those components are bundled in > subsystems. Every subsystem features a parent pom which contains all > components of this subsystem as a snapshot version. > > The snapshot versions are managed by the pom depmgmt-*dev*-*x* in all > subsystems. > > The release versions are managed by the pom depmgmt-*rel*-*x* in all > subsystems. > > > > As you can see project Z retrieves dependecy versions from depmgmt-*dev*-x > & depmgmt-*rel*-x from the subsystems *X* & *Y*. Our plan is that we only > want the subsystem a developer currently is working with snapshot versions, > all other needed subsystems by the project, in this case project Z, are only > available with their released components. > > > > e.g for working with subystem *X*, you need to set in user settings.xml: > > subsystem-*x* > > > > In this case profile subsystem-x gets activated in Z(parent) and resolves > the snapshot dependencies versions from depmgmt-*dev*-*x* & the released > dependencies versions from depmgmt-*rel*-*y *by dependency management. > > > > This is simular to the "reproduce example project" I've uploaded in > http://jira.codehaus.org/browse/MNG-4538. Not exactely the same, though. > > > > I was told activating dependencies by settings.xml isn't a good idea and > like the issue above demonstrates, it doesn't work properly, either. So I > could go ahead and activate the profile "subsystem-x" by a CLI property. > This would also work, but isn't really comfortable to working with in IDE's > because you had to set this for every component by hand or the IDE won't > find any dependency version. Setting these properties in the settings.xml > for profile activation won't work, it's also not by design. > > > > So how to easily activate profile "subsystem-*x*" for maven & maven > embedder in IDE's? Do you have any best practice tip for solving our > problem? > > > > I would really appreciate your help & please ask if my description of the > diagram is too unclear > > Chris > > > > > - > 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: Profile activation with maven & subsystems
First, the pdf is missing. Without that I'm not sure I fully understand your thoughts. In general, having your dependencies defined by a profile being active is IMHO bad practice. The biggest reason for this, however possible not so important for you if you have a "subsystem", is that if some other artifact has a dependency to your artifact, they will not the get the correct transitive dependencies (or different ones dependending on whatever). This is not portability or reproducibility. I'm wondering why you just don't simply keep the version of the depmgmt pom (I guess you use import scope for this one?) as a property and update this property as you need. If you want to try a different version it is possible to override a property value from CLI. However, NEVER override for a release! The pom should then always contain the correct config. /Anders On Tue, Feb 16, 2010 at 07:33, Moser, Christian wrote: > We’ve trouble creating a concept for maven using subsystems. > > > > In the attached pdf you can see a maven/subsystem concept. In short, we’ve > got a component based software which is based on quiet a lot of components > (each component is a maven project). Those components are bundled in > subsystems. Every subsystem features a parent pom which contains all > components of this subsystem as a snapshot version. > > The snapshot versions are managed by the pom depmgmt-*dev*-*x* in all > subsystems. > > The release versions are managed by the pom depmgmt-*rel*-*x* in all > subsystems. > > > > As you can see project Z retrieves dependecy versions from depmgmt-*dev*-x > & depmgmt-*rel*-x from the subsystems *X* & *Y*. Our plan is that we only > want the subsystem a developer currently is working with snapshot versions, > all other needed subsystems by the project, in this case project Z, are only > available with their released components. > > > > e.g for working with subystem *X*, you need to set in user settings.xml: > > subsystem-*x* > > > > In this case profile subsystem-x gets activated in Z(parent) and resolves > the snapshot dependencies versions from depmgmt-*dev*-*x* & the released > dependencies versions from depmgmt-*rel*-*y *by dependency management. > > > > This is simular to the „reproduce example project“ I’ve uploaded in > http://jira.codehaus.org/browse/MNG-4538. Not exactely the same, though. > > > > I was told activating dependencies by settings.xml isn’t a good idea and > like the issue above demonstrates, it doesn’t work properly, either. So I > could go ahead and activate the profile „subsystem-x“ by a CLI property. > This would also work, but isn’t really comfortable to working with in IDE’s > because you had to set this for every component by hand or the IDE won’t > find any dependency version. Setting these properties in the settings.xml > for profile activation won’t work, it’s also not by design. > > > > So how to easily activate profile „subsystem-*x*“ for maven & maven > embedder in IDE’s? Do you have any best practice tip for solving our > problem? > > > > I would really appreciate your help & please ask if my description of the > diagram is too unclear > > Chris > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
Profile activation with maven & subsystems
We've trouble creating a concept for maven using subsystems. In the attached pdf you can see a maven/subsystem concept. In short, we've got a component based software which is based on quiet a lot of components (each component is a maven project). Those components are bundled in subsystems. Every subsystem features a parent pom which contains all components of this subsystem as a snapshot version. The snapshot versions are managed by the pom depmgmt-dev-x in all subsystems. The release versions are managed by the pom depmgmt-rel-x in all subsystems. As you can see project Z retrieves dependecy versions from depmgmt-dev-x & depmgmt-rel-x from the subsystems X & Y. Our plan is that we only want the subsystem a developer currently is working with snapshot versions, all other needed subsystems by the project, in this case project Z, are only available with their released components. e.g for working with subystem X, you need to set in user settings.xml: subsystem-x In this case profile subsystem-x gets activated in Z(parent) and resolves the snapshot dependencies versions from depmgmt-dev-x & the released dependencies versions from depmgmt-rel-y by dependency management. This is simular to the "reproduce example project" I've uploaded in http://jira.codehaus.org/browse/MNG-4538. Not exactely the same, though. I was told activating dependencies by settings.xml isn't a good idea and like the issue above demonstrates, it doesn't work properly, either. So I could go ahead and activate the profile "subsystem-x" by a CLI property. This would also work, but isn't really comfortable to working with in IDE's because you had to set this for every component by hand or the IDE won't find any dependency version. Setting these properties in the settings.xml for profile activation won't work, it's also not by design. So how to easily activate profile "subsystem-x" for maven & maven embedder in IDE's? Do you have any best practice tip for solving our problem? I would really appreciate your help & please ask if my description of the diagram is too unclear Chris - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Profile activation
>From a recently updated
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
"As of Maven 2.0.9, the tags and could be
interpolated. Supported variables are system properties like
${user.home} and enviroment variables like ${env.HOME}. Please note that
properties defined in the POM itself are not available for interpolation
here."
Is this what you are running into?
Lukas Fryc wrote:
> Hi guys,
>
> I'm solving issue with issue with Maven 2.1.X,
>
> I want to activate profile when two conditions are satisfied...
>
> - file is missing
> - property containerId isn't set
>
> I used this:
>
>
> false
>
> ${demo.location}
>
>
> containerId
> jboss5x
>
>
>
> But profile is activated when I'm trying to do
>
> $ mvn verify -Dtest="..."
>
> (without any parameters and that file is missing in ${project.directory})
>
>
> Article 11.4 from
> http://www.sonatype.com/books/maven-book/reference/profiles-sect-activation.html
> says, that this is possible.
--
Dennis Lundberg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Profile activation
Sorry, thanks for reply, but this resolution wouldn't help me. :-)
Lukas Fryc wrote:
>
> Thanks Martin,
>
> I tried all of the possible combinations in property name/value, like:
>
> containerId
> !containerId
> containerId
> containerId!
>
>
> mgainty wrote:
>>
>>
>> i would use the not on the property's name e.g.
>>
>>
>> !containerId
>> Martin Gainty
>> __
>> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>>
>> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
>> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
>> unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese
>> Nachricht dient lediglich dem Austausch von Informationen und entfaltet
>> keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit
>> von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
>> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas
>> le destinataire prévu, nous te demandons avec bonté que pour satisfaire
>> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la
>> copie de ceci est interdite. Ce message sert à l'information seulement et
>> n'aura pas n'importe quel effet légalement obligatoire. Étant donné que
>> les email peuvent facilement être sujets à la manipulation, nous ne
>> pouvons accepter aucune responsabilité pour le contenu fourni.
>>
>>
>>
>>
>>> Date: Thu, 17 Dec 2009 02:31:41 -0800
>>> From: lf...@redhat.com
>>> To: users@maven.apache.org
>>> Subject: Profile activation
>>>
>>>
>>> Hi guys,
>>>
>>> I'm solving issue with issue with Maven 2.1.X,
>>>
>>> I want to activate profile when two conditions are satisfied...
>>>
>>> - file is missing
>>> - property containerId isn't set
>>>
>>> I used this:
>>>
>>>
>>> false
>>>
>>> ${demo.location}
>>>
>>>
>>> containerId
>>> jboss5x
>>>
>>>
>>>
>>> But profile is activated when I'm trying to do
>>>
>>> $ mvn verify -Dtest="..."
>>>
>>> (without any parameters and that file is missing in
>>> ${project.directory})
>>>
>>>
>>> Article 11.4 from
>>> http://www.sonatype.com/books/maven-book/reference/profiles-sect-activation.html
>>> says, that this is possible.
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Profile-activation-tp26826008p26826008.html
>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>
>> _
>> Hotmail: Powerful Free email with security by Microsoft.
>> http://clk.atdmt.com/GBL/go/171222986/direct/01/
>>
>
>
--
View this message in context:
http://old.nabble.com/Profile-activation-tp26826008p26827348.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Profile activation
Thanks Martin,
I tried all of the possible combinations in property name/value, like:
containerId
!containerId
containerId
containerId!
mgainty wrote:
>
>
> i would use the not on the property's name e.g.
>
>
> !containerId
> Martin Gainty
> __
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
> destinataire prévu, nous te demandons avec bonté que pour satisfaire
> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la
> copie de ceci est interdite. Ce message sert à l'information seulement et
> n'aura pas n'importe quel effet légalement obligatoire. Étant donné que
> les email peuvent facilement être sujets à la manipulation, nous ne
> pouvons accepter aucune responsabilité pour le contenu fourni.
>
>
>
>
>> Date: Thu, 17 Dec 2009 02:31:41 -0800
>> From: lf...@redhat.com
>> To: users@maven.apache.org
>> Subject: Profile activation
>>
>>
>> Hi guys,
>>
>> I'm solving issue with issue with Maven 2.1.X,
>>
>> I want to activate profile when two conditions are satisfied...
>>
>> - file is missing
>> - property containerId isn't set
>>
>> I used this:
>>
>>
>> false
>>
>> ${demo.location}
>>
>>
>> containerId
>> jboss5x
>>
>>
>>
>> But profile is activated when I'm trying to do
>>
>> $ mvn verify -Dtest="..."
>>
>> (without any parameters and that file is missing in ${project.directory})
>>
>>
>> Article 11.4 from
>> http://www.sonatype.com/books/maven-book/reference/profiles-sect-activation.html
>> says, that this is possible.
>> --
>> View this message in context:
>> http://old.nabble.com/Profile-activation-tp26826008p26826008.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
> _
> Hotmail: Powerful Free email with security by Microsoft.
> http://clk.atdmt.com/GBL/go/171222986/direct/01/
>
--
View this message in context:
http://old.nabble.com/Profile-activation-tp26826008p26827323.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Profile activation
i would use the not on the property's name e.g.
!containerId
Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Date: Thu, 17 Dec 2009 02:31:41 -0800
> From: lf...@redhat.com
> To: users@maven.apache.org
> Subject: Profile activation
>
>
> Hi guys,
>
> I'm solving issue with issue with Maven 2.1.X,
>
> I want to activate profile when two conditions are satisfied...
>
> - file is missing
> - property containerId isn't set
>
> I used this:
>
>
> false
>
> ${demo.location}
>
>
> containerId
> jboss5x
>
>
>
> But profile is activated when I'm trying to do
>
> $ mvn verify -Dtest="..."
>
> (without any parameters and that file is missing in ${project.directory})
>
>
> Article 11.4 from
> http://www.sonatype.com/books/maven-book/reference/profiles-sect-activation.html
> says, that this is possible.
> --
> View this message in context:
> http://old.nabble.com/Profile-activation-tp26826008p26826008.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
_
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/171222986/direct/01/
Profile activation
Hi guys,
I'm solving issue with issue with Maven 2.1.X,
I want to activate profile when two conditions are satisfied...
- file is missing
- property containerId isn't set
I used this:
false
${demo.location}
containerId
jboss5x
But profile is activated when I'm trying to do
$ mvn verify -Dtest="..."
(without any parameters and that file is missing in ${project.directory})
Article 11.4 from
http://www.sonatype.com/books/maven-book/reference/profiles-sect-activation.html
says, that this is possible.
--
View this message in context:
http://old.nabble.com/Profile-activation-tp26826008p26826008.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Profile activation based on JDK, how it works?
Hi Jan, Jan wrote: > Hi All, > > I was just wondering about the following situation > > I'm using maven 2.2.1 which requires jdk 1.5 to run, but my modules will > compile only with 1.4, so i used the 1.4 executable in my compiler plugin. > > In this case if i create profile with the activation rule for > 1.4 when this profile will get activated? > > Any one had this situation the profile is activated on the JDK version that is used running Maven. The profile is evaluated at very early stage, since it defines the effective (=resulting) POM that is used for your build. However, you should really know, what you do within this profile. It is e.g. a bad idea to manage a different set of dependencies in profiles based on the JDK version for artifacts although this seems a good example at first glance. Especially in your cases where you try to build using a different compiler version (or even build for a different JDK target), such dependencies might give you a surprise. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Profile activation based on JDK, how it works?
Hi All, I was just wondering about the following situation I'm using maven 2.2.1 which requires jdk 1.5 to run, but my modules will compile only with 1.4, so i used the 1.4 executable in my compiler plugin. In this case if i create profile with the activation rule for 1.4 when this profile will get activated? Any one had this situation
Re: profile activation based on env value?
thanks for any help or suggestions on how I might make this work. Obviously my goal is to simple keep database password out of svn and the project. Why do you set it in a profile at all? Your settings.xml is private to you. Thanks. That is just the answer I was looking for actually. I will just keep a settings.xml file with these values. This has a bonus of keeping them all in one place. -jr - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: profile activation based on env value?
James Russo wrote at Dienstag, 8. September 2009 04:33: > Hello, > > In my ~/.m2/settings.xml I have: > > > > > setup_database_password > > true > > > dev > secret > > > > > > > So, this should set environment.type to "dev". Not necessarily. "activeByDefault" means active, if no other profile has been specified. > Then in one of my sub-projects pom (beneath parent, not sure that > matters though) I have this: > > > > setup_database_properties > > > environment.type > dev > > > > > > com.mysql.jdbc.Driver > > jdbc:postgresql://localhost/dbname > dbuser > > > > > However, when I run help:active-profiles I am only seeing the one > profile (from ~/.m2/settings.xml) activated? I would expect that the > profile in > my pom.xml file would be activated since the environment value is set. No, profiles cannot be activated by properties set in other profiles. It is a limitation of the profile mechanism. > If I specify -Denvironment.type=dev on the command line, it works as > expected? No, because then the profile in settings.xml is no longer "by default" as explained above. > If I change activation to !environment it works as well. Seems > like it is just not > picking up properties added by ~/.m2/settings.xml. Simply activate both profiles when "environment.type" is set to "dev". > thanks for any help or suggestions on how I might make this work. > Obviously my goal is to simple keep database password out of svn and the > project. Why do you set it in a profile at all? Your settings.xml is private to you. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: profile activation based on env value?
Thanks Dan.. I've looked at that, and it seems that I have it setup correctly. However, the profile in my pom (which should be activated by an property defined in my ~/.m2/settings.xml file) is never activated. Using help:effective-pom it shows that the property is there, so I know it is getting set. It's almost like the setting of the property in the ~/.m2/settings profile takes place after evaluating the local pom.xml profile. -jr Dan Tran wrote: you should be a to search for it search maven profile using environment variable found http://www.devx.com/Java/Article/32386/1763 good luck. -D On Mon, Sep 7, 2009 at 7:33 PM, James Russo wrote: Hello, In my ~/.m2/settings.xml I have: setup_database_password true dev secret So, this should set environment.type to "dev". Then in one of my sub-projects pom (beneath parent, not sure that matters though) I have this: setup_database_properties environment.type dev com.mysql.jdbc.Driver jdbc:postgresql://localhost/dbname dbuser However, when I run help:active-profiles I am only seeing the one profile (from ~/.m2/settings.xml) activated? I would expect that the profile in my pom.xml file would be activated since the environment value is set. If I specify -Denvironment.type=dev on the command line, it works as expected? If I change activation to !environment it works as well. Seems like it is just not picking up properties added by ~/.m2/settings.xml. thanks for any help or suggestions on how I might make this work. Obviously my goal is to simple keep database password out of svn and the project. -jr - 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: profile activation based on env value?
you should be a to search for it search maven profile using environment variable found http://www.devx.com/Java/Article/32386/1763 good luck. -D On Mon, Sep 7, 2009 at 7:33 PM, James Russo wrote: > Hello, > > In my ~/.m2/settings.xml I have: > > > > > setup_database_password > > true > > > dev > secret > > > > > > > So, this should set environment.type to "dev". > > Then in one of my sub-projects pom (beneath parent, not sure that matters > though) I have this: > > > > setup_database_properties > > > environment.type > dev > > > > > > com.mysql.jdbc.Driver > > jdbc:postgresql://localhost/dbname > dbuser > > > > > However, when I run help:active-profiles I am only seeing the one profile > (from ~/.m2/settings.xml) activated? I would expect that the profile in > my pom.xml file would be activated since the environment value is set. > > If I specify -Denvironment.type=dev on the command line, it works as > expected? If I change activation to !environment it works as well. Seems > like it is just not > picking up properties added by ~/.m2/settings.xml. > > thanks for any help or suggestions on how I might make this work. Obviously > my goal is to simple keep database password out of svn and the project. > > -jr > > - > 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
profile activation based on env value?
Hello, In my ~/.m2/settings.xml I have: setup_database_password true dev secret So, this should set environment.type to "dev". Then in one of my sub-projects pom (beneath parent, not sure that matters though) I have this: setup_database_properties environment.type dev com.mysql.jdbc.Driver jdbc:postgresql://localhost/dbname dbuser However, when I run help:active-profiles I am only seeing the one profile (from ~/.m2/settings.xml) activated? I would expect that the profile in my pom.xml file would be activated since the environment value is set. If I specify -Denvironment.type=dev on the command line, it works as expected? If I change activation to !environment it works as well. Seems like it is just not picking up properties added by ~/.m2/settings.xml. thanks for any help or suggestions on how I might make this work. Obviously my goal is to simple keep database password out of svn and the project. -jr - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Profile Activation Help?
Yes. I also tried adding the tag with the plugin defined in the section (not as a profile). I got the same result. The children still executed the plugin. I defined it to execute on the deploy phase. Stephen Connolly wrote: > Are you saying that if you do sth like this: > > > ... > > ... > > changes-report > > ... > > > > > ... > ... > ... > false > > > produce-changes-report > sitedeploy > > do-the-changes-report-mojo > > > ... > > > > > > > > ... > > ... > > > That the plugin gets executed in the child modules or have you been > trying to run the mojo from the CLI rather than integrating it into the > lifecycle > > -Stephen > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Profile Activation Help?
That is correct. The build plan is evaluated prior to any plugins executing... therefore profile activation must be decided up front AFAIK Maven 3 may be able to fix this somewhat -Stephen 2009/8/11 David C. Hicks > Then my experience, I would say, confirms that for both of us. My file > *is* in the top-level, and I found that the profile was activated for > all modules. I had arrived at the same conclusion that they are > evaluated once, at the start of execution. > > > Benson Margulies wrote: > > You may be walking into a trap in a multi-module project. It is my > > strong impression that activation decisions are not made > > module-by-module in the reactor, but only once. When I tried what you > > tried I found that, since the top-level project with the modules in it > > didn't have the file, the profile was never active when running maven > > from top-level. > > > > On Mon, Aug 10, 2009 at 3:28 PM, David C. Hicks > wrote: > > > >> I must have been blind when reading through my MDG last night. I found > >> what I believe will be my solution. > >> > >> > >> > >> src/changes/changes.xml > >> > >> > >> > >> Since this is the only module that will have a changes.xml file, this > >> should do the trick for me. I thought I'd share what I found for > posterity. > >> Dave > >> > >> David C. Hicks wrote: > >> > >>> I'm trying to get a profile to activate for my parent project but not > >>> for the children. Unfortunately, the children inherit from the parent > >>> to get dependency information. So, they also inherit everything else. > >>> My solution (or so I thought) was to use the project.artifactId > property > >>> in my activation section... > >>> > >>> > >>> false > >>> > >>> project.artifactId > >>> salient > >>> > >>> > >>> > >>> Since only the parent project has this artifact Id, I assumed that it > >>> would activate only for the parent. However, there was no activation > of > >>> this profile at all. > >>> > >>> My overall goal is to try to get the maven-changes-plugin to do an > >>> announcement email using changes.xml in the parent project. I do not > >>> want announcements for all of the children, though. > >>> > >>> Any help? > >>> Thanks, > >>> Dave > >>> > >>> > >>> > >> - > >> 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: Profile Activation Help?
Are you saying that if you do sth like this: ... ... changes-report ... ... ... ... false produce-changes-report sitedeploy do-the-changes-report-mojo ... ... ... That the plugin gets executed in the child modules or have you been trying to run the mojo from the CLI rather than integrating it into the lifecycle -Stephen 2009/8/11 David C. Hicks > Hi Stephen, > > I tried that, but it didn't seem to work. The plugin still tried to > execute for the sub-modules. I ended up punting. I run my > changes:announcement-mail goal in a completely separate Maven run after > my build is completed, but I give it the "-N" switch to keep it from > running child modules. > > Dave > > PS - maybe there is a bug that I should write up a JIRA for? I'm > uncomfortable doing that since I don't know for sure that I had things > configured correctly. > > Stephen Connolly wrote: > > Just define all the _*plugins*_ in your profile as > > false > > > > 2009/8/10 David C. Hicks > > > > > >> I take it back. That doesn't help me, either. > >> I guess once the profile has been activated at the parent POM level, it > >> stays that way for all the children. > >> > >> David C. Hicks wrote: > >> > >>> I must have been blind when reading through my MDG last night. I found > >>> what I believe will be my solution. > >>> > >>> > >>> > >>> src/changes/changes.xml > >>> > >>> > >>> > >>> Since this is the only module that will have a changes.xml file, this > >>> should do the trick for me. I thought I'd share what I found for > >>> > >> posterity. > >> > >>> Dave > >>> > >>> David C. Hicks wrote: > >>> > >>> > I'm trying to get a profile to activate for my parent project but not > for the children. Unfortunately, the children inherit from the parent > to get dependency information. So, they also inherit everything else. > My solution (or so I thought) was to use the project.artifactId > property > in my activation section... > > > false > > project.artifactId > salient > > > > Since only the parent project has this artifact Id, I assumed that it > would activate only for the parent. However, there was no activation > of > this profile at all. > > My overall goal is to try to get the maven-changes-plugin to do an > announcement email using changes.xml in the parent project. I do not > want announcements for all of the children, though. > > Any help? > Thanks, > Dave > > > > > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > >> > > > > >
Re: Profile Activation Help?
Then my experience, I would say, confirms that for both of us. My file *is* in the top-level, and I found that the profile was activated for all modules. I had arrived at the same conclusion that they are evaluated once, at the start of execution. Benson Margulies wrote: > You may be walking into a trap in a multi-module project. It is my > strong impression that activation decisions are not made > module-by-module in the reactor, but only once. When I tried what you > tried I found that, since the top-level project with the modules in it > didn't have the file, the profile was never active when running maven > from top-level. > > On Mon, Aug 10, 2009 at 3:28 PM, David C. Hicks wrote: > >> I must have been blind when reading through my MDG last night. I found >> what I believe will be my solution. >> >> >> >> src/changes/changes.xml >> >> >> >> Since this is the only module that will have a changes.xml file, this >> should do the trick for me. I thought I'd share what I found for posterity. >> Dave >> >> David C. Hicks wrote: >> >>> I'm trying to get a profile to activate for my parent project but not >>> for the children. Unfortunately, the children inherit from the parent >>> to get dependency information. So, they also inherit everything else. >>> My solution (or so I thought) was to use the project.artifactId property >>> in my activation section... >>> >>> >>> false >>> >>> project.artifactId >>> salient >>> >>> >>> >>> Since only the parent project has this artifact Id, I assumed that it >>> would activate only for the parent. However, there was no activation of >>> this profile at all. >>> >>> My overall goal is to try to get the maven-changes-plugin to do an >>> announcement email using changes.xml in the parent project. I do not >>> want announcements for all of the children, though. >>> >>> Any help? >>> Thanks, >>> Dave >>> >>> >>> >> - >> 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: Profile Activation Help?
You may be walking into a trap in a multi-module project. It is my strong impression that activation decisions are not made module-by-module in the reactor, but only once. When I tried what you tried I found that, since the top-level project with the modules in it didn't have the file, the profile was never active when running maven from top-level. On Mon, Aug 10, 2009 at 3:28 PM, David C. Hicks wrote: > I must have been blind when reading through my MDG last night. I found > what I believe will be my solution. > > > > src/changes/changes.xml > > > > Since this is the only module that will have a changes.xml file, this > should do the trick for me. I thought I'd share what I found for posterity. > Dave > > David C. Hicks wrote: >> I'm trying to get a profile to activate for my parent project but not >> for the children. Unfortunately, the children inherit from the parent >> to get dependency information. So, they also inherit everything else. >> My solution (or so I thought) was to use the project.artifactId property >> in my activation section... >> >> >> false >> >> project.artifactId >> salient >> >> >> >> Since only the parent project has this artifact Id, I assumed that it >> would activate only for the parent. However, there was no activation of >> this profile at all. >> >> My overall goal is to try to get the maven-changes-plugin to do an >> announcement email using changes.xml in the parent project. I do not >> want announcements for all of the children, though. >> >> Any help? >> Thanks, >> Dave >> >> > > - > 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: Profile Activation Help?
Hi Stephen, I tried that, but it didn't seem to work. The plugin still tried to execute for the sub-modules. I ended up punting. I run my changes:announcement-mail goal in a completely separate Maven run after my build is completed, but I give it the "-N" switch to keep it from running child modules. Dave PS - maybe there is a bug that I should write up a JIRA for? I'm uncomfortable doing that since I don't know for sure that I had things configured correctly. Stephen Connolly wrote: > Just define all the _*plugins*_ in your profile as > false > > 2009/8/10 David C. Hicks > > >> I take it back. That doesn't help me, either. >> I guess once the profile has been activated at the parent POM level, it >> stays that way for all the children. >> >> David C. Hicks wrote: >> >>> I must have been blind when reading through my MDG last night. I found >>> what I believe will be my solution. >>> >>> >>> >>> src/changes/changes.xml >>> >>> >>> >>> Since this is the only module that will have a changes.xml file, this >>> should do the trick for me. I thought I'd share what I found for >>> >> posterity. >> >>> Dave >>> >>> David C. Hicks wrote: >>> >>> I'm trying to get a profile to activate for my parent project but not for the children. Unfortunately, the children inherit from the parent to get dependency information. So, they also inherit everything else. My solution (or so I thought) was to use the project.artifactId property in my activation section... false project.artifactId salient Since only the parent project has this artifact Id, I assumed that it would activate only for the parent. However, there was no activation of this profile at all. My overall goal is to try to get the maven-changes-plugin to do an announcement email using changes.xml in the parent project. I do not want announcements for all of the children, though. Any help? Thanks, Dave >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> >> > >
Re: Profile Activation Help?
Just define all the _*plugins*_ in your profile as false 2009/8/10 David C. Hicks > I take it back. That doesn't help me, either. > I guess once the profile has been activated at the parent POM level, it > stays that way for all the children. > > David C. Hicks wrote: > > I must have been blind when reading through my MDG last night. I found > > what I believe will be my solution. > > > > > > > > src/changes/changes.xml > > > > > > > > Since this is the only module that will have a changes.xml file, this > > should do the trick for me. I thought I'd share what I found for > posterity. > > Dave > > > > David C. Hicks wrote: > > > >> I'm trying to get a profile to activate for my parent project but not > >> for the children. Unfortunately, the children inherit from the parent > >> to get dependency information. So, they also inherit everything else. > >> My solution (or so I thought) was to use the project.artifactId property > >> in my activation section... > >> > >> > >> false > >> > >> project.artifactId > >> salient > >> > >> > >> > >> Since only the parent project has this artifact Id, I assumed that it > >> would activate only for the parent. However, there was no activation of > >> this profile at all. > >> > >> My overall goal is to try to get the maven-changes-plugin to do an > >> announcement email using changes.xml in the parent project. I do not > >> want announcements for all of the children, though. > >> > >> Any help? > >> Thanks, > >> Dave > >> > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Profile Activation Help?
I take it back. That doesn't help me, either. I guess once the profile has been activated at the parent POM level, it stays that way for all the children. David C. Hicks wrote: > I must have been blind when reading through my MDG last night. I found > what I believe will be my solution. > > > > src/changes/changes.xml > > > > Since this is the only module that will have a changes.xml file, this > should do the trick for me. I thought I'd share what I found for posterity. > Dave > > David C. Hicks wrote: > >> I'm trying to get a profile to activate for my parent project but not >> for the children. Unfortunately, the children inherit from the parent >> to get dependency information. So, they also inherit everything else. >> My solution (or so I thought) was to use the project.artifactId property >> in my activation section... >> >> >> false >> >> project.artifactId >> salient >> >> >> >> Since only the parent project has this artifact Id, I assumed that it >> would activate only for the parent. However, there was no activation of >> this profile at all. >> >> My overall goal is to try to get the maven-changes-plugin to do an >> announcement email using changes.xml in the parent project. I do not >> want announcements for all of the children, though. >> >> Any help? >> Thanks, >> Dave >> >> >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Profile Activation Help?
I must have been blind when reading through my MDG last night. I found what I believe will be my solution. src/changes/changes.xml Since this is the only module that will have a changes.xml file, this should do the trick for me. I thought I'd share what I found for posterity. Dave David C. Hicks wrote: > I'm trying to get a profile to activate for my parent project but not > for the children. Unfortunately, the children inherit from the parent > to get dependency information. So, they also inherit everything else. > My solution (or so I thought) was to use the project.artifactId property > in my activation section... > > > false > > project.artifactId > salient > > > > Since only the parent project has this artifact Id, I assumed that it > would activate only for the parent. However, there was no activation of > this profile at all. > > My overall goal is to try to get the maven-changes-plugin to do an > announcement email using changes.xml in the parent project. I do not > want announcements for all of the children, though. > > Any help? > Thanks, > Dave > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Profile Activation Help?
That would substitute the actual name of the artifact in the tag,
though, wouldn't it?
Jonathan Woods wrote:
> ${project.artifactId} might help.
>
> Jon
>
>
>> -Original Message-
>> From: David C. Hicks [mailto:dhi...@i-hicks.org]
>> Sent: 10 August 2009 18:12
>> To: Maven Users
>> Subject: Profile Activation Help?
>>
>> I'm trying to get a profile to activate for my parent project
>> but not for the children. Unfortunately, the children
>> inherit from the parent to get dependency information. So,
>> they also inherit everything else.
>> My solution (or so I thought) was to use the
>> project.artifactId property in my activation section...
>>
>>
>> false
>>
>> project.artifactId
>> salient
>>
>>
>>
>> Since only the parent project has this artifact Id, I assumed
>> that it would activate only for the parent. However, there
>> was no activation of this profile at all.
>>
>> My overall goal is to try to get the maven-changes-plugin to
>> do an announcement email using changes.xml in the parent
>> project. I do not want announcements for all of the children, though.
>>
>> Any help?
>> Thanks,
>> Dave
>>
>>
>> -
>> 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: Profile Activation Help?
${project.artifactId} might help.
Jon
> -Original Message-
> From: David C. Hicks [mailto:dhi...@i-hicks.org]
> Sent: 10 August 2009 18:12
> To: Maven Users
> Subject: Profile Activation Help?
>
> I'm trying to get a profile to activate for my parent project
> but not for the children. Unfortunately, the children
> inherit from the parent to get dependency information. So,
> they also inherit everything else.
> My solution (or so I thought) was to use the
> project.artifactId property in my activation section...
>
>
> false
>
> project.artifactId
> salient
>
>
>
> Since only the parent project has this artifact Id, I assumed
> that it would activate only for the parent. However, there
> was no activation of this profile at all.
>
> My overall goal is to try to get the maven-changes-plugin to
> do an announcement email using changes.xml in the parent
> project. I do not want announcements for all of the children, though.
>
> Any help?
> Thanks,
> Dave
>
>
> -
> 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
Profile Activation Help?
I'm trying to get a profile to activate for my parent project but not for the children. Unfortunately, the children inherit from the parent to get dependency information. So, they also inherit everything else. My solution (or so I thought) was to use the project.artifactId property in my activation section... false project.artifactId salient Since only the parent project has this artifact Id, I assumed that it would activate only for the parent. However, there was no activation of this profile at all. My overall goal is to try to get the maven-changes-plugin to do an announcement email using changes.xml in the parent project. I do not want announcements for all of the children, though. Any help? Thanks, Dave - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Profile activation based on current plugin?
Sorry — hit send by accident. On 5 Aug 2009, at 14:43, Dominic Mitchell wrote: On 5 Aug 2009, at 14:10, Stephen Connolly wrote: if you think about this a bit more you will realise that what you are asking for does not make sense (unless you are trying to configure the plugin that you are executing. Ok… That does make sense. if you specify a plugin:mojo, then only that plugin:mojo will get executed. Adding other executions of other plugins to a profile and activating that profile will have ZERO effect on what happens, as only the plugin:mojo that you specified will be executed. That's not actually the case. For jetty:run, it executes all phases up to compile before executing jetty:run. Thinking about this, the jetty plugin must be somehow manually be invoking the compile phase. And if I use help:describe, I see: …The plugin forks a parallel lifecycle to ensure that the 'compile' phase has been completed before invoking Jetty. This means that you do not need to explicity execute a 'mvn compile' first… Before this mojo executes, it will call: Phase: 'test-compile' That explains it. try telling us a bit more about what your problem is and perhaps somebody can point you towards a solution but it sounds like you really want maven to be more like ant... maven is not ant, if you want ant use ant ;-) Sorry, I thought I'd been clearer in my original email. I'm trying to avoid calling cocoon:prepare, except in the case of jetty:run. Now I could just not bind cocoon:prepare to the compile phase, but then I have to remember to type two things on the command line. It's not a big deal overall (saving seconds on the non-jetty builds) but it would be nice if I could do it. -Dom
Re: Profile activation based on current plugin?
On 5 Aug 2009, at 14:10, Stephen Connolly wrote: if you think about this a bit more you will realise that what you are asking for does not make sense (unless you are trying to configure the plugin that you are executing. if you specify a plugin:mojo, then only that plugin:mojo will get executed. Adding other executions of other plugins to a profile and activating that profile will have ZERO effect on what happens, as only the plugin:mojo that you specified will be executed. That's not actually the case. For jetty:run, it executes all phases up to compile before executing jetty:run. try telling us a bit more about what your problem is and perhaps somebody can point you towards a solution but it sounds like you really want maven to be more like ant... maven is not ant, if you want ant use ant ;-) Sorry, I thought I'd been clearer in my original email. -Dom -Stephen 2009/8/5 Dominic Mitchell Hi all, I'm wondering — is there a way to activate a profile based on the plugin specified on the command line? The reason for this is that I'm working with a cocoon project. Normally, the cocoon plugin gets bound to compile: org.apache.cocoon cocoon-maven-plugin 1.0.0-M2 prepare compile prepare etc/log4j.xml However, I only really care that this happens when I invoke mvn jetty:run on the command line. Otherwise, it's just wasted effort. I was thinking that I could make this into a profile, but I'm not sure how. Or if that's even possible. Thanks, -Dom - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
