On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner <e...@eknet.org> 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 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.

Reply via email to