4

Must I define every single spring library one by one in my pom.xml , or is there somekind of multipack?

I found out that, for example, when I let maven download spring-core, it also downloaded spring-asm.

Are there more such packs or similar shortcuts....?

Jaanus
  • 16,161
  • 49
  • 147
  • 202
  • Do you _really_ need all of the Spring? – Andrew Logvinov Sep 07 '12 at 15:29
  • @AndrewLogvinov : aop, asm , beans, context, core , expression, jdbc, oprm, transaction , web, web-servlet, so thats alot. – Jaanus Sep 07 '12 at 15:33
  • 1
    most of those will depends on beans, context, core, etc. You can just list dependencies on the leaf libraries. Also, in the time it took to write this question and wait for an answer, you could have typed up the `` elements for 11 of them :) – matt b Sep 07 '12 at 15:40
  • 2
    Or he could have used **Gradle** or **SBT** and do a for loop on the list of dependencies (to be DRY, lazy, and clever). I never did understand why people have such a problem with Maven or doing build files correctly. You only have to modify it a couple of times compared to everything. **Just do it right the first time!** – Adam Gent Sep 07 '12 at 15:45

1 Answers1

5

There is a possible duplicate here: Maven - include all submodules of a pom as dependencies in another module

The short answer is no. The long answer is even if you could it would not be a good idea.

Spring used to offer a bundle groupId=org.springframework artifactId=spring and groupId=org.springframework artifactId=spring-all. For various reasons (I can't find the link) Spring decided this was a bad practice and I tend to agree.

The best thing to do is if your really want to include all the spring submodules is to use parent poms and a property to denote the version ... eg:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.snaphop</groupId>
  <artifactId>snaphop-parent</artifactId>
  <version>0.0.53-SNAPSHOT</version>
  <name>snaphop-parent</name>
    <packaging>pom</packaging>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <java.version>1.6</java.version>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <spring.version>3.1.0.RELEASE</spring.version>
    </properties>

..skip some lines

<dependencyManagement>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
            <version>${spring.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>${spring.version}</version>
        </dependency>

You'll have to read about parent poms here: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Inheritance_vs_Project_Aggregation (or just google).

The other option is to make your own dummy project with all spring dependencies and depend on that.

That being said I really recommend you explicitly choose your dependecies as it can really help modularize/decouple/refactor your project in the future.

Community
  • 1
  • 1
Adam Gent
  • 47,843
  • 23
  • 153
  • 203
  • 1
    It's considered a bad practice to directly use some class without explicitely depending on the artifact providing it, i.e. using the transitive dependencies of your dependencies. If your dependency removes the transitive dependency in a later version, your code will fail (either at compile time or at run time). – Frank Pavageau Sep 07 '12 at 15:44
  • @FrankPavageau I agree (I must have not made that clear enough) that its a bad idea. I recommend he explicitly state his dependencies or use a parent pom. The dummy project idea is a cop out. – Adam Gent Sep 07 '12 at 15:48
  • oh that was clear, I just thought I'd give an example as to why it's a bad idea. I agree with your other comment that's it's not the part of the job that takes the longest, so you spend a bit more time to do it right. And you can always use `mvn dependency:analyze` for help. – Frank Pavageau Sep 07 '12 at 16:04