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
