river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher G. Stach II" <...@ldsys.net>
Subject Re: Short term plan forward... (proposal)
Date Tue, 22 May 2007 19:59:13 GMT
Bob Scheifler wrote:
> Jim Hurley wrote:
>> I'd like to propose
>> that we immediately start working on a release (v0.1).
>> To focus on getting a release out, the initial work
>> would be targeted at integration stuff (for example, getting Service UI
>> integrated) and some documentation rather than on very many
>> bug fixes or rfes.
> 
> I'm OK with that if that's what people want, but it would be good
> to get a bit more clarity.  The first release would have:
>  - no code changes over the 2.1 starter kit release?
>  - lib/serviceui.jar added in as-is (not classes folded into other jars)?
>  - no installer, just a zip file distribution?
>  - no fundamental changes to the build process?
>  - just cosmetic changes to the documentation?  [what changes?]
> 
> 
> - Bob
> 

I'm definitely for fast and short releases.  Some things that should
probably be done in the first release include:

* Identifying what IS Jini and what ISN'T Jini (or, what is River)

I think that there might be a lot of confusion as to what is standard
and what isn't.  Decent examples of this pattern are JPA-Hibernate and
Jini-GigaSpaces (although the Jini isn't that visible there).  I can
imagine that beginners interested in Jini are picking up Jan Newmarch's
Jini 2.0 book and finding themselves puzzled about all of the
clarifications.  "This isn't a standard class and it can disappear at
any time." (paraphrased)  This leaves room for both a bare bones Jini
package that is concerned about backwards compatibility and a value
added set of packages where developers can run free and implement new
things (like a [what I think is an awesome idea] semi-standard
implementation of notify heartbeat.)  Jini is pretty stagnant as it is.
 There's no reason to hold it back from new Java library classes or
language features.

* Make it easily available

A lot of people use Maven, Maven 2, and Ivy.  A zip file or available
JARs should be fine.  Get it on ibiblio ASAP.  I think that anyone using
this can put it together with good documentation.  Screw installers. :)
 I know that I'd personally rather unzip something and take the parts
that I want than run someone else's version of what they think things
should look like on my computer or in my workspace.

* Good, or at least centralized, documentation

As always, the last part to happen. :)  It doesn't have to be
comprehensive, as long as people can get started.  A plain old wiki with
some common use cases should suffice.  In addition, I think that a lot
of the Jini experts are pretty quiet about design patterns, or at least
those patterns are hidden from plain view on mailing lists.  This is a
great chance for everyone to just dump their crap on a wiki and let
people piece it together over time.  At least they will know where to look.

* Great build process.

Jini has a chance to be very useful to a lot of businesses, and open
source is usually pretty tough to sell in many organizations.  Great and
easily available metrics are important.  People will probably want to
see defect analysis, metrics, unit test coverage, defect trends, MTTR,
etc.  Getting this going right away will be good to show that there's
momentum from the initial code delivery and it will help formulate a
repository structure in the early stages.

There was a more, but I was pretty tired...

-- 
Christopher G. Stach II


Mime
View raw message