Isn't option 3 the solution which we have currently in WicketStuff's wicket-bundle-parent ? If it is not then can you please give more details what exactly you mean.
I'd prefer the following approach for Wicket OSGi: - use wicketstuff/wicket-bundle for OSGi deployments (wicket-bundle merges -util, -request and -core into one .jar) - use PAX-Wicket or wicketstuff/wicket-osgi for all glue code like OSGiClassResolver, OSGiInjector, serialization... And this project will depend on wicketstuff/wicket-bundle If any changes are needed in Wicket -core, -ioc, ... then please create tickets (or comment in WICKET-3737) and we will improve where needed. For Wicket 1.6 we could fix the split package problem in -util and -request and wicket-bundle may be retired Do you see any problems with this approach ? -util, -request and -core were made this way to improve Wicket code itself. Now code in -util doesn't use code from -request or -core. On Tue, Aug 16, 2011 at 10:20 AM, Brian Topping <[email protected]> wrote: > Option 2 kind of speaks to the idea that Martijn just had about users being > less inconvenienced by fewer artifacts and it would save a lot of hassle WRT > these packages split across multiple artifacts. > > We were kind of wondering out loud the other day why the packages are split > across artifacts like that. I thought I had heard the reason but was not > sure I could recite it exactly. Can anyone share? > > My non-binding vote is for @2. > > On Aug 15, 2011, at 10:56 PM, Andreas Pieber wrote: > >> Hey Guys, >> >> While we're still in RC phase we might want to consider the following point: >> Packaging >> >> Wicket comes in with three core artifacts: >> >> <dependency> >> <groupId>org.apache.wicket</groupId> >> <artifactId>wicket-core</artifactId> >> <version>1.5-RC5.1</version></dependency> >> >> <dependency> >> <groupId>org.apache.wicket</groupId> >> <artifactId>wicket-util</artifactId> >> <version>1.5-RC5.1</version></dependency> >> >> <dependency> >> <groupId>org.apache.wicket</groupId> >> <artifactId>wicket-request</artifactId> >> <version>1.5-RC5.1</version></dependency> >> >> All three of them are required. Currently I think it is assumed best >> practice to include wicket-core into your maven project and let it resolve >> util and request automatically. Thinking about the OSGi integration into >> wicket this leaves us with three options: >> >> 1. OSGifying all three of them using split-package. >> 2. Embed util and request into wicket-core. >> 3. Provide e.g. "apache-wicket" which repacks core, util and request into >> one package. >> >> @1: Split-Package is a real pain in OSGi. While it might work there are >> always some hidden risks using this technique and I would really like to >> avoid it at any chance >> @2: This one would be an option since it will be the less interrupting one. >> @3: This one might be the most clean solution. Among the apache-wicket >> artifactId we could distribute a bundle (which can be included/referenced in >> a classical J2EE env (as wicket-core before)), but could also be launched in >> an OSGi environment. In addition we can also provide e.g. features.xml & >> .kar packages (for Karaf) within the aritfact id, eba packages (Apache >> Aries) and so on. Option three has the additional advantage that we can also >> separate the OSGi code from the core code by packing and defining it in >> apache-wicket. >> >> TBH I can live with both, @2 and @3 quite well but would slightly prefer >> option 3. What does other think about this? >> >> Please don't get me wrong. I don't want to be intrusive in any way or do >> any criticism on the current way. I can live quite well with option 2 if >> this is the commonly agreed solution. It's just that I want to show up the >> options and possibilities we have. >> >> I'm very interested in your feedback. >> >> Kind regards, >> Andreas > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
