felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [DISCUSS] Default osgi manifest for maven-bundle-plugin
Date Wed, 17 Nov 2010 09:17:35 GMT
It's not really a deviation, because the {local-packages} was already
computed and used as the default for bnd.  So I guess things were not
portable already.   I don't recall what the behavior of bnd is when
not <Export-Package> is provided, but it has to be different from the
maven-bundle-plugin already.
Note that the maven-bundle-plugin also compute resources and
dependencies ... not sure how to do that without knowledge of the
maven project itself.

On Wed, Nov 17, 2010 at 09:25, Peter Kriens <peter.kriens@aqute.biz> wrote:
> 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

Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA

View raw message