Re: maven - building OSGi components? also - PAR files?

[Stuart McCulloch <mc...@gmail.com>]

2009/7/25 Zac Thompson <za...@gmail.com>

> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
-- 
Cheers, Stuart