I like the fist break out that Jeremy proposed as I see there may be issues with
keeping all this organized and lets give this a shot and see how well we
manage it. After a while if we think things are going smooth start breaking out
extensions on their own.
I do hope we can organize it to still allow building the latest in SVN TRUNK of
all components so if we want to test how that all still hangs together it's
possible without being too painful. The danger of going to long without
catching incompatibilities I think is real too.
Moving samples related to extensions to the extensions makes some sense, but I
still think in the future we may want to offer some distribution artifact where
they are bundled together and allow for a user to do a one shot download to play
with them.
Jim Marino wrote:
On Dec 10, 2006, at 7:03 AM, Jeremy Boynes wrote:
On Dec 9, 2006, at 2:52 PM, Jim Marino wrote:
* Extensions (components that add function to the bare runtime)
Axis2 web services (axiom, axis2 ws binding, ...)
Scripting and Web2.0 (script container, json databinding, ...)
A minor nit here - I would separate Scripting and Web 2.0 since I
don't think they are inherently tied together, e.g. JSON could be a
binding used by back-end components. Also, I'm not sure if we want to
lump a bunch of languages under scripting, for example, Ruby or
Groovy. Maybe we categorize more by functional role such as binding
or component impl type and how people are likely to evolve them? I
don't have a really strong preference on this.
These suggestions were just meant to be illustrative and I also don't
have a strong feelings on the groupings. I wanted to capture that
there are likely to be groupings at a level above an individual module
but I think we'll figure out what they are as we go.
J2EE integration (ejb container, rmi/iiop binding, ...)
Spring integration
OSGi integration
and many many more
I like the idea of having a hierarchy of extension modules. I don't
feel strongly about this either, but it may be useful to group by
subtype like we have it today, e.g. binding extensions, component
impl type extensions, etc. It may make things a little more
manageable moving forward as the number of extensions increases.
I've been wondering if this is the right breakdown. IMO the grouping
of a module should be driven by what we would like to release together
and that may span different types of modules. For example, "Axis2 Web
Services" would include the AXIOM databinding, the Axis2 binding, and
perhaps a (hypothetical) JAX-WS container with the main reason for
grouping them together being that they all need to use the same
version of Axis2. On the converse side, I don't see why we would
release a diverse bag of scripting containers together so breaking
"Scripting" apart as you suggested above is a good idea.
I think this approach makes sense. This has come up as well in the
situation where modules depend on versions of other modules such as the
WSDL2Java tool. We should perhaps group things by how they are
released/evolved together and also provide some higher-level
organization. For example, the Axis2 and related modules would go under
bindings/axis2.
Jim
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
