felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <peter.kri...@aqute.biz>
Subject Re: [DISCUSS] Default osgi manifest for maven-bundle-plugin
Date Wed, 17 Nov 2010 08:25:58 GMT
I understand you've already submitted a patch for {local-packages}. You really think it is
a good idea to start deviating the bnd syntax/capabilities from the bnd syntax? I am not comfortable
creating features in the maven plugin that are not in bnd. Bnd is used in ant, eclipse, IntelliJ,
sb4t and many other places. Having a single syntax for those requirements make things easier
to move.

Kind regards,

	Peter Kriens

On 16 nov 2010, at 14:08, Guillaume Nodet wrote:

> On Tue, Nov 16, 2010 at 13:49, Felix Meschberger <fmeschbe@gmail.com> wrote:
>> Hi,
>> Having defaults is good, but ...
>> * AFAICT we already have defaults for Export-Package and
>> Private-Package, at least in the maven bundle plugin
>> * Export package versioning seems to be controversial where the current
>> default (none unless it can be derived from configuration or package
>> version files or @Export annotation) seems to be a minimal consensus.
>> Changing this to default to the bundle version instead is nothing I
>> could agree with (and I learned this the hard way over the course of the
>> last two years ;-) ).
>> * Importing one's own exports is AFAICT OSGi good practice and IMHO
>> should be kept as the default
> I've also learned the hard way that importing the package you export
> usually does not make sense.  That's really only the case when you
> actually have an API package and the implementation in the same
> bundle.   Existing non-osgi aware projects rarely use that afaik, as
> the api is usually packaged in a separate jar or there's no real api
> at all (think about commons-io for example).
>> * Having different behaviour for Import-Package version range generation
>> depending on how a bundle is built (multi- vs. single-module) sounds
>> like not so good an idea (I hate non-deterministic builds and the
>> consequences thereof)
> I badly explained my thoughts here.
> What I mean is when you import packages from the same 'project' (not
> bundle), you usually want a tighter version range.
> So that's specified using something like:
>     org.apache.abdera.*;version="[$(version;===;${abdera.osgi.version.clean}),$(version;==+;${abdera.osgi.version.clean}))",
>     *;version="[$(version;==;${abdera.osgi.version.clean}),$(version;=+;${abdera.osgi.version.clean}))"
>> Nevertheless: having properties to simplify some configuration (like the
>> proposed {local-packages} to easily set export version) or a switch to
>> disable importing one's own exports (doesn't this exist already?) sounds
>> reasonable.
>> Maybe the {local-packages} can even be extended to:
>>  {local-packages} -- all packages in the project
>>  {local-default-export-packages} -- all packages in the project
>>        exported by default (that would be all packages not having
>>        internal or impl in the name)
>>  {local-default-private-packages} -- all packages in the project
>>        not exported by default (that would be all packages having
>>        internal or impl in the name)
>> I understand, that it would be nice to have some default setup for
>> wrapping existing libraries (which is what you want to do for the Axis
>> libraries, IIUIC). But this should be configured in a special
>> configuration (e.g. the Axis parent POM in your case) and not in the
>> Maven Bundle Plugin.
>> For the Bundle Plugin defaults we should IMHO adhere to OSGi good
>> practice.
> Usually, best practices need some refactoring, which is out of scope
> for what I have in mind.
> I'll add the {local-packages} at first, and see if I can come up with
> some kind of profiles (if it's needed at all) to change the defaults.
>> Regards
>> Felix
>> Am Dienstag, den 16.11.2010, 10:07 +0100 schrieb Guillaume Nodet:
>>> I'd like to improve the maven bundle plugin to make it very easy to
>>> actually create good bundles for people that have had limited exposure
>>> to OSGi.
>>> I think in such cases, we should have something like the following:
>>>    * export all the packages from the src/main/java (this is done by
>>> default by the plugin if nothing is specified, but there's no way to
>>> add things without having to list all the packages again)
>>>    * use the pom version for the version of the exported packages
>>>    * do not import exported packages by default (most of the projects
>>> i've worked with do not use api + impl in the same bundle)
>>>    * use default version ranges for third party libraries
>>>    * use a stricter version range for packages imported from the same
>>> build (i.e. if you have two bundles build in the same build, they will
>>> import packages using a stricter version range)
>>> Before you try to shoot me down, I do understand this is not the best
>>> way to create bundles, and ideally, the version of the packages would
>>> be different than the overall version of the system, but I think a lot
>>> of projects aren't prepared to have OSGi have such a big impact on
>>> their code (as OSGi is for them a side thing).   So for those, I'd
>>> still like to have a set of defaults that works better than the
>>> current default (which has no version on the packages, does not use
>>> version ranges, etc...).
>>> I'm not sure how to do that yet, maybe having a simple option that
>>> activate different profiles if people think this should not be the
>>> overall defaults.  I haven't given much thoughts about the technical
>>> aspect yet, but I do think we should make it easier to package OSGi
>>> bundles.
>>> Also maybe a different profile to package an existing jar into a
>>> bundle more easily would be good too.
>>> THoughts ?
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com

View raw message