ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <>
Subject Re: Status Mavenization of ACE
Date Mon, 14 Dec 2009 07:26:02 GMT
Good morning guys,
(comments inlined)

On Sat, Dec 12, 2009 at 9:53 PM, Marcel Offermans <> wrote:

> Hello Brian,
> On Dec 12, 2009, at 17:35 , Brian Topping wrote:
> > As a pattern, I see that you've put an osgi.bnd in every build.  My past
> experience was to avoid this file and have the bundle plugin work from
> scratch.  It can be more work that way, but I liked that the manifest
> instructions were completely contained in the POM.  Any thoughts there?
> We had the same decision to make for the Ant build (where we could have
> gone with .bnd files for every bundle). There we decided to keep the data in
> one place as much as possible, so I agree that having one location makes
> sense.
> Toni, was there a special reason not to put everything in the POM? If not I
> would like to work towards putting everything in there.
Well, in the end its a perspective thing. I am very used to have extra
osgi.bnd files for bundle projects in OPS4J Projects as well as commercial
In the end the pros are
- see immediately a project is a bundle right from filesystem tree
- touching osgi bnd (in commit mails) indicates some osgi related "change"
(in most cases)
- don't deal with XML when you don't have to. That way, bnd directives are
not nested into deep xml hierarchies anymore.
Anyone who dealt with bnd knows, the devil is in detail. XML obscures that
(too me..)

On the other hand, the only benefit in putting it right into the pom is what
you guys mentioned, a single source.
But in times of nicely inherited poms this is not true anymore anyway:
versions and scopes are inherited, most things are variables.
So i suspect you change the pom - once its right - in very rare cases.
Putting the only "playable" figure (bnd settings) out makes things more
clear to me. (SoC).

My vote would be +1 for extra file, but don't mind if the majority wants a
single pom. Can also understand that position.


> Greetings, Marcel

Toni Menzel
Independent Software Developer
Professional Profile:     - New Energy for OSS Communities - Open
Participation Software.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message