Hi John,
> -----Original Message-----
> From: John Casey [mailto:[EMAIL PROTECTED]
> Sent: lundi 12 septembre 2005 04:26
> To: Maven Developers List
> Subject: Re: Questions of profiles and settings...
[snip]
> | * It seems that I need to put my project-specific profiles in a
> profiles.xml
> | file located in my project. So far so good. However, how can I trigger a
> | profile automatically? I could by having an activeProfile element in the
> | master settings.xml file but I don't want to do that as this activation
> is
> | only for this specific project so I want to contain everything related
> to
> | this project in the project's root dir.
> |
> | Here's a reminder of what I'd like to do (from the previous email):
> | - I have a property named ${cargo.containers} that has a default value
> set
> | up in a profile inlined in pom.xml
> | - I'd like that users of the build could specify an overridden value for
> | this cargo.containers property. The best place to do that is in a
> | profile.xml file in the project's root dir.
> | - I'd like their overridden value to be used when they type "m2 install"
> | without them having to type "m2 -Denv=myprofile install" which is too
> much
> | of a hassle IMO
> |
>
> If you want to, you can have a profile activated based on the presence
> or value of any system property. So, if you want the profile
> 'user-jdcasey' to be activated when I run the build, you might do
> something like this:
>
> <profile>
> ~ <id>user-jdcasey</id>
>
> ~ <activation>
> ~ <property>
> ~ <name>user.name</name>
> ~ <value>jdcasey</value>
> ~ </property>
> ~ </activation>
>
> ~ ...
> </profile>
Thanks for this trick. However it sounds too much tricky IMO to be the final
solution. I might be logged under a different user name, etc. I think we
need something explicit when we want a profile to be always actiated.
Why don't we add an <activation> element such as <always/> which would
indicated the profile is always active?
[snip]
> |
> | Note: The reason I want this profile to be always on is because I want
> to
> | always have a default property for ${cargo.containers}.
>
> You might want to use a new feature to m2: POM-level properties. This is
> essentially the same capability you have with profiles, except it's
> built into the POM itself (sans profile). So, if you want to provide
> default values that can be overridden, you would probably want to use
> these.
>
> One side effect of POM-level properties is that you can pick and choose
> which configuration points you want to expose for plugin definitions
> that are inherited. For example, you might define a plugin in your
> parent POM, with configurations that have a common expression for part
> of their paths:
>
> <configuration>
> ~ <param1>${rootPath}/to/somewhere</param1>
> ~ <param2>${rootPath}/to/somewhere-else</param2>
> </configuration>
>
> Now, the user who extends this parent POM doesn't have to redeclare the
> plugin and reconfigure it, replicating the subdirectory structure...they
> can simply redefine ${rootPath}. This redefinition can be done via
> profile or via a child POM that has its own POM-level properties.
I'm still unsure how POM-level properties are defined. For example in your
example above where is rootPath defined?
How is that different from my example:
pom.xml:
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemProperties combine.children="append">
<property>
<name>cargo.containers</name>
<value>${cargo.containers}</value>
</property>
</systemProperties>
</configuration>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>default</id>
<properties>
<cargo.containers>resin3x, orion2x,...</cargo.containers>
</properties>
</profile>
</profiles>
</project>
Following your definition I could call cargo.containers a POM-level property
defined by a profile it seems. Is that correct?
You mentioned the ability to define this property in a child POM. What
syntax would you use?
However in my case, the user of this POM is an end-user so I guess he has to
use a profile for that.
> |
> | * How do I tell m2 that the profile I have defined in the pom.xml file
> must
> | always be activated (I thought naming it "default" would work but
> apparently
> | not)?
>
> With POM-level properties you shouldn't really have to, but if you did,
> you might want something silly like this:
>
> <profile>
> ~ <id>always-on</id>
>
> ~ <activation>
> ~ <property>
> ~ <name>java.version</name>
> ~ </property>
> ~ </activation>
>
> ~ ...
> </profile>
>
> which will result in the profile being activated whenever the system
> property 'java.version' is defined, which should be always. It's a bit
> silly, but if you want system-dependent paths in your builds, you might
> do something like this in your settings.xml. Hmm, looks like we /could/
> use a default profile for the settings.xml... ;)
Yes, we really need something less "magical"... Naming it "default" is also
a bit magical. Why not do as I suggested above and add a nested <always/>
element of <activation>?
BTW, there's already a JIRA for this:
http://jira.codehaus.org/browse/MNG-835
> | * The http://maven.apache.org/maven2/profiles-overview.html doc is quite
> | nice. It explains well what is dangerous with profiles and with an
> appserver
> | path property but it doesn't give a solution (or I haven't found
> it)... :-)
> | I think what I want to do by using a default value specified in an
> inlined
> | profile would do the trick but I can't find a solution to activate this
> | default profile...
>
> See if the above advice helps, and if not, let us know...we're going to
> be pretty busy fixing these types of things for the next few weeks.
Cool. I have the feeling that settings/profiles/inlined profiles/POM-level
properties are all a bit complex for the end user when defining properties.
There are several ways of doing the same thing which is always a bit
worrying.
In any case, it sounds way more complex than the previous build.properties
file (it's doing more of course but I'm only talking about defining a
property). We should make it dead simple to define a simple
environment-dependent property.
Thanks a lot
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
