Op 26 apr 2011, om 16:41 heeft Martin Grigorov het volgende geschreven:
>> [..] >> Wicket bundles are some sort of raw jars+metadata that can be assemled in a >> custom way to become a usable OSGI bundle. Whatever you consider the >> uber-jar solution to go good or not, this is a flaw. >> > Wicket is not OSGi complaint and it has never been built with OSGi in mind. > You and Eike are the only users of OSGi that I know by name. If you don't know them, that doesn't mean they don't exist :-) We're also using OSGI with Wicket. We've made some changes to fix class loading issues and we use all the Wicket jars separately, with a generated manifest that explicitly imports and exports the right packages. We still have to get around to clean up our changes and try to get them committed. One of my 'OSGI expert' colleagues wrote the stuff. > >> I agree that you have to use -util -request and -core to make wicket work, >> but so, if they are so coupled, why to make different bundles at all? >> Alexandros already asked for this.You say modularization helps wicket >> developer.I would agree but what is the difference between the .request and >> .util package in -request, -util and in -core? >> >> As Martin pointed out, there are no more implementation of wicket, to date. >> So the -core is not a specific implementation of -request and -util. Maybe >> just more concret classes? >> >> Again I think that the package that span across different modules is a >> flawed design. For sure it is not OSGi-compliant. >> >> I do not want to bother more, anyway. I'll go for the uber-jar with wicket >> 1.5. I'll open an issue to fix this flaw so maybe wicket 1.6 will work out >> of the box in OSGi. It would be a nice step forward to not have packages split across different Wicket jars. Some OSGI containers trip over this. > See my concerns related to Portlets in my previous mail. If there are > just a few OSGi users out there and none of the core developers uses > OSGi then the "support" for OSGi can and will break at any time in the > future. Not doing anything now because it can break in the future is not a really good argument..? Anything can break, that's why there are unit tests, release candidates, etcetera. With some small design improvements (no split packages, 'better' jar(s)) and a better manifest the 'Wicket OSGI support' will surpass many other frameworks or libraries. BTW: to all the Wicket people: keep up the good work! Regards, Daan --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
