Transitive Dependencies in a profile are not used

are you able to produce a small test case to demonstrate this?

Here is an example of 2 pom files that will show the problem, also note that the active profile is defined in settings.xml

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>a</artifactId>
<version>1.0</version>
<packaging>jar</packaging>
<name>a test</name>
<profiles>
<profile>
<id>struts-old</id>
<dependencies>
<dependency>
<groupId>struts</groupId>
<artifactId>struts</artifactId>
<version>1.1</version>
<scope>compile</scope>
</dependency>
</dependencies>
</profile>
<profile>
<id>struts-new</id>
<dependencies>
<dependency>
<groupId>struts</groupId>
<artifactId>struts</artifactId>
<version>1.2.7</version>
<scope>compile</scope>
</dependency>
</dependencies>
</profile>
</profiles>
</project>

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>b</artifactId>
<version>1.0</version>
<packaging>war</packaging>
<name>b test</name>
<dependencies>
<dependency>
<groupId>test</groupId>
<artifactId>a</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
</dependencies>
</project>

This happens because dependency POMs aren't currently candidates for profile triggering.

However, it seems we will have to trigger profiles for these POMs...otherwise, we'll lose the ability to target a build for a given platform where it will require the inclusion of a helper API.

Set a better title

since profiles are identified by ids, it will probably happen that these IDs will clash in completely unrelated 3rd party libraries. maybe the scope of dependency pom profile triggering should be limuted to the same groupId?

I would not like limiting the scope of the dependency pom profile triggering to the same groupId. I'm working on a very large project with a lot of groupId's. The complete project can run on a middleware project or a stub of it. To accomplish this, the data objects that the applications use to communicate with the middleware will be either the 'real' implementations or the stubbed ones. So for each data object we have two versions: "impl" and "stub". To get the right dependencies, each project that uses the data objects will have two profiles, called "impl" and "stub". Now if I want to build an application with Maven, I will activate either profile. I just discovered that this does not work with Maven right now!

So I have this situation regarding dependencies:

A
  - B
  - profile id="stub"
    - DO1_stub
  - profile id="impl"
    - DO1_impl

B
  - profile id="stub"
    - DO2_stub
  - profile id="impl"
    - DO2_impl

If I run "mvn -Pstub clean package" on A's pom, then I will have DO1_stub but not DO2_stub!

I think that the profile id problem should be solved by good naming conventions, not by limiting the scope since that will reduce the applicability a lot. For example if it is a local profile, prefix it with the artifactId. If it is to be used within a group, prefix it with the groupId etc.

Update: the situation described above does work when profile activation using properties is used:

<profile>
  <id>stub</id>
  <activation>
    <property>
      <name>stub</name>
    </property>
  </activation>
  ...
</profile>

Running "mvn -Pstub -Dstub clean package" on A's pom gives both DO1_stub and DO2_stub.

I second Milos' concern about clashing profile ids. I think the approach outlined by Paul in MNG-4531 is more appropriate.

We are also waiting for this bug solve (have issue similar to described in MNG-4985).
We have a lot of modules, which form a hierarchy (3 or 4 levels). Modules can be built with classifiers ("release", "debug" etc). When war project references these modules, transitive dependencies without any classifiers are used.
In fact that makes "classifier paradigm" useless.