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:henr...@yahoo.fr]
Gesendet: Mittwoch, 19. August 2009 09:48
An: users@maven.apache.org
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
groupIdorg.junit/groupId
artifactIdcom.springsource.org.junit/artifactId
version4.5.0/version
scopetest/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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
