You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Tom Hobbs <tv...@googlemail.com> on 2012/07/27 19:07:18 UTC
[DRAFT][REPORT] Apache River
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.
Community:
No issues to report.
Issues:
No issues to report.
Re: [DRAFT][REPORT] Apache River
Posted by Tom Hobbs <tv...@googlemail.com>.
Fair enough, sorry for the tone of the original. I've not had a chance to
read any river emails for the past month!
Can someone sort the text for the report out so I can try and submit it
Tuesday pm GMT?
Thanks.
Tom
On Jul 28, 2012 6:40 PM, "Gregg Wonderly" <gr...@wonderly.org> wrote:
> 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 <tr...@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.
> >
>
>
Re: [DRAFT][REPORT] Apache River
Posted by Gregg Wonderly <gr...@wonderly.org>.
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 <tr...@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.
>
Re: [DRAFT][REPORT] Apache River
Posted by Greg Trasuk <tr...@stratuscom.com>.
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.