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 <fmesc...@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
