On Mon, Apr 25, 2011 at 8:00 PM, Martin Grigorov <[email protected]>wrote:
> > On Mon, Apr 25, 2011 at 9:29 PM, Daniele Dellafiore > <[email protected]> wrote: > > The idea of OSGi is to have interface and replaceable implementations. > You can use this to replace Hibernate with EclipseLink as JPA > implementation, or one JMS implementation with another. > Can you do that with Wicket ? I don't think so. There is no > specification, no interfaces. There is just one implementation (well, > there is also Richard Emberson's work on Scala translation, but I > wouldn't recommend you to add another new technology in your mix). > > For me you are wasting your time by trying to do it "as the OSGi > specification says". > I'm not using OSGi for that, but for the ability to deploy small packages, being there libraries, webapp or just some small portion of integration code, a JMS consumer... small packages, installed quickly, that does not make any sense in a JEE container. Also, Karaf offer a nice console and a web console also that I find superior to any tomcat/jetty out there. There are many reason for me to switch to OSGi as my default target environment. And none of this is related to switch implementations. > > > > > Another advantage of deployng my bundle without any other jars is that my > > bundle is 60Kb, the uber-jar more than 1MB, maybe 2. And following this > > policy, will grow everytime there's a non-compliant library to deal with. > > > You need to add all Wicket classes from -util, -request and -core > anyway. No matter whether you'll deploy the jars one by one or > all-in-one (uber-jar) the final result will be the same - "maybe 2MB". > It's not like this. It's: one time and only one I install wicket (2MB) All my app deployments (that in development can a log every day) I deploy a few KB and reload a single jar in less then a second. That's the main goal I'm achieving with all this webapp over OSGI thing. > > > In the ed, it's more OSGI-like and does not affect at all the rest of the > > framework. The only effort is to rename a package, in a major release. It > > took almost 10 minutes to do that to me. If problem is > retro-compatibility > > well... it's a major release, it's a good time, isn't it? > > > It is not a problem to do this in 1.5. We already did it for > wicket-auth-roles. > The problem is similar to the one we have with Portlets support - very > few users and no one of the dev team actually uses this technology. > So we may apply your findings now but we can quite easy break it few > days/weeks later by introducing another similar problem without > noticing it. > I'm sorry I do not understand what you mean here. You mean that fixing this issue cannot be a definitive solution? > My personal opinion is that all this doesn't bring enough value. Using > the uber-jar solution is much simpler. > It's simpler releasing a package that force the developer to a specific solution that's not made the osgi way that they have to find out over and over again rather than renaming a package one time and for all in the distro and make it work out of the box for everyone? The uber-jar solution is not documentet anywhere. Even if documented, is more work that a developer with an OSGi target environment has to do and more than that, to discover. He will ask: why can I use, to say, spring and restlet just installing their bundle to Karaf but this does not apply with Wicket? Cause the wicket bundle are not really osgi compliant. Why? No reason. With my solution, wicket webapp over OSGI will work out-of-the-box. And can be made in a few minutes, as I did. And there is the advantage to deploy few Kb over 2MB every time. And there is the advantage of having something that is standard. I do not mean "OSGi compliant", I mean standard in a more pragmatic way: all over OSGi I use external bundles, with wicket no, different solution, uber-jar. Why? No reason.
