On 11/16/10 5:41, Marcel Offermans 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.
This is true, but I think the default was chosen to approximate normal
JAR file behavior.
* 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.
I agree that 1 and 2 are not good. The only reason I suggest 1 is
because it is because I think it makes more sense to be explicit that
you aren't versioning your packages, then to pretend that you are. If
you only want to use bundle versions, then OSGi already supports that at
the package level.
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.
None of this really matters, I guess. The point is, people can choose to
use OSGi that way and it cannot be prevented. So, the question really
just is, how easy should we make it for them to do? I would not like it
to be the default, but I don't care if we make it simpler to do if you
choose.
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.
Right. Our defaults should be best practices, but in this case we are
talking about coming up with a default version for a package and there
is no best practice for that.
-> richard
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
