You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Gunnar Wagenknecht <gu...@wagenknecht.org> on 2008/09/19 23:08:18 UTC
Lucene OSGi Bundle
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.
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.
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.
I'm now asking for feedback which approach you like better and should be
integrated into the Lucene build process. Of course, if there are any
questions, I will be happy to answer them.
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene OSGi Bundle
Posted by Gunnar Wagenknecht <gu...@wagenknecht.org>.
Nicolas Lalevée schrieb:
> the classpath of Lucene is so simple (no dependency at all),
Unfortunately, it's not. Some exported packages are split across
bundles. This makes it tough to manage. I wish it would be as easy as
using BND to simply generate the manifests for the existing jars. But it
doesn't work without the BND descriptors to get the split-packages and
the version dependencies on exported/imported packages right.
BTW, the Maven OSGi plug-in is deprecated and has been replaced by this
one which is also based on BND.
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Lucene OSGi Bundle
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org