Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-Id: <200403032034.BCK15514@ms4.verisignmail.com>
Date: Wed, 3 Mar 2004 15:34:55 -0500
From: Luke Blanshard <luke@blanshard.us>
Subject: RE: [HiveMind] HiveMind ideas
To: "Howard M. Lewis Ship" <hlship@comcast.net>
Cc: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


>Rapdily changing interfaces?  Not just implementations, but interfaces?
>That sounds more like a alpha cycle than a full release cycle.

I suppose it does.  The reality is, though, that a given jar file is
likely to have code whose level of stability spans a pretty wide range.
 Even interfaces.

Taking out the "rapidly", the issue remains.  Just because I change one
interface incompatibly shouldn't mean that users of all the other
interfaces in my module have to adjust their allowed versions.

>Back to your issue. One solution is to use a more fine grained
>approach; have many seperate modules.
>
>I think, to support that approach, HiveMind may need a way to break the
>"one jar == one module" approach.  Perhaps an element of the module
>descriptor could be a path to *additional* module descriptors to read.

That would help, I guess.  But only if you planned ahead far enough.  It
wouldn't give you a way out of a hole.

Luke

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org