On 16 November 2010 11:07, Guillaume Nodet <gno...@gmail.com> wrote:
> 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,
>
yes, once the local set of packages is available in a property then you
could always use:
<Export-Package>{local-packages};version="${project.version}"</Export-Package>
although the code to expand {local-packages} in the plugin would need to be
intelligent
enough to add all the attached attributes to each clause in the expanded
package list
PS. using {local-packages} is imho a more descriptive name than just {local}
--
Cheers, Stuart
> 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
>
