You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Howard M. Lewis Ship" <hl...@comcast.net> on 2003/09/15 14:42:40 UTC
[HiveMind] Forming the community
Based on the feedback I've received from you and from interested parties with Jakarta and Jakarta
Commons, I believe this is how it can roll out.
External developers can contribute patches. By external, this means people who don't already have
Jakarta privileges.
Those with Jakarta privileges should already have access to the HiveMind CVS repository, that's the
nature of the Jakarta Commons Sandbox.
We'll stay on the commons-dev@jakarta.apache.org mailing list, just put [HiveMind] in the subject.
We can worry about promotion out of the sandbox later. Another possibility is moving the source
code under Tapestry (in the Tapestry 3.1 time frame).
I have HiveMind building locally using Maven 1.0-rc-1 (out of Maven's CVS). I'm going to look into
refactoring the code base so that there are multiple sub-projects. Initially, I envision a
framework subproject (for the framework and the core services ... which is to say, what's currently
in CVS). Additionally, we should add a "standard library" module, for useful stuff that doesn't
absolutely have to be in the framework propery and, perhaps, a sandbox module library, for new code
under less stringent release mechanisms.
I this a good vision? Or should the other modules become new commons sandbox projects unto
themselves ... or be elsewhere, such as on SourceForge?
What kind of services can we create for the additional libraries?
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
RE: [HiveMind] Forming the community
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Bill Lear [mailto:rael@zopyra.com]
> Sent: Monday, September 15, 2003 10:49 AM
> To: Jakarta Commons Developers List
> Subject: RE: [HiveMind] Forming the community
>
>
> On Monday, September 15, 2003 at 10:22:08 (-0400) Howard M.
> Lewis Ship writes:
> >...
> >I think its about managing dependencies. HiveMind has limited
> >dependencies on some other commons projects and on
> Javassist. If you
> >build some HiveMind glue to another project, you may inadventantly
> >require the other project as a dependency, so you add a few KB of
> >HiveMinde glue and, possibly, many megs of external dependency. ...
> >So, I'd rather have a new module, say "hivemind.standard.hibernate"
> >that contains wrappers around Hibernate than have those wrappers part
> >of the main library whether you use Hibernate or not.
> >...
>
> Good points, I agree.
>
> >Sounds like a decent idea for me; we're doing something similar at
> >WebCT shortly and I'm pushing to leverage HiveMind. Now if
> only I could
> >MANDATE it ...
>
> You've been reading Nietzsche again, haven't you!
>
> I've just successfully built and run the example you provide
> in the documentation. This is a good start. I do think that
> the example in particular, and HiveMind in general, would be
> helped by a discussion of the advantages of declarative
> programming and how it can be used to simplify testing of
> applications. I liken this to Laplace transforms, with which
> one transforms work to be performed from one domain that is
> difficult, into another which is easier. A mention of why
> certain parts of the application are transformed
> (construction of services), and not others, would also be
> helpful to guide developers in their choices.
That sounds like a good idea of another sub-project, an example that demonstrates some useful things
you can easily do in HiveMind, including unit tests.
>
> Extending this, one needs to show exactly how programming for testing
> (PFT) becomes possible or at least much easier. Without such
> a concrete demonstration of the ease of switching between
> production and testing implementations, the plumbing looks to
> the untrained eye to be just so much dressing for no purpose.
Excellent point, and an excellent area for contributions ... justifying HiveMind after the fact!
>
> So, I would suggest as we move forward that we realize our
> high-level goals directly in the example. So, the example
> should include multiple independent HiveMind services
> ("independent" yoked to HiveMind is of course redundant) and
> perhaps an application that uses these services in
> production, and also, mock services (if that is the
> appropriate term) that implement the services for testing purposes.
>
> This brings another thing to mind: would it be
> appropriate/possible for HiveMind services to also provide a
> mock version of their service? Or is the particular
> implementation of mock services too much dependent upon the
> application in which they are used?
I think it would be hard to pin down; MockObjects can create mockups, but you need a reference to
the mock-object-generator class to tell the mockup how to behave. In other words, you need access
to the service and its implementation, and HiveMind only gives you the service.
You could imagine, though, a MockInterceptor that you could use for these purposes in some way (just
not sure what that way is).
I picture the unit testing story for HiveMind to be the unit test acting as the container,
instantiating core service implementations and settting properties to point at each other, then
invoking methods.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
RE: [HiveMind] Forming the community
Posted by Bill Lear <ra...@zopyra.com>.
On Monday, September 15, 2003 at 10:22:08 (-0400) Howard M. Lewis Ship writes:
>...
>I think its about managing dependencies. HiveMind has limited
>dependencies on some other commons projects and on Javassist. If you
>build some HiveMind glue to another project, you may inadventantly
>require the other project as a dependency, so you add a few KB of
>HiveMinde glue and, possibly, many megs of external dependency.
>...
>So, I'd rather have a new module, say "hivemind.standard.hibernate"
>that contains wrappers around Hibernate than have those wrappers part
>of the main library whether you use Hibernate or not.
>...
Good points, I agree.
>Sounds like a decent idea for me; we're doing something similar at
>WebCT shortly and I'm pushing to leverage HiveMind. Now if only I
>could MANDATE it ...
You've been reading Nietzsche again, haven't you!
I've just successfully built and run the example you provide in the
documentation. This is a good start. I do think that the example in
particular, and HiveMind in general, would be helped by a discussion
of the advantages of declarative programming and how it can be used to
simplify testing of applications. I liken this to Laplace transforms,
with which one transforms work to be performed from one domain that is
difficult, into another which is easier. A mention of why certain
parts of the application are transformed (construction of services),
and not others, would also be helpful to guide developers in their
choices.
Extending this, one needs to show exactly how programming for testing
(PFT) becomes possible or at least much easier. Without such a
concrete demonstration of the ease of switching between production
and testing implementations, the plumbing looks to the untrained eye
to be just so much dressing for no purpose.
So, I would suggest as we move forward that we realize our high-level
goals directly in the example. So, the example should include
multiple independent HiveMind services ("independent" yoked to
HiveMind is of course redundant) and perhaps an application that uses
these services in production, and also, mock services (if that is the
appropriate term) that implement the services for testing purposes.
This brings another thing to mind: would it be appropriate/possible
for HiveMind services to also provide a mock version of their service?
Or is the particular implementation of mock services too much dependent
upon the application in which they are used?
Bill
RE: [HiveMind] Forming the community
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
>
> I think a hierarchy is fine. If you can't use the other
> modules without the main module, perhaps making them separate
> sandbox projects is not terribly useful. On the other hand,
> perhaps the main module could be just another "mix-in" that
> you check out from the repository to add to separate projects
> to support them. Or maybe I'm missing the point entirely.
>
> This is one area I have struggled with many times before.
> Maven has some promise, as you have noted, to allow support
> for clean separation of modules. I tried doing this entirely
> in CVS, but was not altogether successful.
I think its about managing dependencies. HiveMind has limited dependencies on some other commons
projects and on Javassist.
If you build some HiveMind glue to another project, you may inadventantly require the other project
as a dependency, so you add a few KB of HiveMinde glue and, possibly, many megs of external
dependency.
Also, just like you want to keep your APIs lean and mean, keeping the services and extension-points
in a module lean and mean helps with comprehension.
So, I'd rather have a new module, say "hivemind.standard.hibernate" that contains wrappers around
Hibernate than have those wrappers part of the main library whether you use Hibernate or not.
>
> >What kind of services can we create for the additional libraries?
>
> Would a data access service be too ambitious? Even something
> that helps with ordinary JDBC setup and testing would be
> nice/useful for many projects.
Sounds like a decent idea for me; we're doing something similar at WebCT shortly and I'm pushing to
leverage HiveMind. Now if only I could MANDATE it ...
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
Re: [HiveMind] Forming the community
Posted by Bill Lear <ra...@zopyra.com>.
On Monday, September 15, 2003 at 08:42:40 (-0400) Howard M. Lewis Ship writes:
>...
>I have HiveMind building locally using Maven 1.0-rc-1 (out of Maven's
>CVS). I'm going to look into refactoring the code base so that there
>are multiple sub-projects. Initially, I envision a framework
>subproject (for the framework and the core services ... which is to
>say, what's currently in CVS). Additionally, we should add a "standard
>library" module, for useful stuff that doesn't absolutely have to be
>in the framework propery and, perhaps, a sandbox module library, for
>new code under less stringent release mechanisms.
>
>I this a good vision? Or should the other modules become new commons
>sandbox projects unto themselves ... or be elsewhere, such as on
>SourceForge?
I think a hierarchy is fine. If you can't use the other modules
without the main module, perhaps making them separate sandbox projects
is not terribly useful. On the other hand, perhaps the main module
could be just another "mix-in" that you check out from the repository
to add to separate projects to support them. Or maybe I'm missing the
point entirely.
This is one area I have struggled with many times before. Maven has
some promise, as you have noted, to allow support for clean separation
of modules. I tried doing this entirely in CVS, but was not
altogether successful.
>What kind of services can we create for the additional libraries?
Would a data access service be too ambitious? Even something that
helps with ordinary JDBC setup and testing would be nice/useful for
many projects.
Bill
RE: [HiveMind] Forming the community
Posted by di...@multitask.com.au.
"Howard M. Lewis Ship" <hl...@comcast.net> wrote on 16/09/2003 12:16:28
AM:
> beta-10 multiproject is broken; hopefully 1.0-rc-1 will be useable.
If it's not now, it wont be before rc1....I've got no open bugs on it.
> There's a difference in xdoc XML parsing between beta-10 and rc-1 (I
> added a bug, I think rc-1 is
> wrong).
Still haven't been able to track that down. Looks like the xml parser is
screwy to me.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
RE: [HiveMind] Forming the community
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
beta-10 multiproject is broken; hopefully 1.0-rc-1 will be useable.
There's a difference in xdoc XML parsing between beta-10 and rc-1 (I added a bug, I think rc-1 is
wrong).
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Monday, September 15, 2003 9:52 AM
> To: Jakarta Commons Developers List
> Cc: Johan Lindquist; Bill Lear; David Solis; Essl Christian;
> Harish Krishnaswamy; 'Tim OBrien'; 'RANDAD,KAILASH
> (HP-PaloAlto,ex1)'; 'Tetsuya Kitahata'
> Subject: Re: [HiveMind] Forming the community
>
>
>
>
> On Mon, 15 Sep 2003, Howard M. Lewis Ship wrote:
>
> > I have HiveMind building locally using Maven 1.0-rc-1 (out
> of Maven's
> > CVS). I'm going to look into refactoring the code base so
> that there
> > are
>
> Is there a reason for using the CVS one? Or just because
> you've been playing with it?
>
> Should it build with b10?
>
> > multiple sub-projects. Initially, I envision a framework
> subproject
> > (for the framework and the core services ... which is to
> say, what's
> > currently in CVS). Additionally, we should add a "standard library"
> > module, for useful stuff that doesn't absolutely have to be in the
> > framework propery and, perhaps, a sandbox module library,
> for new code
> > under less stringent release mechanisms.
> >
> > I this a good vision? Or should the other modules become
> new commons
> > sandbox projects unto themselves ... or be elsewhere, such as on
> > SourceForge?
>
> I think this sounds good. Other modules in commons-sandbox
> would be bad I think. Going to sourceforge, codehaus,
> java.net or something is another option for the modules, a la
> maven plugins etc. Making that decision later on seems the
> best option.
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [HiveMind] Forming the community
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 15 Sep 2003, Howard M. Lewis Ship wrote:
> I have HiveMind building locally using Maven 1.0-rc-1 (out of Maven's
> CVS). I'm going to look into refactoring the code base so that there are
Is there a reason for using the CVS one? Or just because you've been
playing with it?
Should it build with b10?
> multiple sub-projects. Initially, I envision a framework subproject
> (for the framework and the core services ... which is to say, what's
> currently in CVS). Additionally, we should add a "standard library"
> module, for useful stuff that doesn't absolutely have to be in the
> framework propery and, perhaps, a sandbox module library, for new code
> under less stringent release mechanisms.
>
> I this a good vision? Or should the other modules become new commons sandbox projects unto
> themselves ... or be elsewhere, such as on SourceForge?
I think this sounds good. Other modules in commons-sandbox would be bad I
think. Going to sourceforge, codehaus, java.net or something is another
option for the modules, a la maven plugins etc. Making that decision later
on seems the best option.
Hen