Hi Danielle, On Tue, Apr 26, 2011 at 2:19 PM, Daniele Dellafiore <[email protected]> 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. > 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. Few years ago someone asked for better OSGi support in Wicket and the special entries in MANIFEST.MF were introduced with the help of bnd plugin. That's all Wicket ever supported explicitly for OSGi. I also remember that the same people used PAX-Wicket quite successfully.
About "I, and all wicket developers, have to do" - I said it several times: WicketStuff is a community project. The OSGi users can create a new sub-project, e.g. wicket-osgi, which will pack -util, -request and -core in one. It will be automatically deployed in Maven repos. Let me know if you need help with this project if you want to create/maintain it. > 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. > 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. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
