cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Blocks and packages
Date Mon, 29 May 2006 08:21:16 GMT
Daniel Fagerstrom wrote:
> I'm sorry if you felt attacked, I had no intension to attack you or 
> anyone else. There was a problem that needed to be solved so that I 
> could continue to work.
Ok, perhaps I overreacted a little bit. Sorry for that.

> Of course I could have solved it without asking
> at the list first. But as it involved changing packages on classes that 
> might be part of our contract and reverting some of your recent changes 
> I thought it was much better to ask on the list first so that we could 
> find a solution that take all needs into account.
Yes, sure - that was the right thing to do. Perhaps it was bad wording
or misunderstanding from my side. Whatever it was, it's hopefully gone
now with no hard feelings left.

> I hope I have not said that, in any case it is close to false (see the 
> third paragraph in 
Hmm, I thought you had - but nevermind perhaps it's my weak memory or it
was just a my wishful thinking.

> There is some complicated workaround that can be used (see 
> and the 
> rest of that thread), but I think it adds other problems, so I think we 
> should avoid split packages.
Yes, I think you're right.

> Might be, but o.a.c.classloader is needed in cocoon-core, so I cannot 
> just ignore cocoon-bootstrap. 
A damn, yes, you're right of course.

> From your explanation it makes sense to
> have it as a separate jar. For the time being it seems simplest to make 
> it a separate bundle as well.

> Ok, I changed that.

> The WildCardHelper is used outside the matchers, so it made sense to 
> move it to util. I moved it back to util in core and kept a copy in 
> bootstrap.

>> I really think that these package name restrictions of OSGi bundles will
>> lead to problems in the long run for us.
> I'm certain that it will. Modularization is not for free, OTH having a 
> huge monolith is even more expensive.
Yes, sure - the only real problem I see is compatibility; of course
compatibility should not hinders us from inovations, so we have to find
the right balance here.

> As long as you don't want to contribute classes to a single package from 
> several modules, it will be fine.
Ah, ok, good.

>> I currently don't know if each module will be an own
>> bundle or not and how this will work in OSGi;
> I would suggest that each module produce a bundle, everything else seem 
> complicated. The idea with modules IIRC is that they produce exactly one 
> artifact.
Yes, I guess making an own bundle of each module is the easiest and
straightforward way; let's see where it leads us.

> Sure, that would be nice ;) But I have never seen any framework that 
> doesn't impose any restrictions whatsoever. And currently OSGi is the 
> main modularization framework in Java and considering the development 
> pace in the Eclipse community and elsewhere the restrictions seem to 
> support development rather than hinder it.
Hmm, yes, that's true - it's seems that OSGi is the right choice for
these tasks.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message