Did you compiled from trunk ? or just the activation spec tree ?
You need a recent version of the parent pom which declares the bundle
maven plugin.

On 9/24/07, Rick McGuire <[EMAIL PROTECTED]> wrote:
> I'm getting an error trying to build the javamail specs now, which
> appears related to the OSGI changes:
>
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Cannot find lifecycle mapping for packaging: 'bundle'.
> Component descriptor cannot be found in the component repository:
> org.apache.mav
> en.lifecycle.mapping.LifecycleMappingbundle.
> [INFO]
> ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 1 second
> [INFO] Finished at: Mon Sep 24 05:47:05 EDT 2007
> [INFO] Final Memory: 4M/254M
> [INFO]
> ------------------------------------------------------------------------
>
>
> Rick
>
>
> Guillaume Nodet wrote:
> > Yeah, good point.
> > I've managed to somehow include both versions in the manifest.
> > The specification version (javamail 1.4) goes into the package version
> > for OSGi, whereas the maven version (1.2-SNAPSHOT) goes into the
> > Bundle-Version manifest entry.
> > I suppose this is the right way to deal with that, but the OSGi expert
> > may be able to confirm that.
> >
> > On 9/21/07, Rick McGuire <[EMAIL PROTECTED]> wrote:
> >
> >> For the specs, there are generally 2 version identifiers.  The first
> >> level is the implementation level the spec is supposed to be at.  For
> >> example, javamail 1.4 or javamail 1.3.1.  The second is the Geronimo
> >> release version of that specification.  For example, the javamail 1.4
> >> spec in trunk is currently at the 1.2-SNAPSHOT level.  Does the
> >> OSGIfication of these specs need to capture both levels?
> >>
> >> Also, for the javamail spec, there's a separate subtree for the Provider
> >> implementation, which also includes an uber jar that bundles the
> >> provider and spec classes in one jar file.  I suspect these should also
> >> have OSGI bundles too.  The SVN tree for these packages can be found here:
> >>
> >>     https://svn.apache.org/repos/asf/geronimo/javamail
> >>
> >> Rick
> >>
> >> Guillaume Nodet wrote:
> >>
> >>> So I've just commited a patch for everybody to review.
> >>> I have tested some of the bundles inside servicemix 4.0, so at least
> >>> i'm confident it won't break servicemix ;-)
> >>> Seriously, they seem to be ok, though i had to limit the exported
> >>> package from stax-api to javax.xml.stream* to not clash with other
> >>> packages from the system bundle (I suppose this is the reason).
> >>> See http://svn.apache.org/repos/asf/geronimo/specs/trunk/
> >>>
> >>> On 9/21/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>> For ServiceMix 4.0, which will be based on OSGi, I will need to have
> >>>> OSGified versions of some of the spec jars that geronimo provides.
> >>>> It's quite easy to do in ServiceMix (see
> >>>> http://svn.apache.org/repos/asf/incubator/servicemix/branches/servicemix-4.0/bundles/
> >>>> for servlet, j2ee-management, jms mainly), but I think it would be
> >>>> more useful for other projects if the specs jars were bundles
> >>>> themselves.
> >>>>
> >>>> This is quite a simple process that can be done incrementally without
> >>>> any real side effect and low risk of regression.  So unless someone
> >>>> objects, I'd like to start working on that.
> >>>>
> >>>> --
> >>>> Cheers,
> >>>> Guillaume Nodet
> >>>> ------------------------
> >>>> Blog: http://gnodet.blogspot.com/
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
> >
>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

Reply via email to