2009/7/25 Zac Thompson <[email protected]> > I'm still wrapping my head around OSGi in general, but when it comes > to delivering the bundles there seem to be a number of options around. > > The Maven cookbook suggests the pax plugin from OPS4j: > http://www.ops4j.org/projects/pax/construct/maven-pax-plugin/ > > Felix has the maven-bundle-plugin: > http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html >
FYI, the pax plugin helps you create and manage simple OSGi projects (creates "best practice" poms and example code, handles deployment) the poms it creates actually use the bundle plugin to build the bundles Is there an emerging standard for this? there are two main approaches for building OSGi bundles: pom-first (such as the bundle plugin) ... the pom drives the build manifest-first (for example Eclipse/PDE) ... the manifest drives the build there are ongoing efforts to consolidate the various efforts and define a set of recommended processes for building OSGi bundles, but things are still in the requirements gathering / early prototyping stage... http://www.osgi.org/Event/20090327 see also http://docs.codehaus.org/display/M2ECLIPSE/Tycho+project+overview Will the maven project > eventually maintain a plugin for osgi packaging (if that's even an > appropriate term here, would it be more of a classifier)? Or is it > too early in the OSGi game to ask that question? > if you want to follow an OSGi specific build process then packaging is the right term - but you could also put the OSGi headers in a text file alongside the project artifact, using a classifier (you'd then need an adapter to combine the main artifact and OSGi headers together so you could install it into the framework, but this is straightforward and it could even be done in memory at deploy time) so yes, wrt. tooling and processes, things are still in a state of flux We are considering dm Server, which seems to like the PAR format, but > SpringSource's plugin for it: > > > http://static.springsource.com/projects/dm-server/1.0.x/getting-started/html/ch07s04.html > http://blog.springsource.com/2009/06/24/maven-par-plugin-100m1/ > > ... seems to overlap (group and artifact! > org.apache.maven.plugins:maven-par-plugin) with: > > > http://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-par-plugin/ > > which makes me nervous, since I *think* that is a completely different > PAR format. Was SpringSource just on crack when they used that > groupId? I would have expected them to use > com.springsource.something. me too - it may be they used the core groupId by mistake or because using this id means they can omit the groupId when using the plugin on the command line? (not a good reason to just go ahead and use it) Are they working with the Maven project > on this? > > The Maven POM reference says "The current core packaging values are: > pom, jar, maven-plugin, ejb, war, ear, rar, par." Which "par" is this > referring to? I assume the old one. And yet where's the plugin for > it? Is that *not* a core packaging value? > looking at the source, that's a different PAR format (for persistence) see also http://jira.codehaus.org/browse/MNG-699 - not sure what's the current status of the persistence related maven-par-plugin, but it would clash if it was eventually promoted > http://maven.apache.org/pom.html > > Sigh. Any insight would be appreciated. > hope things are a bit clearer now > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Stuart
