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
