Hi team, we have a lot of explicit exclusions in our app/pom.xml,
particularly with the Apache commons-XXX libraries:
<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
<version>1.3.1</version>
<type>jar</type>
<exclusions>
<exclusion>
<artifactId>commons-beanutils</artifactId>
<groupId>commons-beanutils</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>commons-httpclient</groupId>
<artifactId>commons-httpclient</artifactId>
<version>3.1</version>
<exclusions>
<exclusion>
<artifactId>commons-codec</artifactId>
<groupId>commons-codec</groupId>
</exclusion>
</exclusions>
</dependency>
// and several other places.
This in turn requires us to explicitly declare dependencies that would
otherwise be brought in for us transitively, bulking up our POM further.
I'd be more comfortable with explicit exclusions if we had some
commenting in the pom.xml about *why* we needed to exclude the
transitive dependencies that an explicitly declared dependency would
bring in, for each place in which we put an exclusion in. Otherwise, I
don't know if the original purpose of the exclusions were just to force
specific versions that the previous Ant build had declared, while in
reality, the version that would otherwise be chosen by Maven
transitively would be fine. Roller shouldn't be so fragile that it
needs 1.4.2 of a particular dependency but will fall apart if Maven
picks 1.4.6 for it instead, and I suspect the bulk of these exclusions
are no longer needed today, that mvn dependency:tree will show that the
versions that Maven selects in most cases are fine for Roller.
I'd like to work on simplifying the pom, removing some exclusions and
commenting the others about why they're needed. Any objections? If any
one knows off the bat why some of the exclusions *must* be in place
today and can leave comments in the pom.xml, that would be helpful.
Regards,
Glen