5

I have a project that needs to depend on a ZIP file which is produced by another project. That 'other project' is not under my control. The ZIP file is required for correctly building my project. It is not required for execution of my project. I need Maven to download the ZIP file for me.

I currently create a dependency on the ZIP artifact like this:

<dependency>
    <groupId>org.foo</groupId>
    <artifactId>zeus</artifactId>
    <version>1.1</version>
    <type>zip</type>
    <scope>test</scope>
</dependency>

My problem is the scope. If I use anything but test it brings with it a lot of transitive dependencies from 'other project' which screws up my own project. Using test as the scope actually does the job but it shows in my IDE as a Test-dependency. So I feel I'm doing something wrong. This is not a test-dependency!

I've looked through the available Maven scopes ('compile', 'provided', etc) and I just cannot seem to find one that matches my use case. Am I doing something wrong?

peterh
  • 18,404
  • 12
  • 87
  • 115
  • i would use 'provided' and worst-case exclude any extras it drags along with it (tip: use mvn dependency:tree to get a nice visualization for you dependency structure) – radai Dec 11 '13 at 08:06
  • @radai. I need Maven to download the dependency for me. Does 'provided' do that? – peterh Dec 11 '13 at 08:11
  • @radai `provided` won't work as this is the opposite of what the OP wants. `provided` means "required at compile time but **not** at run time". – Boris the Spider Dec 11 '13 at 08:13
  • The issue would seem to be with the other artefact - the zip should be built such that transitive dependencies aren't bundled with it. Short of manually excluding the dependencies you don't want I reckon the only thing to do is use the shade plugin. – Boris the Spider Dec 11 '13 at 08:17
  • @BoristheSpider. While I do not have control over 'other project' I can create an in-between project between my own project and that 'other project' and that in-between project would then use the shade plugin in order to exclude dependencies. Would that work? I've never worked with the shade plugin before. Thanks for pointing it out. – peterh Dec 11 '13 at 08:24
  • @nolan6000 Yup, that would work fine. The only painful thing would be version changes as you would have to change the dependency in your intermediate project, release it, then change the dependency in your main project. Removes the mess from your POM at the expense of a bit of maintenance overhead - your decision. – Boris the Spider Dec 11 '13 at 08:44

2 Answers2

3

You can just exclude all transitive dependencies with wildcard:

<dependency>
    <groupId>org.foo</groupId>
    <artifactId>zeus</artifactId>
    <version>1.1</version>
    <type>zip</type>
    <scope>compile</scope>
    <exclusions>
        <exclusion>
            <groupId>*</groupId>
            <artifactId>*</artifactId>
        </exclusion>
    </exclusions>
</dependency>

(source Exclude all transitive dependencies of a single dependency)

AntoineT
  • 31
  • 2
1

You have to declare all transitive dependencies as exclusions:

<dependency>
    <groupId>org.foo</groupId>
    <artifactId>zeus</artifactId>
    <version>1.1</version>
    <type>zip</type>
    <scope>compile</scope>
    <exclusions>
       <exclusion>
          <groupId>org.foo</groupId>
          <artifactId>transitive-dep-1</artifactId>
       </exclusion>
       <exclusion>
          <groupId>org.foo</groupId>
          <artifactId>transitive-dep-2</artifactId>
       </exclusion>
       <!-- add all transitive deps. -->
    </exclusions>
</dependency>
eolith
  • 1,366
  • 10
  • 14
  • 1
    Thanks. I guess that could be a maintenance nightmare as I would have to keep track of that other project's dependencies. I feel my use case is simple, and somewhat strange that there's (apparently) no obvious solution. I just want to depend on a zip artifact ... how difficult is that? (whenever I find myself thinking like this I always try to look myself in the mirror and think that perhaps I've misunderstood Maven concepts?) – peterh Dec 11 '13 at 08:29
  • For various reasons I'm going with this solution (despite the maintenance nightmare, as I see it) and not using the shade plugin as suggested elsewhere. Thanks. – peterh Dec 11 '13 at 09:30