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
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.
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.
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.
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 )
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’.
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
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.