On Tue, Apr 26, 2011 at 11:48 PM, Eike Kettner <[email protected]> wrote:
> Hi Daniele, > > > > > 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.f a day in thread like this to finally > arrive to the wicket-stuff projects that solves your problem. > Yeah but you know how things really works. You download/maven/something-else the wicket jars. They do not work in osgi. Then you start google around, it will take you hours, reading conversation like this one, before eventually landing to the wicket-stuff page where there is the solution. If that's the case. You will be not happy. Of course I can accept the "wicket is not intended to be OSGi compliant" explanation and go for the uber-jar in wicket-stuff. Maybe I want to ask: why wicket can't be OSGi compliant? I consider OSGi to be an important reference platform nowadays. Let's fill a jira issue and see what happen. > > > > 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). To me seems like that the split of .util and .request package into separate bundles is just not complete. This is totally understandable. I'm not seeing the point of splitting those two packages that, indeed, are always necessary to run a wicket app, but sure I do not have enough insight view of the project. Despite that, it took ten minutes straight to me to renamce -core packages into .wicket.util and .wicket.request and fix the confusion. Indeed, mvn test now fails in -core, I did not take any care of those in my tentative.
