Neon can host Jini services..... well it turns agents into Jini services
2008/11/30 Dan Rollo <[EMAIL PROTECTED]>: > Hi All, > > I'm in the midst of some redesign discussions with other devs on the > CruiseControl project (plug link: > http://cruisecontrol.sourceforge.net/distributed/index.html). ;) > > We have a "Distributed extension" aka: DistCC (for remote build agents) that > we are trying to merge into the core of the project. We are also working to > remove some coupling to "shared file systems" that have limited our options > going forward. Towards that end, I see Jini as a way to keep hostname and > other hardcoded network configuration out of the picture. > > In my stumblings with Jini, I've more that once done things the "wrong way", > and I think I have an opportunity to use a nice "Jini Container" that will > do things the "right way", and protect me from myself in the future. ;) > > While searching for such "Jini Service Containers", I have a few questions > about what might be the best fit: > > Rio > https://rio.dev.java.net/ > This is the one I've heard the most about, but I'm a little concerned about > the size of it's footprint. Any thoughts here? Are there smaller "rio parts" > that could be deployed, without requiring a ~15mb download on each client? > Even if not, it's probably not a show stopper, but it may be harder to get > buy in... > > Seven > http://www.cheiron.org > This link appears broken. Is it replaced by: > https://whatsitdo.dev.java.net/ ? > Is there some other "most up to date" URL to use for Seven? > > Harvester > https://harvester.dev.java.net/ > Is this still active, and has the latest code been published somewhere? > > Others? > > CruiseControl has a fairly decent size user base, and I'd really like to > find a way to remove (or at least hide) my "worst practices" Jini code (and > also of course, make the system more stable, scalable, etc.) ;) Right now, > only the "build agents" are distributed across the network via Jini, but > ideally, we'd like to have every node be able to handle all tasks > (bootstrapping, scheduling, building, publishing, etc). I think a container > framework is the best way to make this happen, and with such a framework in > place, we could then do things like replace the build queue with a > javaspace, etc, but that's step 203 of 5,000. Other suggestions are also > welcome. > > Thanks! > Dan Rollo >
