Maven dependencies in profile section are not supported

It seems to me that gradle does not download per default the transitive dependencies from a maven repo when they are defined in a profile section of a pom. Am I missing a configuration? Or can I somehow define which profile should be taken? An example is

group: 'com.sun.jersey.jersey-test-framework', name: 'jersey-test-framework-grizzly2', version: '1.10'

which has a default profile section with two dependencies:

<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>com.sun.jersey.jersey-test-framework</groupId>
<artifactId>jersey-test-framework-core</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-grizzly2-servlet</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
</profile>

Both of them I don’t see in the dependency tree.

This sounds like a bug to me: I’ve raised an issue in Jira (GRADLE-1997)

I wonder whether a profile section has any relevance in a realized POM (i.e. one published to a repository). For example, if activation is based on an environment variable, would it really be expected that this is resolved at dependency resolution time? Aren’t Maven profiles a build-time concept?

Yes and no, because you can define a default profile and I would expect that at least this profile will be taken by gradle to resolve dependencies which might be defined in there.

Is that how it works in Maven? A profile that’s active by default is considered, and others are not? Sounds a bit arbitrary to me.

yup. from maven spec:

Profiles can also be active by default using a configuration like the following:

<profiles>
    <profile>
      <id>profile-1</id>
       <activation>
          <activeByDefault>true</activeByDefault>
       </activation>
       ...
    </profile>
 </profiles>

This profile will automatically be active for all builds unless another profile in the same POM is activated using one of the previously described methods. All profiles that are active by default are automatically deactivated when a profile in the POM is activated on the command line or through its activation config.

So my real world problem is like that:

<profile>
  <id>default</id>
   <activation>
    <activeByDefault>true</activeByDefault>
   </activation>
   <dependencies>
    <dependency>
     <groupId>com.sun.jersey.jersey-test-framework</groupId>
     <artifactId>jersey-test-framework-core</artifactId>
     <version>${project.version}</version>
    </dependency>
    <dependency>
     <groupId>com.sun.jersey</groupId>
     <artifactId>jersey-grizzly2-servlet</artifactId>
     <version>${project.version}</version>
    </dependency>
   </dependencies>
  </profile>
 </profiles>

taken from http://search.maven.org/remotecontent?filepath=com/sun/jersey/jersey-test-framework/jersey-test-framework-grizzly/1.11/jersey-test-framework-grizzly-1.11.pom

The text you quote says nothing about the expected behavior in a realized POM. It would be good to know what the actual (impl) and expected (spec) behavior is in this case.

The text is taken directly from http://maven.apache.org/guides/introduction/introduction-to-profiles.html So when I generate a pom file for my project and include a dependency like

<dependency>
  <groupId>com.sun.jersey.jersey-test-framework</groupId>
  <artifactId>jersey-test-framework-grizzly2</artifactId>
  <version>1.10</version>
</dependency>

then maven will download the dependencies defined in the profile section. So as far as I know, and I am not a maven guru, it is allowed to define dependencies in that section. That means in fact that you can define compile dependencies in there which are needed by other applications later on, otherwise they might get ClassNotFoundException.

So from my point of view it is critical that gradle doesn’t do it in the way maven does because that means it may always happen that I get a ClassNotFoundException because someone defined a dependency in a pom file in the profile section, which is really hard to test. I cannot inspect all pom files of all dependencies of my application (or better, I don’t want to :wink: )

So as far as I can see that is the impl part. I don’t know whether maven should itself move these dependencies to an upper level when creating a ‘realized pom’.

Ditto,

I can’t build a basic jersey project without expanding all transitive dependencies by hand.

From the Gradle docs regarding dependency management: > Gradle also validates your dependency hierarchy against the reality of your code by using only the first level dependencies for compiling.

Does this mean that, as cowboyd mentions, you will always need to expand transitive dependencies by hand, e.g. in the case of Jersey, even if GRADLE-1997 is resolved?

I was under the impression that transitive dependencies in Maven are included on the compile build path (if it is declared as a compile-time dependency), not just the first level?

Gradle has been enjoyable to use so far, keep up the great work :slight_smile:

As a concrete example, I am using this:

dependencies {
    compile 'javax.ws.rs:jsr311-api:1.1.1'
    runtime module('com.sun.jersey:jersey-server:1.12') {
        dependency('com.sun.jersey:jersey-core:1.12')
        dependency('com.sun.jersey:jersey-servlet:1.12')
    }
}

But it seems that I should just be able to say (assuming GRADLE-1997 is resolved):

dependencies {
    compile 'javax.ws.rs:jsr311-api:1.1.1'
    runtime 'com.sun.jersey:jersey-server:1.12'
}

Unless, for some reason, I wanted to mess around with the transitive dependencies declared by the Jersey POMs.

Am I missing something?

Note: the build succeeds without the runtime dependency but the necessary JARs are not included in the WAR file so there are ClassNotFound exceptions at runtime.