Le 19 sept. 08 à 23:08, Gunnar Wagenknecht a écrit :
Hi Lucene Developers,
Issue 1344 requests to make the Lucene JAR an OSGi bundle. The
approach
proposed is to add the OSGi specific meta data into the MANIFEST.MF of
the existing Maven artifacts.
I prepared a patch which proposes a different approach. Instead of
adding the headers into the Maven JARs it will create a new set of
OSGi
JARs.
This is basically driven by the following advantages.
1. In OSGi the naming convention for a bundle JAR file is "<symbolic
name>_<version>.jar". The Maven JARs are not fully qualified.
Therefor,
it's not possible to use them out of the box, i.e. one has to download
and manually rename them before they can be used. A separate set of
OSGi
bundles could be consumed directly without any modifications.
Even if it is hardly recommended just for sanity, there is no direct
relation between the name of the jar and its OSGi metadata. This hard
binding only exist in an Eclipse environment.
2. Maven repositories cannot be consumed directly by OSGi frameworks.
It's better to have the OSGi bundle jars in one folder which can be
downloaded from mirrors and consumed by frameworks directly.
actually it is possible. A maven plugin exist to manage a OSGi bundle
with maven:
http://felix.apache.org/site/apache-felix-maven-osgi-plugin.html
And there is a maven repository which contains OSGi bundles:
http://www.springsource.com/repository
And in fact, that repository is mainly a repository of jar. And there
is different kind of metadata around it so that different dependency
management tools (maven, ivy, obr) can use it.
3. In addition to the OSGi bundle JAR I was able to generate a source
jar for Eclipse PDE. Thus, whenever you are developing with Eclipse
for
*any* OSGi framework one would simply throw the Lucene OSGi bundle
JARs
together with the source bundles into the target platform. Eclipse PDE
then configures the classpath automatically to attach the source
code to
the class files. This is very developer friendly.
This could also be done in the source jars in the maven artifacts.
So I think there is no hard requirement to have a complete different
build for having OSGi metadata into the Lucene jars. The question here
is just about the naming convention of the jars.
I don't have any objection of having a third distribution layout, but
it will somehow increase the work of the Lucene developers when
releasing because it will add some extra sign/deploy/check work.
So if Lucene developers are up to have an OSGi jar naming convention,
I think that a good build would be to include the OSGi headers into
the manifest to the actual jar (as does the patch I provided), and add
an extra task to copy the maven jars into an OSGi layout.
Then there can be a debate on to use or not to use the bnd tool (this
tool used as an ant task in Gunnar's patch tries to leverage the
maintenance of manifest file). I didn't used it in my patch because
the classpath of Lucene is so simple (no dependency at all), that I
thought it would be simpler for Lucene developers to maintain a
MANIFEST.MF than a lucene.bnd. Here again, this can be question of
taste for the Lucene developers.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
