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>
From: "Howard M. Lewis Ship" <hlship@comcast.net>
To: "'Luke Blanshard'" <luke@blanshard.us>
Cc: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Subject: RE: [HiveMind] HiveMind ideas
Date: Wed, 3 Mar 2004 14:50:59 -0500
Message-ID: <026801c40158$dc6123c0$6401a8c0@ALMIGHTYBEAST>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <200403031843.BCJ88153@ms4.verisignmail.com>
Importance: Normal

> >From: "Howard M. Lewis Ship" <hlship@comcast.net> =20
> >>=20
> >> - I believe your placeholder for version checking is at the=20
> >> wrong level.
> >>  I think versioning should be at the service interface=20
> level, not the
> >> module level.  Isn't that how Eclipse does it?  What are your=20
> >> thoughts here?
> >
> >I'm pretty sure module level makes sense. Eclipse does it that way.
>=20
> Right you are -- I misremembered.  However, let me expand a bit on my
> theory.
>=20
> A HiveMind module may supply lots of service interfaces.  Now, you
> *might* want to manage all of these services' versions with a single
> module-wide version -- as you have it.  But you might instead want to
> manage their versions individually.  Why?  Well, otherwise your 10
> stable services will appear to have changed incompatibly when you have
> to bump your module's version number to satisfy your 1=20
> rapidly changing
> service.
>=20
> I'm anticipating being able to specify the version number=20
> required when
> wiring up a service, and when providing an implementation, with the
> meanings for version numbers that Eclipse uses.  (Namely: a change to
> the major number means a potentially incompatible change, and a change
> to the minor number means backwards compatible.)
>=20
> This seems useful to me, when trying to manage lots of independently
> developed services, which is what I'm trying to do.
>=20

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

I'm beginning to see that your interfaces will stay simpler and more =
stable. HiveMind gives you a
lot of tools (on-the-fly service construction, dependency injection, =
event notifications, stateful
service models) so that its' very easy to create simple facade =
interfaces around more intracate,
collaborative services.

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 =3D=3D one module"
approach.  Perhaps an element of the module descriptor could be a path =
to *additional* module
descriptors to read. =20

In other words, you can have a "myco.mypackage.public" module and a =
"myco.mypackage.private" module
packaged together in a single JAR.

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components=20
http://howardlewisship.com


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