On 11/16/10 7:49, Felix Meschberger 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
Yes and no. It is actually only useful to import your exported API
packages, which typically mean specification packages. If some package
implements some utility library, then importing your own exports is not
necessary. If you always import every exported package, then library
bundles often get shadowed in favor of already resolved providers and
then you end up not being able to use the underlying shadowed version at
all, which was not the intent.
I would say that always importing all exports is not much better than
never importing your own exports. There is no easy single rule here. You
have to ask, "Is it possible that this package could be provided by
someone else and could my bundle use it from a different provider?"
Importing your own exports was purely intended for including service
specification packages with your bundle implementing the service
specification.
-> richard
* 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)
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.
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 ?
