Hi all
I'm new to this list (and Wicket), and was interested in this
discussion.
On 12/02/2009, at 11:32 PM, Hoover, William wrote:
Just out of curiosity... Are there any plans to push a JSR that Wicket
could follow. I think there would be a lot more acceptance of Wicket
if
this was to happen :o)
--------
It might be interesting to examine this idea in the context of OSGi.
OSGi is a standard for componentisation and packaging and component
lifecycle management that has it roots in embedded devices, and
incorporates a whole range of further standards related to this type
of platform. It grew out of efforts that were mostly independent of
Sun, and has continued to evolve as a standard in a separate
organisation to the JSR process.
It now has a JSR (277), but the OSGi specifications evolve separately
of this original JSR. It has multiple implementations (Felix, Equinox,
Knopflerfish, etc). Its flexibility in its design (extender bundles,
manifest extensions, whiteboard model, etc assist this) has led to
many addons that build upon it such as Spring DM, iPOJO, etc. In the
next version of the specification many of these community ideas will
be incorporated back into the main specifications. The Core OSGi
specification doesn't add much to the language, but its Compedium
specifications, which build upon the Core spec, provide everything
from configuration management, device resolution, to user
administration and logging.
Sun were looking at using it in Java 7 in order to modularise the JVM,
a similar goal to the Apache Harmony project IIRC. They have since
dropped this goal and have revived JSR 294 for modularisation. OSGi
continues to move along alone and gain its own popularity without the
JSR/JCP process. Sun's attitude seems to be to just ignore OSGi (a
form of NIH syndrome?).
IMHO what this means for Wicket is: unless it provides a small base
for lots of extra functionality to be built upon, its just going to
get mired in the politics of the JSR/JCP process and not really
achieve anything. It will probably end up being shunned as a
competitor to JSF and left unresolved.
It may be better for Wicket to look at managing its own APIs so there
is less breakage between versions (note: I've only begun using Wicket
recently so I'm not trying to suggest this is the case) and that
versions are clearly delineated in terms of API compatibility between
them. It could try and elevate the Wicket extensions to be more
tightly managed within the Wicket project, and seek from time to time
to incorporate these back in into the Wicket mainline. In this way,
Wicket becomes "standardised" but still maintains the freedom to
innovate more quickly. Wicket seems to be tightly modularised enough
(or able to modularised) that using Wicket as a base to grow new and
interesting functionality whilst maintaining a stable core seems
feasible.
Cheers
Chris
---
Christopher Armstrong
carmstrong at fastmail com au.
--------
Christopher Armstrong
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
