Re: Entries, ServiceTemplates, and JavaSpaces

> It sounds like you started out with a fixed set of criteria 
> that are always present.  There are some additional criteria 
> that you'd like to make arbitrarily large.  Depending on how 
> this list of criteria changes, it might be possible to create 
> a base Entry class with the always present values.  
> Additional applications could subclass the base Entry to add 
> their specific criteria.  The issue is whether there is a 
> natural separation of properties or if there are overlaping 
> uses where this would not work.

We do have a base Entry class with some always-present values. From
there, though, it's possible for the user to configure the build
master with entries that don't have corresponding build agents. These
build requests should languish and eventually get cleaned up (would
love to use http://autot.jini.org to boot a new machine with the
correct features--that'd be awesome) and logged as unbuildable. The
agents should usually have many properties describing their features
(e.g. "os.name=Windows XP", "fixpack=1.1", "service.pack=SP2"), most
of which won't matter for most builds. (For instance, most of the time
with our Java projects we don't care if they are built on Linux or
Windows.) So, in summary, the build master's property requirements
MUST be met and the agent must not have any conflicting properties.
With the entries of service registration this worked fine.

Incidentally, I don't think I made clear that the point of the whole
project is to run unit tests every time a change is committed to CVS.
CruiseControl currently can't distribute its builds and subsequent
unit tests, so if CVS has been busy there could potentially be enough
simultaneous builds going on to dog the build machine. We hope to be
able to distribute the work and accumulate the results on the build
master.

Hope that at least clears up our use-case!
 
> Gregg Wonderly

Jeff

| Jeff Ramsdale |
|   SolutionsIQ |
|  Bellevue, WA |

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html

JDC members can download the JavaSpaces(tm) Technology from:
http://developer.java.sun.com/developer/products/jini/