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