Starting in May I began adding several JIRA issues related to 'Overweight OSGi bundles'.
http://issues.apache.org/jira/browse/DIRSERVER-622 http://issues.apache.org/jira/browse/DIRSERVER-653 http://issues.apache.org/jira/browse/DIRSERVER-654 http://issues.apache.org/jira/browse/DIRSERVER-655 Overview of the problem - What is common to all of these issues is that the unnecessary jars being added to the OSGi bundles in the maven build are coming from the inherited pom.xmls up the ancestor chain. My patches simply broke the chain at the osgi poms. There is a better alternative... Details - For each ADS osgi bundle it's maven pom.xml is inheriting from its parent -> trunks/apacheds/osgi/pom.xml, which in turn inherits from its parent --> trunks/apacheds/pom.xml. For naming sake trunks/apacheds/pom.xml is the grandfather of each of the osgi pom.xml files. It's maven group/artid/ver is: <groupId>org.apache.directory.server</groupId> <artifactId>build</artifactId> <version>1.1.0-SNAPSHOT</version> And trunks/apacheds/pom.xml is where the problem starts. Inside the trunks/apacheds/pom.xml one dependency is specified. <dependency> <groupId>org.apache.directory.shared</groupId> <artifactId>shared-ldap</artifactId> <version>0.9.6-SNAPSHOT</version> </dependency> And this dependency and its transitive dependencies cascade down the inheritance chain adversely effecting children that don't need shared- ldap (and its transitives) - like the osgi projects. This kind of dependency is not a good thing to have in a ancestor pom unless all its descendants need it, and that is not the case for apacheds. So that dep needs to be removed from the trunks/apacheds/pom.xml and placed only in the descendant poms that really need to use it. Once done my patches will not be needed and we will still keep a nice inheritance chain up to the root pom.xml. Note: I have not investigated which projects in the trunks/apacheds directory outside of the osgi sub directory will be effected. I wanted to get this out in the air for discussion. Comments? John
