On 22 févr. 2013, at 11:15, Francis ANDRE <[email protected]> wrote:
> Hi Pierre-Arnaud > > Le 22/02/2013 10:50, Pierre-Arnaud Marcelot a écrit : >> Hi Francis, >> >> You shouldn't embed transitive dependencies when you create a "library >> plugin". > Ok but it seems to work... when I remove manually the duplicate jar entry in > the Eclipse classpath and launch the studio, classes from the lib jars are > loaded...so, is your statement a formal and strong directive? Yeah, it will work, indeed. But this isn't the way OSGI is supposed to work. Before we moved to creating what I call "library plugins" we were using a dedicated Eclipse plugin (it was called "jars") which role was to contain all our jar libraries, exported all the classes from them and made them available to our plugins. While it worked perfectly fine for Studio plugins, we received reports that other third party plugins (installed in Eclipse by our users) were being buggy or completely non-functional. This did not affect the RCP app which only used Eclipse and Apache Directory Studio plugins. It was just a problem when users installed Apache Directory Studio in an Eclipse application alongside other third party plugins. It looked like our "jars" plugin was selected in the dependency resolution of some of those third party plugin, and given that we were not using the same library version of them, they would fail. So, in version 2.0, we removed the "jars" plugin and replaced it by proper use of OSGI capabilities. Hopefully for us, some of our dependencies were already OSGI bundle, so we could include them as is. For all other libraries, we had to repackage them into OSGI bundles (or Eclipse plugins), hence the name I gave them "library plugins". So, that's the story behind all that... >> First of all, if the library is already an OSGI bundle, you don't need to >> create one, just add it to the linked libraries from the custom Target >> Platform, this is in the 'repository' pom. >> >> If it's not an OSGI bundle, then you need to make it an OSGI by repackaging >> the jar as a "library plugin", that's what you're currently doing. >> But, as it becomes an OSGI bundle, it means all its dependencies must also >> be OSGI bundle, so you need to convert them as well, one "library plugin" >> per dependency > I have more than 25 jars as dependencies...so I would appreciate any other > alternative than building one "library plugin" per dependency if any... I understand... I've gone that path (very difficult to maintain). You could maybe try the all-in-one "jars" plugin, here's what it looked like in previous versions of Apache Directory Studio: https://svn.apache.org/repos/asf/directory/studio/tags/1.5.3.v20100330/jars/pom.xml But, keep in mind the limitations and possible issues it could bring depending on what environment you'll be running your plugins. Regards, Pierre-Arnaud >> Hope this helps, >> Pierre-Arnaud >> >> >> >> On 22 févr. 2013, at 10:14, Francis ANDRE <[email protected]> >> wrote: >> >>> Hi >>> >>> I am adding a new library to the ADS Studio by copy/paste an already >>> existing pom.xml like org.apache.commons.codec/pom.xml but the generated >>> MANIFEST.MF contains a duplicate entry even with the instruction: >>> <_exportcontents>!lib,*</_exportcontents>. The only difference with the new >>> pom.xml is the <Embed-Transitive>true</Embed-Transitive> >>> >>> What do I miss for remonving the duplicate entry? >>> >>> <configuration> >>> <manifestLocation>META-INF</manifestLocation> >>> <instructions> >>> <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName> >>> <Embed-Dependency>*;scope=compile|runtime</Embed-Dependency> >>> <Embed-Directory>lib</Embed-Directory> >>> <Embed-StripGroup>true</Embed-StripGroup> >>> <Embed-Transitive>true</Embed-Transitive> >>> <_exportcontents>!lib,*</_exportcontents> >>> <Import-Package>!</Import-Package> >>> </instructions> >>> </configuration> >>> >>> >>> >>> TIA >> >
