[#CONF-9760] Confluence 2.6.0 needs dependency cleanup

Confluence

Confluence 2.6.0 needs dependency cleanup

Created: 18/Oct/07 08:37 AM Updated: 18/Oct/07 07:57 PM

Component/s:

Engine Room / Architecture

Affects Version/s:

2.6.0

Fix Version/s:

2.6.1

Time Tracking:

Not Specified

Environment:

Confluence 2.6.0

Participants:	Gary Weaver and Matt Ryall [Atlassian]
Since last comment:	1 year, 6 weeks, 4 days ago
Resolution Date:	18/Oct/07 07:57 PM
Labels:

Description

« Hide

I just noticed that Confluence is accidentally including two versions of JTA dependencies. If you look in (confluence-std-2.6.0)/confluence/WEB-INF/lib/ there are:

~~rw-r~~r- 8809 Aug 16 03:13 jta-1.0.1.jar
~~rw-r~~r- 8382 Aug 16 03:10 jta-1.0.1B.jar

In addition there are dependencies where the newer version of the jar could likely be used instead of the older version like:

~~rw-r~~r- 247021 Aug 16 03:13 jtidy-r8-20050104.jar
~~rw-r~~r- 246990 Aug 16 03:09 jtidy-r8-21122004.jar

And (although this one looks a little scarier since it decreased in size):

~~rw-r~~r- 63992 Aug 16 03:07 mockobjects-j1.3-j2ee1.3-0.07.jar
~~rw-r~~r- 57598 Aug 16 03:07 mockobjects-jdk1.3-j2ee1.2-0.09.jar

And ofbcore which according to a different ticket isn't even being used:

~~rw-r~~r- 236334 Aug 16 03:17 ofbcore-entity-2.1.1-atlassian-21Mar06.jar
~~rw-r~~r- 150255 Aug 16 03:10 ofbcore-ofbcore-share-2.1.1.jar

Duplicate jars:

~~rw-r~~r- 6672 Aug 16 03:13 pell-multipart-2.1.5.jar
~~rw-r~~r- 6672 Aug 16 03:09 pell-multipart.jar

And mixtures of duplicate and different versions like:

~~rw-r~~r- 12318 Aug 16 03:13 alt-0.07-j1.3-j2ee1.3.jar
~~rw-r~~r- 8116 Aug 16 03:11 alt-0.07-jdk1.3.jar
~~rw-r~~r- 8116 Aug 16 03:08 alt-jdk1.3-0.07.jar

Since there was also a dependency issue in 2.5.7, it would seem as if Atlassian might want to implement some sort of process in which someone reviews the list of dependencies included with all of the developers to make sure it is sane before releasing a final build.

Dependencies of a dependency can be excluded in a Maven 2 pom by using the exclusions element, for example:

<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1</version>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
<exclusion>
<groupId>logkit</groupId>
<artifactId>logkit</artifactId>
</exclusion>
<exclusion>
<groupId>avalon-framework</groupId>
<artifactId>avalon-framework</artifactId>
</exclusion>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>
</exclusions>
</dependency>

I know that if you have two different versions of dependencies each built against some other version of the same dependency, that it is tricky to remove one or the other and in some cases perhaps it would make sense to have two different versions of the same jar and hope that the JVM can figure it all out. However, when you see duplicate dependencies in the list, to me that just looks a little sloppy.

Hope this helps.

Description

I just noticed that Confluence is accidentally including two versions of JTA dependencies. If you look in (confluence-std-2.6.0)/confluence/WEB-INF/lib/ there are: ~~rw-r~~r- 8809 Aug 16 03:13 jta-1.0.1.jar ~~rw-r~~r- 8382 Aug 16 03:10 jta-1.0.1B.jar In addition there are dependencies where the newer version of the jar could likely be used instead of the older version like: ~~rw-r~~r- 247021 Aug 16 03:13 jtidy-r8-20050104.jar ~~rw-r~~r- 246990 Aug 16 03:09 jtidy-r8-21122004.jar And (although this one looks a little scarier since it decreased in size): ~~rw-r~~r- 63992 Aug 16 03:07 mockobjects-j1.3-j2ee1.3-0.07.jar ~~rw-r~~r- 57598 Aug 16 03:07 mockobjects-jdk1.3-j2ee1.2-0.09.jar And ofbcore which according to a different ticket isn't even being used: ~~rw-r~~r- 236334 Aug 16 03:17 ofbcore-entity-2.1.1-atlassian-21Mar06.jar ~~rw-r~~r- 150255 Aug 16 03:10 ofbcore-ofbcore-share-2.1.1.jar Duplicate jars: ~~rw-r~~r- 6672 Aug 16 03:13 pell-multipart-2.1.5.jar ~~rw-r~~r- 6672 Aug 16 03:09 pell-multipart.jar And mixtures of duplicate and different versions like: ~~rw-r~~r- 12318 Aug 16 03:13 alt-0.07-j1.3-j2ee1.3.jar ~~rw-r~~r- 8116 Aug 16 03:11 alt-0.07-jdk1.3.jar ~~rw-r~~r- 8116 Aug 16 03:08 alt-jdk1.3-0.07.jar Since there was also a dependency issue in 2.5.7, it would seem as if Atlassian might want to implement some sort of process in which someone reviews the list of dependencies included with all of the developers to make sure it is sane before releasing a final build. Dependencies of a dependency can be excluded in a Maven 2 pom by using the exclusions element, for example: <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.1</version> <exclusions> <exclusion> <groupId>log4j</groupId> <artifactId>log4j</artifactId> </exclusion> <exclusion> <groupId>logkit</groupId> <artifactId>logkit</artifactId> </exclusion> <exclusion> <groupId>avalon-framework</groupId> <artifactId>avalon-framework</artifactId> </exclusion> <exclusion> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> </exclusion> </exclusions> </dependency> I know that if you have two different versions of dependencies each built against some other version of the same dependency, that it is tricky to remove one or the other and in some cases perhaps it would make sense to have two different versions of the same jar and hope that the JVM can figure it all out. However, when you see duplicate dependencies in the list, to me that just looks a little sloppy. Hope this helps.

Show »

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Gary Weaver added a comment - 18/Oct/07 09:11 AM - edited

If it helps to see dependencies visually, Andy Brook showed me this depgraph plugin which produces a pretty nifty dependency map. It requires graphviz which is free.

Andy put an example for how to use it in our plugin's pom.xml:
http://svn.atlassian.com/svn/public/contrib/confluence/custom-space-user-management/trunk/pom.xml

That might make dependencies a little more visible to developers.

[ Permlink | « Hide ]

Gary Weaver added a comment - 18/Oct/07 09:16 AM

Looks like you are already using it:
http://blogs.atlassian.com/developer/dependencyMap.html

However, it also looks hard to make anything out of. Maybe just looking at the WEB-INF/lib directory would be more helpful.

[ Permlink | « Hide ]

Matt Ryall [Atlassian] added a comment - 18/Oct/07 07:56 PM

Hi Gary,

Thanks for the report. JTidy has been fixed for 2.6.1, which I think is the only one in your list that is problematic. The others are known duplicates that won't affect Confluence's operation. Let me explain that a bit more.

We have an automated test now to check for duplicated classes in the webapp. This is to help us find these duplicated JARs. At the moment, we're excluding a few packages from the test for known duplicates which are the same version (JTA, OfBiz-core, Pell, mockobjects, alt and javamail fall into this category). You can see the full list in the source at com.atlassian.confluence.util.classpath.ClasspathJarDuplicateClassFinder.KNOWN_DUPLICATES.

We aim to reduce the list over the next couple of stable releases. But in the meantime they should be limited to the known duplicates which are either the same version or not used by Confluence directly. Many of the duplicates are from the Maven 1 to Maven 2 migration of our dependent libraries; these need to be changed with care because they're shared across a few different products.

On your Confluence instance, you can run the duplicate class check at any time by visiting http://confluence.example.com/admin/classpath.action. This lists the JARs on the classpath, and displays the result of the duplicate check at the bottom of the page.

Please report any new ones you see.

Thanks,
Matt

[ Permlink | « Hide ]

Matt Ryall [Atlassian] added a comment - 18/Oct/07 07:57 PM

JTidy was fixed for 2.6.1. The others will be cleaned up as the dependent libraries are migrated to Maven 2 properly.