On Tue, Aug 16, 2011 at 2:12 PM, Martin Grigorov <[email protected]> wrote: > 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 And of course PAX/wicket-osgi project could be merged to Wicket distro if we decide so. > > 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 >
-- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
