[MDEP-440] When dependency:build-classpath includeArtifactIds is set and excludeTransitive is still false, include transitive dependencies of specified artifacts

• Type: New Feature
• Status: Closed
• Priority: Trivial
• Resolution: Incomplete
• Component/s: build-classpath
• Assignee: Unassigned
• Reporter: David Boden
• Created: 25/Mar/14 07:22
• Updated: 15/Apr/17 20:45
• Resolved: 15/Apr/17 20:45

Description

Summary:

Please consider supporting on the dependency:build-classpath goal:

• includeArtifacts=component-A
• excludeTransitive=false

Result: creating a classpath containing component-A's transitive dependencies.

Detail:

My use case is that I have a large assembly .zip that includes multiple components but I want to create "personalised" scripts for each component.

Each script's classpath must include a large subset of the total list of dependencies. However, although they share many dependencies, component-A shouldn't have component-B's jar file on its classpath. Or if component-A uses Apache MQ and component-B doesn't then the Apache MQ jars shouldn't appear on component-B's classpath.

It would be convenient to be able to say "build me the classpath for component-A, including all its dependencies" within the context of the wider assembly build. Would it be appropriate to do this by setting includeArtifactIds=component-A and leaving excludeTransitive as false? At the moment, as soon as you add includeArtifactIds, only those specific artifacts are included.

The well-used alternative is to have the scripts generated in the individual component's build. The assembly pulls together all the components and scripts. However, there's no guarantee that the dependency resolution for the individual component decided on the same versions of .jar files as the overall assembly build. This can lead to some component's scripts relying on version 1.3 of Apache MQ but the asssembly packaging version 1.4. This enforcer goal exists to break the build if a potential problem is detected:
https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html

I feel that it's more convenient to build the scripts and the assembly in one shot and avoid the possibility of dependency resolution problems as far as the scripts are concerned. (of course, it opens you up to the possibility of runtime problems where a component won't execute properly because it's running against a different version of the dependency that it was compiled against).