Hi Jörg. Thanks for response.

Do you have knowledge enough about Maven to tell if it would be too
difficult, if even possible, for Maven to activate profiles based on user
properties defined on a pom? I mean.. if a property defined on a major
pom.xml is visible to a child pom.xml why wouldn´t this property be able to
activate a profile configured on that child pom.xml to be activated when a
property is found?

Basically, what I´m trying to say is:

If i have a simple pom.xml like

ProjectA/pom.xml {
...
//Declares ProjectB as a module
...
<properties>
     <activate.custom.profile>true</activate.custom.profile>
</properties>
...
}

And if I have another simple pom.xml like

ProjectA/ProjectB/pom.xml {
...
//declares ProjectA/pom.xml as parent
...
//makes some use of ${activate.custom.profile} like
<build><finalName>${activate.custom.profile}</finalName></build>
...
<profiles>
     <profile>
          <id>custom.profile</id>
          <activation>
               <property>
                    <name>activate.custom.profile</name>
                    <value>true</value>
               </property>
          </activation>
     </profile>
</profiles>
...
}

So, in ProjectB if I can make use of ${activate.custom.profile} to specify
the final name of the package, why can´t I make use of it to activate the
profile with id "custom.profile" ?

I can only think it´s a bug or, if there´s no suitable reason for that
feature not to be possible to implemented, it´s maybe something that hasn´t
been thought to be implemented.


On Thu, Mar 24, 2011 at 2:15 PM, Jörg Schaible <[email protected]>wrote:

> Hi Rafael,
>
> Rafael Vanderlei wrote:
>
> [snip]
>
> > Now that you know the problem I had with M2Eclipse, it comes the issue
> I´m
> > having with Maven itself, that occurred when I tried a solution to that
> > problem with M2Eclipse. Maven has lots of ways to activate profiles and
> so
> > I tried to combine 2 of them: specifying the profile on the command line
> > and using property. Basically, what I did was:
> >
> > 1. On the pom.xml of that module with 30 profiles, I configured
> activation
> > by properties like "name: activate.profile1 / value: true", "name:
> > activate.profile2 / value: true" and so on...
> > 2. On the major pom.xml, I created a profile (with the option
> > "activatedByDefault" set to true) that combines the intern module
> > profiles, i.e, I created a "major.profile" which sets the properties
> > "activate.profile1=true", "activate.profile5=true",
> > "activate.profile10=true", "activate.profile15=true" and so on...
> >
> > As the profile is activatedByDefault, I would not need to tell M2Eclipse
> > which profile I want to activate (so I would not have any repeated list
> of
> > profiles to configure on all the projects). I was happy with the solution
> > (as, in theory, it should work) until I tried to build with it... I
> > thought that running on the command line mvn -Pmajor.profile package
> would
> > set all the properties I defined on that profile and on cascade by doing
> > so I would activate all the profiles defined on the internal module. But
> > it did not work. It seems that Maven activation by properties doesn´t
> work
> > the way I thought.. it seems it works only if you specify the property on
> > the command line.
>
> Profiles do simply not work this way. A profile is always "local" to the
> pom
> where it is defined, profile activation is not inherited i.e. if a profile
> is activated in the parent, the activation is not propagated to the child
> pom, even if it defines a profile with the same name.
>
> Profiles cannot be activated by Maven properties, simply because Maven has
> to activate the proper profiles before it can build the effective pom -
> which defines the properties.
>
> You can activate a profile with a special id globally by activating it in
> the settings.xml, from command line or by using an activation that evauates
> to true before the effective pom is built.
>
> [snip]
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to