You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Vincent Massol <vm...@pivolis.com> on 2005/09/11 12:54:36 UTC

Questions of profiles and settings...

Hi,

I'll be presenting m2 at JavaZone 2005 (this coming Wednesday) and I have
some slides on settings and profiles. I'd like to ensure I do not present
false information... Could you help me in validating the following?

* Here's a slide I'd like to present that shows how to set up an
environment-dependent property: 
http://people.apache.org/~vmassol/m2-env-dependent-property-cargo.jpg

- Is that correct?

- Should the file put in samples/java be named profiles.xml instead of
settings.xml? If so, how do I tell m2 to activate a profile by default (I'm
currently using the <activeProfile> tag which belongs to settings.xml)?

- ATM I don't think that settings.xml file located in project directories
are read. Is that going to be supported in the future? If not where do I put
project-specific environment-dependent stuff?

BTW I have found that default profile in the pom is not working and I have
opened a JIRA issue for this: http://jira.codehaus.org/browse/MNG-835

* Why do we have both profiles.xml and settings.xml files? When to use one
over the another?

* Does someone knows what's already implemented from
http://docs.codehaus.org/display/MAVEN/Build+Profiles and what's left to do?

Thanks for your help!
-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: Questions of profiles and settings...

Posted by Vincent Massol <vm...@pivolis.com>.
Hi John,

> -----Original Message-----
> From: John Casey [mailto:jdcasey@commonjava.org]
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Questions of profiles and settings...

Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

See my comments inline.

Cheers,

john

Vincent Massol wrote:
|
|>-----Original Message-----
|>From: Jason van Zyl [mailto:jason@maven.org]
|>Sent: lundi 12 septembre 2005 06:56
|>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>

| * The http://maven.apache.org/maven2/profiles-overview.html document
doesn't
| mention the trick of naming a default profile "default" (as is
described on
| http://docs.codehaus.org/display/MAVEN/Build+Profiles). Does it mean it's
| not implemented?

Not entirely sure. It's been awhile since I implemented that stuff, I
may have missed that detail. See below for why that may just fall by the
wayside...

|
| 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.

|
| * 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... ;)

|
| * 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.

- -j

|
| Thanks
| -Vincent
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
| For additional commands, e-mail: dev-help@maven.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDJOdHK3h2CZwO/4URApMYAJwJ7a9cGsnMO7+pG94UgyCXLAvR3gCfZgMC
+Q/glzaphw9edJcIs2CdIO4=
=7beA
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: Questions of profiles and settings...

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: Jason van Zyl [mailto:jason@maven.org]
> Sent: lundi 12 septembre 2005 06:56
> To: Maven Developers List
> Subject: Re: Questions of profiles and settings...

[snip]

> Here's a little piece of doco that John wrote that might be of help
> right now:
> 
> http://maven.apache.org/maven2/profiles-overview.html

Thanks Jason, I wasn't aware of this doc. I've read it and I have some more
questions (probably for John):

* 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

* The http://maven.apache.org/maven2/profiles-overview.html document doesn't
mention the trick of naming a default profile "default" (as is described on
http://docs.codehaus.org/display/MAVEN/Build+Profiles). Does it mean it's
not implemented?

Note: The reason I want this profile to be always on is because I want to
always have a default property for ${cargo.containers}.

* 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)?

* 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...

Thanks
-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Questions of profiles and settings...

Posted by Jason van Zyl <ja...@maven.org>.
On Sun, 2005-09-11 at 12:54 +0200, Vincent Massol wrote:
> Hi,
> 
> I'll be presenting m2 at JavaZone 2005 (this coming Wednesday) and I have
> some slides on settings and profiles. I'd like to ensure I do not present
> false information... Could you help me in validating the following?
> 
> * Here's a slide I'd like to present that shows how to set up an
> environment-dependent property: 
> http://people.apache.org/~vmassol/m2-env-dependent-property-cargo.jpg
> 
> - Is that correct?
> 
> - Should the file put in samples/java be named profiles.xml instead of
> settings.xml? If so, how do I tell m2 to activate a profile by default (I'm
> currently using the <activeProfile> tag which belongs to settings.xml)?
> 
> - ATM I don't think that settings.xml file located in project directories
> are read. Is that going to be supported in the future? If not where do I put
> project-specific environment-dependent stuff?
> 
> BTW I have found that default profile in the pom is not working and I have
> opened a JIRA issue for this: http://jira.codehaus.org/browse/MNG-835
> 
> * Why do we have both profiles.xml and settings.xml files? When to use one
> over the another?
> 
> * Does someone knows what's already implemented from
> http://docs.codehaus.org/display/MAVEN/Build+Profiles and what's left to do?

Here's a little piece of doco that John wrote that might be of help
right now:

http://maven.apache.org/maven2/profiles-overview.html

> Thanks for your help!
> -Vincent
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
-- 
jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org