Btw, what's the default behavior for bnd ? I guess that's the main point.
One problem with the current code is if you have any maven plugin
generating some code or use another language such as scala, those
classes won't be taken into account.
I agree having that in bnd would be better.
On Wed, Nov 17, 2010 at 10:17, Guillaume Nodet <gno...@gmail.com> wrote:
> 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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
