Hi Daniele, On [Tue, 26.04.2011 12:19], Daniele Dellafiore wrote: > On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner <[email protected]> wrote: > > > the "uber-jar" is only concerning wicket, not any war bundle. while it > > would be of course "nicer" to have all wicket jars as separate bundles > > available out of the box. but one solution I find quite ok is creating > > one bundle out of core, request and util. this will then be a uber-jar > > that brings wicket into the osgi mix. It's just containing the core > > packages of wicket. > > > > I think the different jars help the wicket developers to cleaner > > dependencies (when creating a class the dependencies make you think > > about where to put it, so you don't create a RequestClass in the core > > package/module, for example) -- please correct me if this is wrong. > > > > But from the client or user point of view, the jars wicket-core,util and > > request are all kind of core modules. You'll need them all (I think) to > > use wicket. this makes it in my opinion ok to use the one big wicket > > jar. all others (auth-roles etc) are still separate bundles. > > > > regards > > Eike > > > > This is not as bad as having to package the uber-jar with the war, sure. > Better than keeping a separate wicket codebase, at least :) > > Anyway it's still a custom solution that I, and all wicket developers, have > to do. More over, they have to discover that this has to be done, that > wicket bundles are working bundles, but not usable. > 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.
I totally agree with you. Wicket is such a great web framework and people who like to use it with osgi shouldn't have a hard time to get both workgin together. The fact that the three wicket modules have osgi related meta data but don't work as osgi bundles is really confusing. So a distributed uber-jar would be a quick fix for that. People can easily deploy wicket to an osgi container. > 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. Again I agree with you. The uber jar is good to get wicket quickly running with osgi, but it is more a workaround. I'm not deep in wicket code, but it feels awkward to first package classes in one package and than split this package across modules (which is even harder grained). A while ago I tried to create different package names per module using wicket-trunk codebase. But it was more work than it seemed. Many classes rely on package visibility (also many test classes) on packages that are split across modules. I think, this is an indication that those modules are tightly coupled as you said. It's probably not an easy task to decouple them. But imho something to think about. Then it shouldn't be a problem to have different package names per module, which will solve the osgi problem right away;) Just my opinion... > 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. -- email: [email protected] https://www.eknet.org pgp: 481161A0 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
