cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Blocks and packages
Date Mon, 29 May 2006 18:27:44 GMT
Carsten Ziegeler skrev:
> 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.

No problem, I can understand your reaction as I have used harder words 
in similar situations some times before, not this time though :)


>>> 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.

Yes definitely. I think that the main issue from OSGi POV is that we 
have to get rid of split packages. As Ralph pointed out it is needed 
from documentation POV as well. And maybe from security POV as Niclas 
mentioned. Also having several modules/blocks/bundles contributing to 
the same package is fairly confusing when trying to follow the code.

It seem reasonable to deprecate such uses during 2.2 and remove in 3.

Further work on modularization will probably also lead to some limmited 
back incompatibilities. OTH when we have decreased the dependencies 
between different parts of Cocoon, it will be so much easier to innovate 
without affecting the rest of Cocoon. And to let classic and innovative 
Cocoon blocks living side by side in the same application.


>> 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.



View raw message