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.
Great!
/Daniel
