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.kri...@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 <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
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
