I concur. Greg has been moving along with his work on this, and I am trying to find some spare cycles to try and engage with him to put together a Netbeans project "type" and the associated infrastructure to finally have an IDE friendly Jini development environment. It was recently made possible to replace the security manager in netbeans, at startup, and so that is another one of the issue that needed addressing. My changes from last year that allowed the RMIClassLoaderSPI to be supplanted in Jini with a different mechanism, should allow the netbeans platform class loading module mechanism to be used as well.
Gregg Wonderly On Jul 27, 2012, at 12:52 PM, Greg Trasuk <tras...@stratuscom.com> wrote: > > On Fri, 2012-07-27 at 13:07, Tom Hobbs wrote: >> I'm in a coffee shop with my lappy, so I can get this out for review, >> but someone else will have to submit it. >> >> >> Below is the August report for Apache River >> >> Apache River is a distributed computing architecture, based on the JSK >> Starter Kit Source code donated by Sun Microsystems, for the Jini >> Specification. >> >> Releases: >> No new releases since last report. Work on fixing some issues for the >> next release is ongoing. >> >> Branding: >> No issues to report. >> >> Progress: >> Same few commits and activity taking place as before. >> > Seems a little negative. How about "The pace of commit activity remains > steady." > > Speaking for myself, I've put quite a bit of work into the container > architecture (surrogate and non-surrogate) and hope to complete a > working container-based deployment environment as an alternative to the > "com.sun.jini.start" approach. For what it's worth, the container as it > stands right now fires up and hosts the infrastructure services (Reggie > at least, although there's no reason it couldn't host others) and the > codebase http server. I'm currently working on the mechanism to shut > down a service after startup so as to allow hot-deployment and > facilitate development. > > I'm aiming to implement "deployment by copy", where you deploy a Jini > service provider simply by copying a service archive file into the > deployment directory, much like on Tomcat or JBoss. Then it becomes > very easy to include that deployment in a build workflow, or even the > "build.xml" script inside a Netbeans project. > > Once that's done, and there is some user documentation in place, I will > propose moving the container out from the "skunk" branch to become a > River deliverable, separate from the JTSK. The container depends on the > JTSK, obviously. "Sub-project" seems too grandiose, but at the same > time I don't think the JTSK should contain everything in the project. > I'm thinking that from the users' point of view, they shouldn't have to > deal with everything involved in the infrastructure. They just want to > download a product and start developing applications with it. > > Cheers, > > Greg. > >> Community: >> No issues to report. >> >> Issues: >> No issues to report. >
