You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Glen Mazza <gl...@gmail.com> on 2013/07/14 04:25:03 UTC
reducing dependency exclusions in app/pom.xml
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
Re: reducing dependency exclusions in app/pom.xml
Posted by Glen Mazza <gl...@gmail.com>.
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 <gl...@gmail.com> 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
>>
>>
Re: reducing dependency exclusions in app/pom.xml
Posted by Glen Mazza <gl...@gmail.com>.
OK, I'll experiment a bit to see if I can simplify a few things.
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 <gl...@gmail.com> 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
>>
>>
Re: reducing dependency exclusions in app/pom.xml
Posted by Dave <sn...@gmail.com>.
+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 <gl...@gmail.com> 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
>
>