Eclipse: exclude a 'runtime' maven dependency from the build path

Question

I have a project that needs a dependency on iText 5.5.2 and on iText 2.1.7 (Primefaces needs this specific version at runtime and won't work with iText 5 due to license issues).

So I have this in my pom.xml:

<dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>itextpdf</artifactId>
    <version>5.5.2</version>
    <scope>compile</scope>
</dependency>

<!-- iText 2.1.7 is necessary at runtime to have the 'Export to PDF' function of Primeface work -->
<!-- It won't conflict with iText 5 as the packages are different -->
<dependency>
    <groupId>com.lowagie</groupId>
    <artifactId>itext</artifactId>
    <version>2.1.7</version>
    <scope>runtime</scope>
</dependency>

The problem is that I don't want our developers to be able to import classes from iText 2.1.7 (com.lowagie.* package). I want to force them to use classes from iText 5.5.2 (com.itextpdf.* package).

Although iText 2.1.7 is in 'runtime' scope, Eclipse still adds the jar file in the build path, allowing developers to import the wrong package (com.lowagie instead of com.itextpdf).

Is there a way to exclude it from the build path ?

Answer 1

Unfortunately it seems not to be possible on Eclipse with a normal build, it is a known bug, check Bug 414645 and Bug 376616 . Eclipse (m2e) can't properly manage Maven dependencies scope.

However, if you place the runtime dependencies on a profile, then Eclipse will not add them to the classpath (the profile shouldn't be active by default, though). I just tested it on Eclipse Mars and it works perfectly.

Hence, in your case you could add to your POM:

<profiles>
    <profile>
        <id>runtime</id>
        <dependencies>
            <dependency>
               <groupId>com.lowagie</groupId>
               <artifactId>itext</artifactId>
               <version>2.1.7</version>
               <scope>runtime</scope>
            </dependency>
        </dependencies>
    </profile>
</profiles>

As such, it can't be used to compile on Eclipse. However, your build would then need to use it at runtime, running with -Pruntime in this case.

Although adapting your POM and build to an issue of an IDE might not be ideal, it could be a good compromise to achieve your goal.