Best way to get maven dependencies - maven-2

Question

I only need to use this class org.apache.commons.io.FileUtils, and yet I'm downloading all commons Classes which I actually don't need, is there a way to say to maven download just FileUtils class? Not whole commons like from dependency below
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>1.4</version>
</dependency>

Answer 1

is there a way to say to maven download just FileUtils class?
No. But depending on your exact use case, you could maybe use the Maven Shade Plugin to create an uber-jar and filter the content of the included dependencies:
Selecting Contents for Uber JAR
...
For fine-grained control of which
classes from the selected dependencies
are included, artifact filters can be
used:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>1.3.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<filters>
<filter>
<artifact>junit:junit</artifact>
<includes>
<include>junit/framework/**</include>
<include>org/junit/**</include>
</includes>
<excludes>
<exclude>org/junit/experimental/**</exclude>
<exclude>org/junit/runners/**</exclude>
</excludes>
</filter>
<filter>
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
</excludes>
</filter>
</filters>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
Here, Ant-like patterns are used to
specify that from the dependency
junit:junit only certain
classes/resources should be included
in the uber JAR. The second filter
demonstrates the use of wildcards for
the artifact identity which was
introduced in plugin version 1.3. It
excludes all signature related files
from every artifact, regardless of its
group or artifact id.
But note that FileUtils depends on other classes:
import org.apache.commons.io.filefilter.DirectoryFileFilter;
import org.apache.commons.io.filefilter.FalseFileFilter;
import org.apache.commons.io.filefilter.FileFilterUtils;
import org.apache.commons.io.filefilter.IOFileFilter;
import org.apache.commons.io.filefilter.SuffixFileFilter; // depends on org.apache.commons.io.IOCase
import org.apache.commons.io.filefilter.TrueFileFilter;
import org.apache.commons.io.output.NullOutputStream;
That you'll obviously need to include too.

Answer 2

Apache commons io has no dependencies to other apache commons projects. You get only commons io, no other commons libraries. That is one jar with about 100 classes, not very much.
You cannot get only one class into your project - this would propably also violating the license!
A look at FileUtils source also shows a lot of imports of other commons io classes. It will not work without the rest of the jar!

Answer 3

Use the dependency <exclusion> element
<dependency>
<groupId>sample.ProjectA</groupId>
<artifactId>Project-A</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion> <!-- declare the exclusion here -->
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
</exclusion>
</exclusions>
</dependency>
to exclude those transitive dependencies that you don't need.
It is also a good practice to use mvn dependency:analyze-only and mvn dependecy:tree to understand how your depency graph is actually structured and what dependencies are you really using and not declaring and/or declaring and not using.
Regards.

Answer 4

I don't think so. The artifacts are packaged as jar files; you can't get them individually (that is, on a file-by-file basis). At least, not to my knowledge.
Also, think about it a little more - it is entirely possible that the FileUtils class has dependencies on other classes. But you can't really tell what they are without examining the source. That is information the user of the package does not need to know. You wouldn't want to figure out every other class that FileUtils uses (or what other classes the dependencies of FileUtils uses and so on and so forth). This is why the entire artifact is distributed as a discrete and self-contained entity. The artifact as a whole, if it is mavenized, will know what dependencies it needs and maven will go grab those for you as well.