I'll reiterate the goal I had in mind here.
The goal is to make an existing non-osgi project produce the best
possible osgi bundles instead of jars without any change in the
packaging or the versioning of the jars themselves (as those will
still be used in non-osgi environement). I'm just in the process of
doing that once again for another project (abdera). So anything that
require changing the code is ruled out at this point, so things like
cleanly separating the api from the implementation is not a
possibility here.
The goal is to make the project being able to be consumed in OSGi.
Additional refactoring could be done after that to start following
best practices, but that's not my point. So that's really my goal:
do not touch a single line of code and make things easy for people to
use, this means the maven bundle plugin should mostly figure out
everything using defaults.
Actually, I think the {local} thing should be sufficient as I could
specifiy the defaults I want in the root pom and have it inherited,
but then, those defaults could be available using a single maven
bundle switch to help people. That would mean turning plain jars into
(not completely screwed) osgi bundles would require mostly no osgi
knowledge and only adding a snippet of code in the root pom and change
the packaging to bundle (even maybe that's not required).
That's really my goal, help non-osgi aware projects produce osgi
bundles to avoid having to repackage all the jars as we do in
servicemix or as spring-source does.
That said, comments below...
On Tue, Nov 16, 2010 at 11:41, Marcel Offermans
<marcel.offerm...@luminis.nl> wrote:
> Hello Guillaume,
>
> On 16 Nov 2010, at 10:47 , Guillaume Nodet wrote:
>> On Tue, Nov 16, 2010 at 10:22, Richard S. Hall <he...@ungoverned.org> wrote:
>>> On 11/16/10 4:07, Guillaume Nodet wrote:
>>>>
>>>> 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)
>>>
>>> Not sure what you are proposing here, since it already is the default as you
>>> mention. Are you proposing some sort of macro to specify "export all" ?
>
> Actually I think it is a really horrible default to export all packages in a
> bundle, as it does not promote modularity at all: if all your bundles simply
> export all their packages, then what did you gain by using OSGi at all? Very
> little.
As I said, you gain the ability to use that project in an osgi
environment, that's already a lot.
>
>>>> * use the pom version for the version of the exported packages
>>>
>>> I don't think this is a good idea. You might as well just set them all to
>>> 0.0.0, since it is about as meaningful. The bundle-version attribute is
>>> already added implicitly, so if someone wants to use the bundle version they
>>> already can.
>>
>> I disagree. A version that never chagnes is not really a version. At
>> least, if you put the bundle version, you can use version ranges and
>> make sure you have some idea about what you're importing. Most of the
>> projects i've seen, or all the re-packaged jars, use the bundle
>> version as the package version, so, even if it's not the best way of
>> doing versioning, that's something that people use and which is much
>> better than nothing at all. I think we should support them if they
>> want to use that.
>
> So this is really about how to do versioning packages, and basically there
> are three ways to do it:
>
> 1) never bump the version automatically, so you'll stay at 0.0.0
> 2) always bump the version, regardless of any real changes
> 3) properly version, only bumping the appropriate part of the version when a
> change is made
>
> I would strongly advise against both 1 and 2, as neither makes much sense to
> me. Option 1 is obvious, if you do not version your packages and start doing
> updates of bundles, any non-compatible change in any package will probably
> break your deployment. Option 2 just means that you are very close to doing
> monolithic deployments, because if a bundle A gets a new version, and other
> bundles depend on a package of A, they all need a new version as well. This
> effect will pretty soon ripple through the whole system. That leaves option
> 3, which is more work but the only way to go if you really care about
> modularity and updating only parts of your application at runtime.
The thing is the bundle-version is hardly used at all. And yeah,
option 2 is close to monolithic deployment, when that's not really a
problem. A workaround is what i tried to explain earlier: use a
stricter version range for the import package within such a
deployment. That allows deploying bug fix bundles.
Again, it's not best practices, but that's something that non osgi
people can deal with easily.
>
>> Actually, I think sling is the only project i've seen where the
>> package version is not the bundle version, not to say, that everyone's
>> right, but that's the way people use it now, and in all the projects
>> i've seen, people are not osgi experts and they do not necessarily
>> want to spend much time on it, so having to specify a different
>> version for each package is not something they'll do.
>
> I think we might work in different types of projects. All projects I have
> done did explicitly choose OSGi because of its benefits, and they make an
> effort to properly use it. Of course all of this does not come for free, but
> I am wondering if the projects you're involved in really care about the
> benefits that OSGi brings. If not, why is it being used at all?
>
> Yes, properly versioning packages and bundles is not the easiest thing in the
> world, but it's a crucial part of designing modular applications. Tooling can
> help (both Eclipse and BndTools already support bytecode analysis tools that
> help you decide what has changed and what consequences those changes have for
> your package and bundle versions) but in the end, both exporting and
> versioning are things you design and that have semantics and will therefore
> always need some human involvement.
That's exactly my point. Most of the projects i've been involved in
are not OSGi centric, meaning the team there don't know much about
OSGi. They need something that's easy to use and maintain (meaning
mostly no maintenance). So it's just here about enabling downstream
users to use the project in osgi.
Over time, osgi things can kick in and refactoring can be done in
major versions, but that's a slow process.
>
>>>> 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.
>>>
>>> I agree that we should generate better bundles by default. The new bnd helps
>>> in some cases. I think the most controversial aspect is the default package
>>> version, which I'd argue against.
>>
>> Then, we should let the user decide and have an easy option to turn
>> that the way the user want. I'm talking here about making users life
>> easier, not enforcing best practices.
>
> Maybe that's what this whole discussion is about: do we promote best
> practices?
>
> You are advocating not to promote them, but instead make versioning as easy
> as possible. The downside is that you end up with a set of bundles that is
> tightly coupled and not particularly well designed. Of course the
> requirements of particular projects will dictate if this is a problem or not,
> but since Felix is an OSGi implementation we should definitely promote best
> practices.
>
> If users want to use different settings for their projects, I'm sure it's not
> hard to do, as defaults can always be overridden with other defaults. To
> deviate from best practices then becomes a conscious choice, which sounds a
> lot better than the other way round.
Again, it would be easy to document that those are not best practices,
but a simple way to have usable osgi bundles. That's why I proposed
having maybe some kind of profile in the maven bundle plugin to have a
different set of defaults that could suit that needs.
>> The problems comes from the fact that the bundle plugin has no simple
>> way to specify defaults.
>
> That is a valid point, one should be able to override the built-in defaults.
>
> Greetings, Marcel
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
