Matthias Wessendorf schrieb: > >> I'm also sceptical that it will be possible to create a "super stable >> API". Just look at what is in shared at the moment! And in addition to >> the API, the *implementation* will also need to be super-stable. For >> example, if a Tomahawk issue (whether bug or new feature) needs changes >> in the "commons" module to resolve, then deploying that commons change >> will immediately impact myfaces-core too. Suddenly people will be >> > +1 that's a side effect > > >> running a version of myfaces-core together with a commons version that >> it was never tested against. I don't like that idea at all. It was >> precisely this issue that the shared repackaging idea was invented for. >> > yup, I guess I now move to your direction, or... > base-tomahawk :-) but... that doesn't fly at all. >
I guess what we really want is for servlet engines to explicitly permit OSGi use. Then myfaces-core can depend on version X of the "common" lib, while tomahawk can run in the same webapp using version Y. That would solve my major objection. Package-renaming is just a hack to get a similar effect without having to mess with classloaders. But with this setup, we would still have people complaining that they do not know where to put their breakpoints. In fact, it's even worse. At least with the current stuff, you can clearly see "o.a.m.shared_core.Foo", rather than dealing with two different concurrently-loaded versions of the "o.a.m.Foo" class. How do people interactively debug OSGi apps, I wonder.. Regards, Simon
