Hi I know just a little bit about OSGi :-)
About 1) This isn't possible, since the OSGi Manifest states what packages are visible for the user of the JAR. You can't automate that, it has to be planned by the authors. On the other hand, a lot of Apache Commons projects already build OSGi compliant JARs, and still SpringSource has their own versions of them... Best regards, Eric > -----Ursprüngliche Nachricht----- > Von: Julien HENRY [mailto:[email protected]] > Gesendet: Mittwoch, 19. August 2009 09:48 > An: [email protected] > Betreff: OSGi compatible dependencies > > Hi, > > Foreword: I hadly know anything about OSGi. > > I recently discovered that Springsource is maintaining a > parallel set of "common" dependencies in their own repository > using modified artifactId. > For example: > > <dependency> > <groupId>org.junit</groupId> > <artifactId>com.springsource.org.junit</artifactId> > <version>4.5.0</version> > <scope>test</scope> > </dependency> > > As I said I'm not using OSGi but I was testing the Roo tool. > To make it short Roo generate a Maven2 application and the > pom.xml was full of this kind of dependencies. It was very > annoying to me because even if I had all these dependencies > already in my local repository, I had to download them again. > > After asking the reason of duplicating artifacts, someone > explained to me [1] that these artifact are slighly modified > to be OSGi compliant (AFAIK it means adding some standard > properties in the manifest, correct me if I am wrong). > > Again I'm not an OSGi aware developer, but I'm very concerned > by avoiding duplicate artifacts. Duplicating artifact will > lead to confusion for developpers, it will increase size of > both local and managed repositories, .... Sometimes there are > good reason to duplicate, but for me this is not a good > reason because AFAIK an OSGi compliant JAR can work in a > regular application. > > I'm not blaming Spring guys for what they did, as this was > certainly the only quick way to have it working with full > control. But IMHO it would be better to think of a standard > way to provide OSGi compliant JARs, especially because I > heard Maven 3 will address this area. > > Some proposal : > 1) Make all future JAR uploaded to Central OSGi compliant (is > it possible to automatically enhance the MANIFEST?) => > simplest/transparent solution for end users > 2) OSGi compliant JARs use a separate classifier (we can have > the regular junit-XX.jar and junit-XX-osgi.jar) => this > solution can be used for all existing artifacts that can't be > modified on central. > > What do you think? > > Regards, > > Julien > > > [1] http://forum.springsource.org/showthread.php?p=255777 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
