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 > http://www.osgi.org/blog/2006/04/please-tell-us-what-you-want-from-osgi.html). 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 > http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg01004.html 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. > Ok, I changed that. Thanks. > 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. Great. > >> 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 -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
