Profile dependencies not working
Closed this issue · 9 comments
In my setup I have all the profiles defined in the parent pom and one of the childs defines a dependency in one of the profiles defined in top but that dependency is never included in the execution.
To help to explain it I have the following hierarchy A->B->C1,C2,C3 the dependency X is set in a child project for profile B. If I set profile C1 X is not included, if I set B it is included.
I am using maven 3.3.3 with the latest version of the plugin
Can you elaborate which profiles are defined in which pom or give an abbreviated source for both parent and child pom...
/pom.xml (parent)
<profile>
<id>foo-min</id>
<properties>
<nm.client>foo</nm.client>
<nm.core.database>oracle-foo</nm.core.database>
<nm.log.environment>production</nm.log.environment>
<nm.process.environment>production</nm.process.environment>
</properties>
</profile>
<profile>
<id>foo</id>
<properties>
<profile.depends>foo-min</profile.depends>
<nm.repository.database>oracle-repository</nm.repository.database>
<nm.ui.environment>production</nm.ui.environment>
<nm.ui.security>preAuth_requestHeader_custom</nm.ui.security>
<nm.ui.host>foo</nm.ui.host>
<nm.uimdoule.mkt.host>foo</nm.uimdoule.mkt.host>
</properties>
</profile>
<profile>
<id>foo-prod</id>
<properties>
<profile.depends>foo</profile.depends>
<nm.core.log>foo-prod</nm.core.log>
</properties>
</profile>
<profile>
<id>foo-prod-1</id>
<properties>
<profile.depends>foo-prod</profile.depends>
<nm.core.host>foo-prod-1</nm.core.host>
<nm.core.cache>foo-prod-1</nm.core.cache>
<nm.process.host>foo-prod-1</nm.process.host>
</properties>
</profile>
<profile>
<id>foo-prod-2</id>
<properties>
<profile.depends>foo-prod</profile.depends>
<nm.core.host>foo-prod-2</nm.core.host>
<nm.core.cache>foo-prod-2</nm.core.cache>
<nm.process.host>foo-prod-2</nm.process.host>
</properties>
</profile>
<profile>
<id>foo-prod-3</id>
<properties>
<profile.depends>foo-prod</profile.depends>
<nm.core.host>foo-prod-3</nm.core.host>
<nm.core.cache>foo-prod-3</nm.core.cache>
<nm.process.host>foo-prod-3</nm.process.host>
</properties>
</profile>
<profile>
<id>foo-prod-4</id>
<properties>
<profile.depends>foo-prod</profile.depends>
<nm.core.host>foo-prod-4</nm.core.host>
<nm.core.cache>foo-prod-4</nm.core.cache>
<nm.process.host>foo-prod-4</nm.process.host>
</properties>
</profile>
/ear/pom.xml (Child)
<profile>
<id>foo</id>
<dependencies>
<dependency>
<groupId>es.dtg.nm</groupId>
<artifactId>nm-web-spring-security-fooWS</artifactId>
</dependency>
</dependencies>
</profile>
If I activate profile "foo" in the command line the dependency is added but if I use "foo-prod-1" it does not get added.
Please tell me if you need some more information.
AFAIK, this is a limitation of Maven.
You can activate a profile by a parameter provided by a command line switch for instance.
But you cannot provide this parameter in another profile.
In a word you can't "chain" profiles activation...
Regards.
Ok, I've got it... This is not currently supported.
The problem is that maven resolves profiles separately. It first resolves profiles in current pom, and than resolves profiles in it's parent. Theoretically we can support dependencies from profile defined in child pom to profile defined in parent pom, but never other way around...
Currently, you should probably move (and possibly rename) your foo profile from child pom to parent pom to support correct profile chaining...
My current strategy is to move everything into some kind of uber-parent-pom and use only property customization in child poms.
This limitation is difficult to overcome since maven does lots of stuff between child and parent pom processing.
@debovema By the way you can certainly chain profiles with this extension. This is the whole point of maven-profiledep-extension
Umm well I understand the problem but that reduces a lot the use cases for the extension and it won't be enough for me.
By the way I think the idea is a great and I think everyone needs this kind of profile dependencies if the project gets big enough.
Thank you. I understand you sentiment, I've been thinking about ways to overcome this limitation, but it seems very hard in current Maven infrastructure.