{local-packages} looks good to me.
I'll try to add that asap.
On Tue, Nov 16, 2010 at 12:30, Stuart McCulloch <mccu...@gmail.com> wrote:
> 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
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
