As already explained: No, it does not work this way.
Rafael Vanderlei wrote:
> 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]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
