half here, half in felix-dev
I have made some improvements to Felix bundle plugin for manifest
generation that you can see here
https://issues.apache.org/jira/browse/FELIX-199
once that it's applied and hopefully released we'll give a try with
our own maven artifacts
On 3/28/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
On 3/28/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> I'm working with the Felix guys to go through all these issues. As
> usual Maven would provide a default manifest that you could override
> with configuration in your pom.
Where is this conversation happening? I'd like to hear more about the details.
-Nathan
>
> On 3/28/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> > On 3/28/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> > >
> > > We're just trying to help out the OSGi folks so that they aren't
> > > repackaging everything which is what they are doing. It's basically
> > > doing the minimum work so that JARs produced will function with OSGi
> > > containers. If it has no impact on normal users there's no real harm
> > > in trying to help. I just don't want Maven used as a vehicle to push
> > > OSGi down people's throats.
> > >
> > > Jason.
> >
> > I must concur with Jason's note of caution. Be very careful in this
> > realm. You can't just arbitrarily add OSGi entries to a manifest of
> > every build. OSGi entries must be defined very carefully, as they are
> > deployment descriptors and can have a significant impact on how a
> > bundle is consumed. There are many factors to take into consideration.
> >
> > For example, there are multiple ways to declare dependencies, you can
> > declare a dependency on a bundle, by name and you can declare a
> > dependency on a Java package, which abstracts you from a particular
> > packaging. Additionally, each dependency can be optional, meaning the
> > bundle can be started, even if that dependency isn't available. The
> > dependencies can be version-specific too, so a bundle can require a
> > specific version of a bundle or specific version of a Java package.
> > Note, though OSGi versions are similar to Maven2 versions, there are
> > some major conflicts, such as the interpretation of qualifiers.
> >
> > Once OSGi information is added to a JAR to make it a proper OSGi
> > bundle, those values make an API contract that must be strictly
> > adhered to.
> >
> > It's my opinion that OSGi enablement must be taken on by
> > component/project owners. I think that the only part the Maven
> > community should play here is adding OSGi support and making it easy.
> > The only other consideration might be to consider how Maven2 might be
> > OSGi hosted, but I'd be very surprised if this turned out as simple as
> > all Maven JARs adding "standard" manifest attributes.
> >
> > -Nathan Beyer
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
