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 > > > > >
