High-Level Goals

• Official Wicket artifacts work seamlessly in OSGi environments.
• The same artifacts continue to work in Java EE and Java SE environments without creating additional dependencies for non-OSGi users.
• OSGi extensions add value to the Wicket project by enabling modular web applications which can be extended at run-time.
• Code duplication and unnecessary dependencies are to be avoided.
• OSGi extensions do not necessarily have to be maintained by the Wicket core team (but of course it would be great to see them actively embracing OSGi). Extensions can continue to live under the WicketStuff or OPS4J umbrellas, or move to ASF.
• Ensuring OSGi-readiness of official artifacts is part of the integration and release process of the Wicket core project.
• Ensuring full OSGi functionality and dynamism is the responsibility of the OSGi extension team(s).

Wicket Artifact Packaging

General Requirements

• Use Maven packaging type bundle by default.
• Do not use dynamic imports.
• Do not embed dependencies when you can import them.

Wicket Core Module Split

Wicket 1.5 Core is currently split into three libraries wicket-core, wicket-request and wicket-util. These libraries only express a layering structure in Wicket, but they are not modules in essence, since they are not intended to be used in isolation, neither in OSGi nor in Java EE.

This library structure is only relevant to Wicket developers and to the build process. For Wicket users, there is no added value in the split libs.

Proposal: The three libraries continue to be used in Wicket's directory structure and build process, However, the final release artifact is a single wicket.jar bundle.

Web Application Packaging

In theory there are three package types

1. Plain HTTP Services
2. WAB
3. WAR (via war-extender)

In pax-wicket we can support all three types. 3 has the option that it could run in OSGi and an J2EE server without modification. Option 2 does not require too many changes but is not really useable for an 1:1 replacement. Option 1 requires more changes (e.g. no web.xml) but has the big advantage that no additional logic is required.

Injection

There are various possiblities for injection. IMHO the easiest way is that a user configures an injection type per bundle in e.g. the manifest.mf. That way we could support all types of injections at once and use the correct one easily for the correct bundle