On Mon, Apr 25, 2011 at 9:29 PM, Daniele Dellafiore <[email protected]> wrote: > On Mon, Apr 25, 2011 at 7:20 PM, Martin Grigorov <[email protected]>wrote: > >> It is the same conversation. >> You need uber-jar. At least one that combines -util, -request and >> -core. Everything else is optional, depending on your app needs. >> > > Ok. As you see I read and answered to that. Well, your statement there wasn't that hard against the uber jar. > > >> >> Can you describe what is the problem to use the uber-jar? Or what are >> the benefits to deploy these three jars separately in the OSGi >> container ? >> > > That is basically a war. One of the advantage of OSGI is having separate > bundles for every module, to start, stop, refresh etc. > If I start packaging things in wars/jars, I lose the control of what is > being used. Will be the bundle or the embedded jar? It's a JEE hell, so why > not use a JEE? I want a clean, pure, osgi environment. The other way, I stay > on JEE.
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". > > 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". > 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. My personal opinion is that all this doesn't bring enough value. Using the uber-jar solution is much simpler. > > >> >> On Mon, Apr 25, 2011 at 9:08 PM, Daniele Dellafiore >> <[email protected]> wrote: >> > Are you referring to this conversation? >> > >> http://apache-wicket.1842946.n4.nabble.com/wicket-1-5-rc2-and-aggregate-jar-for-osgi-td3356667.html >> > >> > If so, I read it and answered that I'm not interested in any solution >> that >> > involves the uber-jar. I do not see any advantage in that solution over a >> > normal war. >> > >> > I do not find any other advice from you and Eike, maybe you can point me >> out >> > the right conversation. >> > >> > >> > On Mon, Apr 25, 2011 at 6:25 PM, Martin Grigorov <[email protected] >> >wrote: >> > >> >> Hi Daniele, >> >> >> >> Me and later Eike explained to you in the other thread you started few >> >> months ago how to solve exactly this problem. >> >> It seems you didn't read it at all. Please read again the part >> >> mentioning Wicket 1.5 RC1. >> >> >> >> On Mon, Apr 25, 2011 at 6:30 PM, Daniele Dellafiore >> >> <[email protected]> wrote: >> >> > I did it. Yes, the tough way but I did it. >> >> > Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the >> >> > 1.5-SNAPSHOT I built. >> >> > >> >> > Basically I renamed the .util and .request packages in -core bundle to >> be >> >> > .core.util and .core.request. >> >> > I had to make a class public in another package under -request bundle >> to >> >> > make it visible, but it's a minor thing. >> >> > >> >> > I open a bug on jira now... wow, is down :) well, as soon as it get >> back >> >> > online. >> >> > >> >> > On Mon, Apr 25, 2011 at 4:03 PM, Daniele Dellafiore >> >> > <[email protected]>wrote: >> >> > >> >> >> it is not. >> >> >> >> >> >> I'm hacking on the trunk to make that work. >> >> >> Maybe a quick solution is just change org.apache.wicket to >> >> >> org.apache.wicket.core in the -core bundle. >> >> >> >> >> >> Of course there are some default scope classes that works through >> >> different >> >> >> packages but I can just make them public for now. >> >> >> >> >> >> On Mon, Apr 25, 2011 at 3:18 PM, James Carman < >> >> [email protected]>wrote: >> >> >> >> >> >>> On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore < >> >> [email protected]> >> >> >>> wrote: >> >> >>> > >> >> >>> > I think that the wicket package layout should be changed now that >> >> -util >> >> >>> and >> >> >>> > -request bundles have been detached from -core. >> >> >>> > >> >> >>> >> >> >>> From an OSGi perspective, we should probably try to make sure that >> >> >>> packages don't span jar files. Everything in >> >> >>> org.apache,wicket.request should be in wicket-request.jar, for >> >> >>> example. I don't know if that's the case, currently or not. >> >> >>> >> >> >>> >> --------------------------------------------------------------------- >> >> >>> To unsubscribe, e-mail: [email protected] >> >> >>> For additional commands, e-mail: [email protected] >> >> >>> >> >> >>> >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> Martin Grigorov >> >> jWeekend >> >> Training, Consulting, Development >> >> http://jWeekend.com >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> >> >> >> -- >> Martin Grigorov >> jWeekend >> Training, Consulting, Development >> http://jWeekend.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
