I was able to shrink it quite a bit in the past couple of weeks, from about 1150 lines to 750 today.

Glen

On 07/14/2013 03:11 PM, Dave wrote:
+1

I think the main reason that those excludes are present is that modules we
depend on like Struts and JPA would bring in different versions of the same
jars. So we would get foolib-1.2.jar and foolib-1.4.jar, which is redundant
and can cause errors. Another reason, as I remember, was to exclude
transitve dependencies that we do not need.

Things have changed over time and it's probably a good idea to review those
excludes and see where we can simplify.

- Dave




On Sat, Jul 13, 2013 at 10:25 PM, Glen Mazza <[email protected]> wrote:

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



Reply via email to