You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Nikolaos Abatzis <Ni...@newriversystems.com> on 2011/04/06 18:49:22 UTC
Jena as OSGi bundle
All,
I googled and found some email threads between Paolo and the folks at Clerezza regarding creating an OSGi bundle for Jena.
Are there any news on this, as we are using Jena in an OSGi environment and I am coming across linkage errors due to class loading issues?
Please do not hesitate to contact me if you need additional information. Thank you.
Regards,
Nikolaos Abatzis
New River Systems Corporation
1890 Preston White Drive, Suite 24linkage error
Reston, VA 20191
Re: Jena as OSGi bundle
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
The clerezza project to create a jena bundle is here:
https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/ext.com.hp.hpl.jena/
for tdb:
https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/ext.com.hp.hpl.jena.tdb/
compiled bundles can be found here:
https://repository.apache.org/content/repositories/snapshots/org/apache/clerezza/
Cheers,
reto
On Thu, Apr 7, 2011 at 3:31 AM, Paolo Castagna <
castagna.lists@googlemail.com> wrote:
> Hi Dave,
> not being an OSGi expert, this is what I've tried to do at the time in the
> Jena pom.xml file:
>
> <profile>
> <id>OSGi</id>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-jar-plugin</artifactId>
> <version>2.2</version>
> <configuration>
> <archive>
>
> <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
> </archive>
> </configuration>
> </plugin>
>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <extensions>true</extensions>
> <executions>
> <execution>
> <goals>
> <goal>manifest</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> </profile>
>
> However, as far as I remember, there wasn't a great deal of feedback about
> it.
>
> Ideally, if it is possible/easy to support people wanting to use Jena+ARQ
> via
> OSGi, why not?
>
> Paolo
>
>
> Dave Reynolds wrote:
>
>> Hi Nikolaos,
>>
>> Topical, I'm just in the middle of some experimental OSGi work which
>> involves Jena :)
>>
>> I'm not sure where the Paolo/Clerzza discussions are at but I've found
>> it easy to create a Jena bundle locally. Just create a separate pom.xml
>> file which pulls in jena+arq from maven and builds a single bundle (see
>> below) then
>> mvn package
>> will create a usable bundle in the ./target
>>
>> I've based this on the arq rather than jena artifact so as to get a
>> single bundle of jena including arq which matches the normal jena
>> packaging.
>>
>> The resulting bundle works for me in that I can write bundles which
>> create and output jena models using this with no glitches.
>>
>> What linkage problems did you find?
>>
>> Does the above approach solve them?
>>
>> I don't think there's any project agreement on whether to create a jena
>> bundle as part of the standard build process and if so how to do that
>> while still supporting the current packaging[*]. But I would be happy to
>> support a move in that direction.
>>
>> Dave
>>
>> [*] Given the problem of maven only allowing one packaging I wonder if
>> the easiest thing would be to invoke bnd during the assembly phase since
>> the maven bundle plugin is just a layer over bnd.
>>
>>
>> [[[ pom.xml ]]] <project xmlns="http://maven.apache.org/POM/4.0.0"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/xsd/maven-4.0.0.xsd">
>> <modelVersion>4.0.0</modelVersion>
>> <groupId>com.hp.hpl.jena</groupId>
>> <artifactId>jena-osgi</artifactId>
>> <version>2.6.4</version>
>> <name>Jena OSGi</name>
>> <description>OSGi bundling of Jena and its internal
>> dependencies.</description>
>>
>> <packaging>bundle</packaging>
>>
>> <repositories>
>> <!-- jena-repo is mirrored to Maven central repository -->
>> <!-- In case mirroring has not happened yet ... -->
>> <repository>
>> <id>repo-jena</id>
>> <name>Jena Maven - Repository</name>
>> <layout>default</layout>
>> <url>http://openjena.org/repo</url>
>> <snapshots>
>> <enabled>false</enabled>
>> </snapshots>
>> </repository>
>>
>> </repositories>
>>
>>
>> <dependencies>
>> <dependency>
>> <groupId>com.hp.hpl.jena</groupId>
>> <artifactId>arq</artifactId>
>> <version>2.8.7</version>
>> </dependency>
>> </dependencies>
>>
>> <build>
>> <plugins>
>> <plugin>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>maven-bundle-plugin</artifactId>
>> <extensions>true</extensions>
>> <configuration>
>> <instructions>
>> <!-- Defaults for name and symbolic name created by
>> bundle-plugin -->
>>
>> <Embed-Dependency>*;artifactId=!commons-logging</Embed-Dependency>
>> <Embed-Transitive>true</Embed-Transitive>
>> <Import-Package>
>> !org.apache.xml.resolver.*,!sun.*,
>>
>> !com.sun.jdmk.*,!com.sun.msv.*,!org.relaxng.*,
>>
>> !javax.jms.*,!javax.mail.*,!javax.swing.*,!javax.management,!javax.naming,
>> *</Import-Package>
>> <Export-Package>com.hp.hpl.jena.*,
>> org.apache.xerces.util</Export-Package>
>> </instructions>
>> </configuration>
>> </plugin>
>> </plugins>
>> </build>
>> </project>
>>
>> On Wed, 2011-04-06 at 09:49 -0700, Nikolaos Abatzis wrote:
>>
>>> All,
>>>
>>> I googled and found some email threads between Paolo and the folks at
>>> Clerezza regarding creating an OSGi bundle for Jena.
>>>
>>> Are there any news on this, as we are using Jena in an OSGi environment
>>> and I am coming across linkage errors due to class loading issues?
>>>
>>>
>>>
>>> Please do not hesitate to contact me if you need additional information.
>>> Thank you.
>>>
>>> Regards,
>>>
>>> Nikolaos Abatzis
>>> New River Systems Corporation
>>> 1890 Preston White Drive, Suite 24linkage error
>>> Reston, VA 20191
>>>
>>
>>
>>
>>
>
Re: Jena as OSGi bundle
Posted by Brian McBride <br...@epimorphics.com>.
Forgive me if I'm missing the point, but isn't what Andy suggests the
obvious solution?
Eventually, when in everything moves into Apache there will be a top
level Jena maven project with subprojects for Jena core, ARQ, TDB, SDB
etc. If there is a need to build a composite OSGI bundle, that will
just be another subproject, with its own POM that will have its
dependencies and build the bundle. I assume that Maven OSGI tools will
enable a composite bundle to be built from the dependent jars.
In the meantime, to build a composite OSGI bundle just create a separate
maven project for it. Then it has its own POM and it follows the Maven
discipline of one project, one artefact.
Brian
On 07/04/2011 15:33, Andy Seaborne wrote:
> "sometime" we should to have a separate "deliverables" module(s) to
> make various artifacts.
>
> (That's not to say there should be an intermediate addition to the
> current build system.)
>
> Andy
>
Re: Jena as OSGi bundle
Posted by Andy Seaborne <an...@epimorphics.com>.
On 07/04/11 15:39, Paolo Castagna wrote:
> Hi Andy,
> I am not sure I understand what you mean. Could you expand a little?
> Do you mean separate modules for Jena?
Separate modules for all of Jena - current jena, ARQ, TDB etc etc
Hopefully, when move Apache-wards, we can redo the build to make it more
suitable for all things we want to do: OGSi, download of Jena+ARQ,
download of Fuseki, .... and not split across separate projects.
Andy
>
> Paolo
>
> Andy Seaborne wrote:
>> "sometime" we should to have a separate "deliverables" module(s) to
>> make various artifacts.
>>
>> (That's not to say there should be an intermediate addition to the
>> current build system.)
>>
>> Andy
>>
Re: Jena as OSGi bundle
Posted by Paolo Castagna <ca...@googlemail.com>.
Hi Andy,
I am not sure I understand what you mean. Could you expand a little?
Do you mean separate modules for Jena?
Paolo
Andy Seaborne wrote:
> "sometime" we should to have a separate "deliverables" module(s) to make
> various artifacts.
>
> (That's not to say there should be an intermediate addition to the
> current build system.)
>
> Andy
>
Re: Jena as OSGi bundle
Posted by Andy Seaborne <an...@epimorphics.com>.
"sometime" we should to have a separate "deliverables" module(s) to make
various artifacts.
(That's not to say there should be an intermediate addition to the
current build system.)
Andy
RE: Jena as OSGi bundle
Posted by Nikolaos Abatzis <Ni...@newriversystems.com>.
All:
Did not mean to stirrup all this when I first asked the question :-(
Anyways we managed to "OSGify" Jena. If anybody is interested drop me an email and I can provide direction.
It was our resident OSGi expert that did it but I can provide explanation as best as I can, if needed. We did not address, as it was not one of our goals, the need to produce two jars from one set of source code.
As somebody already mentioned I would go for simplicity having only one set that contains the manifest entries for OSGi, thus making the jars readily compatible with OSGi, yet still usable outside of it. My 2 cents.
Please do not hesitate to contact me if you need additional information. Thank you.
Regards,
Nikolaos Abatzis
New River Systems Corporation
1890 Preston White Drive, Suite 240
Reston, VA 20191
________________________________________
From: Dave Reynolds [dave.e.reynolds@gmail.com]
Sent: Friday, April 08, 2011 5:39 AM
To: jena-users@incubator.apache.org
Subject: Re: Jena as OSGi bundle
This is getting rather off-topic for jena-users so I suggest taking it
elsewhere, however rather than leave a dangling set of questions here's
a brief response ...
On Fri, 2011-04-08 at 09:16 +0100, Ian Dickinson wrote:
> > It is perfectly possible to do what Paolo has already done and
> > include an OSGi manifest in the jena.jar. That is useful but not as
> > useful having a more self contained bundle.[*]
>
> Sorry, I must be missing something here. I thought that the point of
> OSGI was like maven and other dependency managers:
No, OSGi is not a dependency manager it's a module system for java.
Definitely shouldn't think of it as a weird maven, they are doing
different jobs.
In Java you end up in jar hell because all the contents of all the jars
is normally mixed up in a single namespace (i.e. classloader).
Maven et al solve this by helping you pick the jars you are going to put
in that global namespace.
OSGi (and to some extent other container approaches) solve this by
breaking up the global namespace. Encouraging you to write components
that expose compact service interfaces and hiding all the implementation
details of those components, allowing selective import/export of
packages. Then it adds the service layer machinery for how you can
advertise, discover link to, dynamically change, inspect, configure etc
those services.
So there's a choice about how much of the details (including things that
were implemented as other jars) you expose from a bundle. You could have
every bundle expose every package if you wanted to.
There's also a choice about how self-contained your bundles are. Some
projects provide both fine grain bundles and all-in-one bundling of
those bundles.
> that the dependencies
> are declarative so that (a) they can be auto-installed by the container,
> and (b) duplication can be avoided and conflicts resolved.
Better than that, conflicts are to some extent avoided in the first
place by allowing multiple versions to coexist and allowing components
to be selective in both import and export.
> Are you
> saying that in an OSGI container, you're still responsible for
> installing all the dependencies yourself?
Yes, for the basic containers. There are services which can help with
that "provisioning" (e.g. PAX runner) including some dependency support
(and support for provisioning plain jars and wars) but as a bundle
provider you probably don't want to force people to use those.
Dave
Re: Jena as OSGi bundle
Posted by Dave Reynolds <da...@gmail.com>.
This is getting rather off-topic for jena-users so I suggest taking it
elsewhere, however rather than leave a dangling set of questions here's
a brief response ...
On Fri, 2011-04-08 at 09:16 +0100, Ian Dickinson wrote:
> > It is perfectly possible to do what Paolo has already done and
> > include an OSGi manifest in the jena.jar. That is useful but not as
> > useful having a more self contained bundle.[*]
>
> Sorry, I must be missing something here. I thought that the point of
> OSGI was like maven and other dependency managers:
No, OSGi is not a dependency manager it's a module system for java.
Definitely shouldn't think of it as a weird maven, they are doing
different jobs.
In Java you end up in jar hell because all the contents of all the jars
is normally mixed up in a single namespace (i.e. classloader).
Maven et al solve this by helping you pick the jars you are going to put
in that global namespace.
OSGi (and to some extent other container approaches) solve this by
breaking up the global namespace. Encouraging you to write components
that expose compact service interfaces and hiding all the implementation
details of those components, allowing selective import/export of
packages. Then it adds the service layer machinery for how you can
advertise, discover link to, dynamically change, inspect, configure etc
those services.
So there's a choice about how much of the details (including things that
were implemented as other jars) you expose from a bundle. You could have
every bundle expose every package if you wanted to.
There's also a choice about how self-contained your bundles are. Some
projects provide both fine grain bundles and all-in-one bundling of
those bundles.
> that the dependencies
> are declarative so that (a) they can be auto-installed by the container,
> and (b) duplication can be avoided and conflicts resolved.
Better than that, conflicts are to some extent avoided in the first
place by allowing multiple versions to coexist and allowing components
to be selective in both import and export.
> Are you
> saying that in an OSGI container, you're still responsible for
> installing all the dependencies yourself?
Yes, for the basic containers. There are services which can help with
that "provisioning" (e.g. PAX runner) including some dependency support
(and support for provisioning plain jars and wars) but as a bundle
provider you probably don't want to force people to use those.
Dave
Re: Jena as OSGi bundle
Posted by Ian Dickinson <ia...@epimorphics.com>.
Hi Dave,
On 08/04/11 08:50, Dave Reynolds wrote:
> Thorsten wrote:
>> Anyway, is it really necessary to have an extra JAR with the OSGi
>> meta data (and one without)? As far as I can see, the set of
>> classes would not change in that extra JAR (would it?), only the
>> manifest.mf would be enriched by additional OSGi meta data. The
>> latter is unproblematic as non-OSGi environments would just ignore
>> it. Do I miss something?
>
> We are talking about having a (reasonably) self-contained
> jena-bundle which will include the most/all of the dependent jars
> that end up in the lib part of the jena distribution (i.e. icu4j,
> stax etc). That way you can just drop the jena-bundle into your
> container and you are all set.
>
> It is perfectly possible to do what Paolo has already done and
> include an OSGi manifest in the jena.jar. That is useful but not as
> useful having a more self contained bundle.[*]
Sorry, I must be missing something here. I thought that the point of
OSGI was like maven and other dependency managers: that the dependencies
are declarative so that (a) they can be auto-installed by the container,
and (b) duplication can be avoided and conflicts resolved. Are you
saying that in an OSGI container, you're still responsible for
installing all the dependencies yourself?
> [*] Caveat I've been working with OSGi for barely a week so I'm hardly
> an expert on it, though other projects seem to go a similar way.
And I have no experience at all, apart from the talk you gave at work!
Ian
--
____________________________________________________________
Ian Dickinson Epimorphics Ltd, Bristol, UK
mailto:ian@epimorphics.com http://www.epimorphics.com
cell: +44-7786-850536 landline: +44-1275-399069
------------------------------------------------------------
Epimorphics Ltd. is a limited company registered in England
(no. 7016688). Registered address: Court Lodge, 105 High St,
Portishead, Bristol BS20 6PT, UK
Re: Jena as OSGi bundle
Posted by Dave Reynolds <da...@gmail.com>.
On Fri, 2011-04-08 at 09:19 +0200, Thorsten Möller wrote:
> Though not directly related to the OSGi/no OSGi artifacts problem, but related to the general problem:
> http://www.sonatype.com/people/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/
Thanks, so that's basically Paolo's "use profiles" approach.
If that can be made to work with the felix bundle plugin then that would
be fine by me.
Though I'm not sure how huge a difference it makes to the build process.
With the separate-poms solution then you use "-f pom-osgi", with the
profiles solution you have use "-P profile-osgi" either way it is a
separate maven invocation creating a separate artifact. I guess the
profiles approach is less fragile when it comes to build order.
> Anyway, is it really necessary to have an extra JAR with the OSGi meta data (and one without)? As far as I can see, the set of classes would not change in that extra JAR (would it?), only the manifest.mf would be enriched by additional OSGi meta data. The latter is unproblematic as non-OSGi environments would just ignore it. Do I miss something?
We are talking about having a (reasonably) self-contained jena-bundle
which will include the most/all of the dependent jars that end up in the
lib part of the jena distribution (i.e. icu4j, stax etc). That way you
can just drop the jena-bundle into your container and you are all set.
It is perfectly possible to do what Paolo has already done and include
an OSGi manifest in the jena.jar. That is useful but not as useful
having a more self contained bundle.[*]
Dave
[*] Caveat I've been working with OSGi for barely a week so I'm hardly
an expert on it, though other projects seem to go a similar way.
> Am 08.04.2011 um 00:05 schrieb Dave Reynolds:
>
> > Hi Paolo,
> >
> > On Thu, 2011-04-07 at 15:24 +0100, Paolo Castagna wrote:
> >> Hi Dave,
> >> I am not sure profiles are a better option for OSGi bundles.
> >> That was what I used to try to build the OSGi bundle and keep it out of the way.
> >>
> >> "Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are
> >> meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing,
> >> and production environments). As such, profiles can easily lead to differing build results from different members of your team. However, used properly, profiles can be used while still preserving
> >> project portability. This will also minimize the use of -f option of maven which allows user to create another POM with different parameters or configuration to build which makes it more maintainable
> >> since it is runnning with one POM only."
> >> -- http://maven.apache.org/guides/introduction/introduction-to-profiles.html
> >>
> >> You activate a profile using the -P option
> >>
> >> mvn -P profile-1,profile-2 ...
> >
> > OK. Having looked at a little it seems that they can't change the
> > packaging, so the one-artifact-per-pom limitation remains.
> >
> >> Your idea about using assembly could be a better approach, if possible.
> >
> > I think it may be possible for Jena (because we don't have complex
> > recursive dependencies) but I haven't tried it for real yet and it looks
> > non-trivial.
> >
> >> Reto also pointed us at how Clerezza do this (I've not look at the details yet), we should look at it as well.
> >
> > It's a separate pom with packaging "bundle" using the felix
> > bundle-plugin, very similar to the pom I use and posted.
> >
> > Is that a possible solution for us? Just have a separate pom-osgi.xml
> > in the jena code base and invoke:
> >
> > mvn -f pom-osgi.xml package
> >
> > to do that part of a release build.
> >
> > I don't understand the current jena release process as well as I should,
> > so I'm not sure if building one more artifact that way would be a
> > serious complication or an acceptable approach.
> >
> > FWIW the best match I could find to this with Google is a question on
> > stackoverflow for which the first answer is the separate-pom approach:
> > http://stackoverflow.com/questions/4374275/maven-bundle-plugin-problem-osgi
> >
> > Dave
> >
> >
>
Re: Jena as OSGi bundle
Posted by Thorsten Möller <th...@unibas.ch>.
Though not directly related to the OSGi/no OSGi artifacts problem, but related to the general problem:
http://www.sonatype.com/people/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/
Anyway, is it really necessary to have an extra JAR with the OSGi meta data (and one without)? As far as I can see, the set of classes would not change in that extra JAR (would it?), only the manifest.mf would be enriched by additional OSGi meta data. The latter is unproblematic as non-OSGi environments would just ignore it. Do I miss something?
Thorsten
Am 08.04.2011 um 00:05 schrieb Dave Reynolds:
> Hi Paolo,
>
> On Thu, 2011-04-07 at 15:24 +0100, Paolo Castagna wrote:
>> Hi Dave,
>> I am not sure profiles are a better option for OSGi bundles.
>> That was what I used to try to build the OSGi bundle and keep it out of the way.
>>
>> "Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are
>> meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing,
>> and production environments). As such, profiles can easily lead to differing build results from different members of your team. However, used properly, profiles can be used while still preserving
>> project portability. This will also minimize the use of -f option of maven which allows user to create another POM with different parameters or configuration to build which makes it more maintainable
>> since it is runnning with one POM only."
>> -- http://maven.apache.org/guides/introduction/introduction-to-profiles.html
>>
>> You activate a profile using the -P option
>>
>> mvn -P profile-1,profile-2 ...
>
> OK. Having looked at a little it seems that they can't change the
> packaging, so the one-artifact-per-pom limitation remains.
>
>> Your idea about using assembly could be a better approach, if possible.
>
> I think it may be possible for Jena (because we don't have complex
> recursive dependencies) but I haven't tried it for real yet and it looks
> non-trivial.
>
>> Reto also pointed us at how Clerezza do this (I've not look at the details yet), we should look at it as well.
>
> It's a separate pom with packaging "bundle" using the felix
> bundle-plugin, very similar to the pom I use and posted.
>
> Is that a possible solution for us? Just have a separate pom-osgi.xml
> in the jena code base and invoke:
>
> mvn -f pom-osgi.xml package
>
> to do that part of a release build.
>
> I don't understand the current jena release process as well as I should,
> so I'm not sure if building one more artifact that way would be a
> serious complication or an acceptable approach.
>
> FWIW the best match I could find to this with Google is a question on
> stackoverflow for which the first answer is the separate-pom approach:
> http://stackoverflow.com/questions/4374275/maven-bundle-plugin-problem-osgi
>
> Dave
>
>
Re: Jena as OSGi bundle
Posted by Dave Reynolds <da...@gmail.com>.
Hi Paolo,
On Thu, 2011-04-07 at 15:24 +0100, Paolo Castagna wrote:
> Hi Dave,
> I am not sure profiles are a better option for OSGi bundles.
> That was what I used to try to build the OSGi bundle and keep it out of the way.
>
> "Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are
> meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing,
> and production environments). As such, profiles can easily lead to differing build results from different members of your team. However, used properly, profiles can be used while still preserving
> project portability. This will also minimize the use of -f option of maven which allows user to create another POM with different parameters or configuration to build which makes it more maintainable
> since it is runnning with one POM only."
> -- http://maven.apache.org/guides/introduction/introduction-to-profiles.html
>
> You activate a profile using the -P option
>
> mvn -P profile-1,profile-2 ...
OK. Having looked at a little it seems that they can't change the
packaging, so the one-artifact-per-pom limitation remains.
> Your idea about using assembly could be a better approach, if possible.
I think it may be possible for Jena (because we don't have complex
recursive dependencies) but I haven't tried it for real yet and it looks
non-trivial.
> Reto also pointed us at how Clerezza do this (I've not look at the details yet), we should look at it as well.
It's a separate pom with packaging "bundle" using the felix
bundle-plugin, very similar to the pom I use and posted.
Is that a possible solution for us? Just have a separate pom-osgi.xml
in the jena code base and invoke:
mvn -f pom-osgi.xml package
to do that part of a release build.
I don't understand the current jena release process as well as I should,
so I'm not sure if building one more artifact that way would be a
serious complication or an acceptable approach.
FWIW the best match I could find to this with Google is a question on
stackoverflow for which the first answer is the separate-pom approach:
http://stackoverflow.com/questions/4374275/maven-bundle-plugin-problem-osgi
Dave
Re: Jena as OSGi bundle
Posted by Paolo Castagna <ca...@googlemail.com>.
Hi Dave,
I am not sure profiles are a better option for OSGi bundles.
That was what I used to try to build the OSGi bundle and keep it out of the way.
"Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are
meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing,
and production environments). As such, profiles can easily lead to differing build results from different members of your team. However, used properly, profiles can be used while still preserving
project portability. This will also minimize the use of -f option of maven which allows user to create another POM with different parameters or configuration to build which makes it more maintainable
since it is runnning with one POM only."
-- http://maven.apache.org/guides/introduction/introduction-to-profiles.html
You activate a profile using the -P option
mvn -P profile-1,profile-2 ...
Your idea about using assembly could be a better approach, if possible.
Reto also pointed us at how Clerezza do this (I've not look at the details yet), we should look at it as well.
Paolo
Dave Reynolds wrote:
> Hi Paolo,
>
> On Thu, 2011-04-07 at 02:31 +0100, Paolo Castagna wrote:
>> Hi Dave,
>> not being an OSGi expert, this is what I've tried to do at the time in the Jena
>> pom.xml file:
>>
>> <profile>
>> <id>OSGi</id>
>> <build>
>> <plugins>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-jar-plugin</artifactId>
>> <version>2.2</version>
>> <configuration>
>> <archive>
>> <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
>> </archive>
>> </configuration>
>> </plugin>
>> <plugin>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>maven-bundle-plugin</artifactId>
>> <extensions>true</extensions>
>> <executions>
>> <execution>
>> <goals>
>> <goal>manifest</goal>
>> </goals>
>> </execution>
>> </executions>
>> </plugin>
>> </plugins>
>> </build>
>> </profile>
>>
>> However, as far as I remember, there wasn't a great deal of feedback about it.
>
> Not being a Maven person I don't understand what the profiles do or how
> to invoke them or how that integrates with the rest of the build
> process :)
>
> However, presumably it would only create a jena.jar with a default
> bundle manifest. I guess that's better than nothing but doesn't really
> help that much. Rather than have to load all the Jena dependent jars in
> as separate bundles it's more convenient to have a jena bundle that
> includes them (or at least the ones that aren't likely to already be
> present). Which is what the pom example I showed does, Clerezza's looks
> very similar.
>
> Dave
>
>
Re: Jena as OSGi bundle
Posted by Dave Reynolds <da...@gmail.com>.
Hi Paolo,
On Thu, 2011-04-07 at 02:31 +0100, Paolo Castagna wrote:
> Hi Dave,
> not being an OSGi expert, this is what I've tried to do at the time in the Jena
> pom.xml file:
>
> <profile>
> <id>OSGi</id>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-jar-plugin</artifactId>
> <version>2.2</version>
> <configuration>
> <archive>
> <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
> </archive>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <extensions>true</extensions>
> <executions>
> <execution>
> <goals>
> <goal>manifest</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> </profile>
>
> However, as far as I remember, there wasn't a great deal of feedback about it.
Not being a Maven person I don't understand what the profiles do or how
to invoke them or how that integrates with the rest of the build
process :)
However, presumably it would only create a jena.jar with a default
bundle manifest. I guess that's better than nothing but doesn't really
help that much. Rather than have to load all the Jena dependent jars in
as separate bundles it's more convenient to have a jena bundle that
includes them (or at least the ones that aren't likely to already be
present). Which is what the pom example I showed does, Clerezza's looks
very similar.
Dave
Re: Jena as OSGi bundle
Posted by Paolo Castagna <ca...@googlemail.com>.
Hi Dave,
not being an OSGi expert, this is what I've tried to do at the time in the Jena
pom.xml file:
<profile>
<id>OSGi</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.2</version>
<configuration>
<archive>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<executions>
<execution>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
However, as far as I remember, there wasn't a great deal of feedback about it.
Ideally, if it is possible/easy to support people wanting to use Jena+ARQ via
OSGi, why not?
Paolo
Dave Reynolds wrote:
> Hi Nikolaos,
>
> Topical, I'm just in the middle of some experimental OSGi work which
> involves Jena :)
>
> I'm not sure where the Paolo/Clerzza discussions are at but I've found
> it easy to create a Jena bundle locally. Just create a separate pom.xml
> file which pulls in jena+arq from maven and builds a single bundle (see
> below) then
> mvn package
> will create a usable bundle in the ./target
>
> I've based this on the arq rather than jena artifact so as to get a
> single bundle of jena including arq which matches the normal jena
> packaging.
>
> The resulting bundle works for me in that I can write bundles which
> create and output jena models using this with no glitches.
>
> What linkage problems did you find?
>
> Does the above approach solve them?
>
> I don't think there's any project agreement on whether to create a jena
> bundle as part of the standard build process and if so how to do that
> while still supporting the current packaging[*]. But I would be happy to
> support a move in that direction.
>
> Dave
>
> [*] Given the problem of maven only allowing one packaging I wonder if
> the easiest thing would be to invoke bnd during the assembly phase since
> the maven bundle plugin is just a layer over bnd.
>
>
> [[[ pom.xml ]]]
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.hp.hpl.jena</groupId>
> <artifactId>jena-osgi</artifactId>
> <version>2.6.4</version>
> <name>Jena OSGi</name>
> <description>OSGi bundling of Jena and its internal dependencies.</description>
>
> <packaging>bundle</packaging>
>
> <repositories>
> <!-- jena-repo is mirrored to Maven central repository -->
> <!-- In case mirroring has not happened yet ... -->
> <repository>
> <id>repo-jena</id>
> <name>Jena Maven - Repository</name>
> <layout>default</layout>
> <url>http://openjena.org/repo</url>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
>
> </repositories>
>
>
> <dependencies>
> <dependency>
> <groupId>com.hp.hpl.jena</groupId>
> <artifactId>arq</artifactId>
> <version>2.8.7</version>
> </dependency>
> </dependencies>
>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <extensions>true</extensions>
> <configuration>
> <instructions>
> <!-- Defaults for name and symbolic name created by bundle-plugin -->
>
> <Embed-Dependency>*;artifactId=!commons-logging</Embed-Dependency>
> <Embed-Transitive>true</Embed-Transitive>
> <Import-Package>
> !org.apache.xml.resolver.*,!sun.*,
> !com.sun.jdmk.*,!com.sun.msv.*,!org.relaxng.*,
> !javax.jms.*,!javax.mail.*,!javax.swing.*,!javax.management,!javax.naming,
> *</Import-Package>
> <Export-Package>com.hp.hpl.jena.*,
> org.apache.xerces.util</Export-Package>
> </instructions>
> </configuration>
> </plugin>
> </plugins>
> </build>
> </project>
>
> On Wed, 2011-04-06 at 09:49 -0700, Nikolaos Abatzis wrote:
>> All,
>>
>> I googled and found some email threads between Paolo and the folks at Clerezza regarding creating an OSGi bundle for Jena.
>>
>> Are there any news on this, as we are using Jena in an OSGi environment and I am coming across linkage errors due to class loading issues?
>>
>>
>>
>> Please do not hesitate to contact me if you need additional information. Thank you.
>>
>> Regards,
>>
>> Nikolaos Abatzis
>> New River Systems Corporation
>> 1890 Preston White Drive, Suite 24linkage error
>> Reston, VA 20191
>
>
>
Re: Jena as OSGi bundle
Posted by Dave Reynolds <da...@gmail.com>.
Hi Nikolaos,
Topical, I'm just in the middle of some experimental OSGi work which
involves Jena :)
I'm not sure where the Paolo/Clerzza discussions are at but I've found
it easy to create a Jena bundle locally. Just create a separate pom.xml
file which pulls in jena+arq from maven and builds a single bundle (see
below) then
mvn package
will create a usable bundle in the ./target
I've based this on the arq rather than jena artifact so as to get a
single bundle of jena including arq which matches the normal jena
packaging.
The resulting bundle works for me in that I can write bundles which
create and output jena models using this with no glitches.
What linkage problems did you find?
Does the above approach solve them?
I don't think there's any project agreement on whether to create a jena
bundle as part of the standard build process and if so how to do that
while still supporting the current packaging[*]. But I would be happy to
support a move in that direction.
Dave
[*] Given the problem of maven only allowing one packaging I wonder if
the easiest thing would be to invoke bnd during the assembly phase since
the maven bundle plugin is just a layer over bnd.
[[[ pom.xml ]]]
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.hp.hpl.jena</groupId>
<artifactId>jena-osgi</artifactId>
<version>2.6.4</version>
<name>Jena OSGi</name>
<description>OSGi bundling of Jena and its internal dependencies.</description>
<packaging>bundle</packaging>
<repositories>
<!-- jena-repo is mirrored to Maven central repository -->
<!-- In case mirroring has not happened yet ... -->
<repository>
<id>repo-jena</id>
<name>Jena Maven - Repository</name>
<layout>default</layout>
<url>http://openjena.org/repo</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>com.hp.hpl.jena</groupId>
<artifactId>arq</artifactId>
<version>2.8.7</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<!-- Defaults for name and symbolic name created by bundle-plugin -->
<Embed-Dependency>*;artifactId=!commons-logging</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>
<Import-Package>
!org.apache.xml.resolver.*,!sun.*,
!com.sun.jdmk.*,!com.sun.msv.*,!org.relaxng.*,
!javax.jms.*,!javax.mail.*,!javax.swing.*,!javax.management,!javax.naming,
*</Import-Package>
<Export-Package>com.hp.hpl.jena.*,
org.apache.xerces.util</Export-Package>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
</project>
On Wed, 2011-04-06 at 09:49 -0700, Nikolaos Abatzis wrote:
> All,
>
> I googled and found some email threads between Paolo and the folks at Clerezza regarding creating an OSGi bundle for Jena.
>
> Are there any news on this, as we are using Jena in an OSGi environment and I am coming across linkage errors due to class loading issues?
>
>
>
> Please do not hesitate to contact me if you need additional information. Thank you.
>
> Regards,
>
> Nikolaos Abatzis
> New River Systems Corporation
> 1890 Preston White Drive, Suite 24linkage error
> Reston, VA 20191