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

Reply via email to