You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2009/03/05 09:16:03 UTC
Board Report is due...
River PMC,
please note that the quarterly Board report is due in a few days;
Wednesday, 11 March 2009
The report is to go into; http://wiki.apache.org/incubator/March2009
Cheers
Niclas
--
http://www.qi4j.org - New Energy for Java
Re: Board Report is due...
Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks Jukka,
I'll have a crack at it this coming weekend.
Cheers,
Peter Firmstone
Jukka Zitting wrote:
> Hi,
>
> On Sat, Mar 14, 2009 at 10:14 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>> Perhaps we could create some readme files eg Readme.Netbeans.txt and
>> Readme.Eclipse.txt etc to assist getting started, would anyone mind if I
>> wrote one for Netbeans?
>>
>
> On the contrary, any contributed documentation would be greatly appreciated.
>
>
>> Or better still is there space on Apache River's web site for a web page,
>> I could take some screen shots and show it step by step?
>>
>
> Sure, just file a Jira issue for that and we'll get it uploaded on the site.
>
>
>> The ant scripts for the integration tests sound promising, perhaps we could
>> have both the make and the ant scripts included in separate test trees, so
>> everyone can run the tests in parallel for a while, more eyes make better
>> code yes?
>>
>
> The latest Ant script and the latest test sources are now located in
> the integrationtests folder inside the jtsk trunk. The make scripts
> are still available in the separate qatests trunk.
>
> BR,
>
> Jukka Zitting
>
>
Re: Board Report is due...
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Sat, Mar 14, 2009 at 10:14 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Perhaps we could create some readme files eg Readme.Netbeans.txt and
> Readme.Eclipse.txt etc to assist getting started, would anyone mind if I
> wrote one for Netbeans?
On the contrary, any contributed documentation would be greatly appreciated.
> Or better still is there space on Apache River's web site for a web page,
> I could take some screen shots and show it step by step?
Sure, just file a Jira issue for that and we'll get it uploaded on the site.
> The ant scripts for the integration tests sound promising, perhaps we could
> have both the make and the ant scripts included in separate test trees, so
> everyone can run the tests in parallel for a while, more eyes make better
> code yes?
The latest Ant script and the latest test sources are now located in
the integrationtests folder inside the jtsk trunk. The make scripts
are still available in the separate qatests trunk.
BR,
Jukka Zitting
Re: Board Report is due...
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Tom,
Thanks for your kind advise, much appreciated, I've got everything
working so I'll play around and see what I can come up with. It sounds
like the issues are well understood and are in the process of being
actioned. Perhaps we could create some readme files eg
Readme.Netbeans.txt and Readme.Eclipse.txt etc to assist getting
started, would anyone mind if I wrote one for Netbeans? Or better still
is there space on Apache River's web site for a web page, I could take
some screen shots and show it step by step?
The ant scripts for the integration tests sound promising, perhaps we
could have both the make and the ant scripts included in separate test
trees, so everyone can run the tests in parallel for a while, more eyes
make better code yes?
Cheers,
Peter.
Tom Hobbs wrote:
> Hi Peter,
>
> I think you're absolutely right. Here are my comments on your points;
>
>
>> 1. Importing River into your preferred IDE, including the tools.jar
>>
> into
>
>> your classpath on the correct tested jdk environment and building it.
>>
>
> I hope this experience will be improved when we (I) finish RIVER-301.
> The tools.jar thing I believe is RIVER-272. I seem to recall someone
> saying that they're looked at that and were reluctant to post their
> patch or that they were intending to look at it. (I might have dreamed
> that conversation though, can anyone else remember it?)
>
>
>> 2. Getting to know Rivers structure, how it all works, playing around
>>
> with
>
>> it, writing some programs that use it to improve understanding.
>>
>
> Unfortunately, I can't see a way around this without spending the
> personal effort to actually do the reading and coding required to get
> familiar. My advice, would be to pick one small area and get to know
> that and then branch out into other areas as and when.
>
>
>> 3. Getting to know how the integration tests work to improve
>>
> confidence
>
>> your not breaking anything.
>>
>
> This is RIVER-301 again. I've got an ant script that can now run the
> tests I just need to tidy it up and attach it to JIRA. It's not
> perfect, but since I don't understand how the integration tests work
> either, I'm having trouble making it so.
>
> Does anyone know where I can find a complete list of all the test
> categories? I don't seem to be able to find it and need it to complete
> the script.
>
> I think that the unit tests should be written for new code (someone's
> writing new code?) but I doubt that there'll be much take up on writing
> unit tests for existing code.
>
>
>> 4. Becoming confident enough to tackle some of the open issues.
>>
>
> My advice is to just jump in. Pick an issue (any issue) and try to work
> through it. Attach the patch to JIRA and it'll eventually get looked
> at. I did this with RIVER-296 when I was in no way confident that I
> understood the code I was looking at.
>
> There are integration tests and dedicated committers who'll check
> through these things and get back to you if it's not correct. No one is
> going to be attacked (I hope, for my sake!) for attaching a patch that
> unintentionally breaks the build or isn't a complete fix.
>
> I hope that some of these comments (and the eventual completion of
> RIVER-301) will lower the entry barrier. I'd like to reiterate my final
> comment that you shouldn't be reluctant to get involved because you're
> not "confident enough". Nothing improves confidence like trying to
> solve a puzzle and eventually getting through it. That in and of itself
> gets you part the way up the learning curve.
>
> Cheers,
>
> Tom
>
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: 13 March 2009 02:34
> To: river-dev@incubator.apache.org
> Subject: Re: Board Report is due...
>
> Hi,
>
> I'd like to contribute, I'm thinking about nio, SocketChannel and
> SSLSocketChannel, however I'm still new to Jini, so there's a relatively
>
> steep learning curve to overcome before I'll feel confident enough to do
> so.
>
> The obstacles that a new developer faces:
>
> 1. Importing River into your preferred IDE, including the tools.jar into
>
> your classpath on the correct tested jdk environment and building it.
> 2. Getting to know Rivers structure, how it all works, playing around
> with it, writing some programs that use it to improve understanding.
> 3. Getting to know how the integration tests work to improve confidence
> your not breaking anything. It'd be nice if there were some junit tests
>
> for the newer developer to improve confidence and to perform some checks
>
> before committing, unit tests could be added gradually by module and
> reduce the burden on the integration test developers. I'm bogged down
> here, I'm in the habit of using junit to assist in understanding code
> intricacies.
> 4. Becoming confident enough to tackle some of the open issues.
>
> There's heaps of documentation available regarding jini, what it is and
> supposed to do, however there's a significant learning curve before one
> can start using it.
>
> On another front, I'm interested in using it for JavaME CDC embedded
> devices, where I guess River has huge potential as these devices become
> more powerful and plentiful.
>
> I certainly want to see River succeed, it'd be a terrible shame to see
> it terminated, I think we just need to work on lowering the barriers to
> entry for new developers as an urgent priority.
>
> Perhaps a page on the website to guide new developers?
>
> Cheers,
>
> Peter Firmstone.
>
>
> Jukka Zitting wrote:
>
>> Hi,
>>
>> On Thu, Mar 5, 2009 at 9:16 AM, Niclas Hedhman <ni...@hedhman.org>
>>
> wrote:
>
>>
>>
>>> River PMC,
>>> please note that the quarterly Board report is due in a few days;
>>> Wednesday, 11 March 2009
>>>
>>>
>> We're already a bit late, so I just went ahead and filed the following
>>
> report.
>
>> <report>
>> River is aimed at the development and advancement of the Jini
>> technology core infrastructure. Jini technology is a service oriented
>> architecture that defines a programming model which both exploits and
>> extends Java technology to enable the construction of secure,
>> distributed systems which are adaptive to change. River has been
>> incubating since December 2006.
>>
>> The River project is not doing well. Practically all original
>> committers are inactive and while there are interested users and even
>> some pretty active discussions about the future of River, that
>> interest isn't showing up as patches or other more constructive
>> contributions.
>>
>> We've seen some effort towards making the QA test suite more
>> accessible, and there is interest in doing another release. However,
>> nobody is actively working on new features or bigger improvements. It
>> has been suggested that River needs a major new vision, but its
>> debatable whether that would do better as a fresh new project. In any
>> case nobody is actively pushing for anything like that.
>>
>> There is still hope for River, but at this rate the project is heading
>> for termination.
>>
>> Issues before graduation:
>>
>> * Re-activate the development community
>> * Migrate packages to org.apache.river
>> * Another Apache release
>> </report>
>>
>> BR,
>>
>> Jukka Zitting
>>
>>
>>
>
> www.sucden.co.uk
> Sucden (UK) Limited, 5 London Bridge Street, London SE1 9SG
> Telephone +44 20 7940 9400
>
> Registered in England no. 1095841
> VAT registration no. GB 446 9061 33
> Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
>
> This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucden.co.uk immediately and delete it from your computer system.
>
> We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
>
> Sucden (UK) Ltd may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden’s monitoring the content of any emails you send to or receive from Sucden. Sucden is not liable for any opinions expressed by the sender where this is a non-business email.
> The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
> This message has been scanned for viruses by Mimecast.
>
RE: Board Report is due...
Posted by Tom Hobbs <to...@sucfin.com>.
Hi Peter,
I think you're absolutely right. Here are my comments on your points;
> 1. Importing River into your preferred IDE, including the tools.jar
into
> your classpath on the correct tested jdk environment and building it.
I hope this experience will be improved when we (I) finish RIVER-301.
The tools.jar thing I believe is RIVER-272. I seem to recall someone
saying that they're looked at that and were reluctant to post their
patch or that they were intending to look at it. (I might have dreamed
that conversation though, can anyone else remember it?)
> 2. Getting to know Rivers structure, how it all works, playing around
with
> it, writing some programs that use it to improve understanding.
Unfortunately, I can't see a way around this without spending the
personal effort to actually do the reading and coding required to get
familiar. My advice, would be to pick one small area and get to know
that and then branch out into other areas as and when.
> 3. Getting to know how the integration tests work to improve
confidence
> your not breaking anything.
This is RIVER-301 again. I've got an ant script that can now run the
tests I just need to tidy it up and attach it to JIRA. It's not
perfect, but since I don't understand how the integration tests work
either, I'm having trouble making it so.
Does anyone know where I can find a complete list of all the test
categories? I don't seem to be able to find it and need it to complete
the script.
I think that the unit tests should be written for new code (someone's
writing new code?) but I doubt that there'll be much take up on writing
unit tests for existing code.
> 4. Becoming confident enough to tackle some of the open issues.
My advice is to just jump in. Pick an issue (any issue) and try to work
through it. Attach the patch to JIRA and it'll eventually get looked
at. I did this with RIVER-296 when I was in no way confident that I
understood the code I was looking at.
There are integration tests and dedicated committers who'll check
through these things and get back to you if it's not correct. No one is
going to be attacked (I hope, for my sake!) for attaching a patch that
unintentionally breaks the build or isn't a complete fix.
I hope that some of these comments (and the eventual completion of
RIVER-301) will lower the entry barrier. I'd like to reiterate my final
comment that you shouldn't be reluctant to get involved because you're
not "confident enough". Nothing improves confidence like trying to
solve a puzzle and eventually getting through it. That in and of itself
gets you part the way up the learning curve.
Cheers,
Tom
-----Original Message-----
From: Peter Firmstone [mailto:jini@zeus.net.au]
Sent: 13 March 2009 02:34
To: river-dev@incubator.apache.org
Subject: Re: Board Report is due...
Hi,
I'd like to contribute, I'm thinking about nio, SocketChannel and
SSLSocketChannel, however I'm still new to Jini, so there's a relatively
steep learning curve to overcome before I'll feel confident enough to do
so.
The obstacles that a new developer faces:
1. Importing River into your preferred IDE, including the tools.jar into
your classpath on the correct tested jdk environment and building it.
2. Getting to know Rivers structure, how it all works, playing around
with it, writing some programs that use it to improve understanding.
3. Getting to know how the integration tests work to improve confidence
your not breaking anything. It'd be nice if there were some junit tests
for the newer developer to improve confidence and to perform some checks
before committing, unit tests could be added gradually by module and
reduce the burden on the integration test developers. I'm bogged down
here, I'm in the habit of using junit to assist in understanding code
intricacies.
4. Becoming confident enough to tackle some of the open issues.
There's heaps of documentation available regarding jini, what it is and
supposed to do, however there's a significant learning curve before one
can start using it.
On another front, I'm interested in using it for JavaME CDC embedded
devices, where I guess River has huge potential as these devices become
more powerful and plentiful.
I certainly want to see River succeed, it'd be a terrible shame to see
it terminated, I think we just need to work on lowering the barriers to
entry for new developers as an urgent priority.
Perhaps a page on the website to guide new developers?
Cheers,
Peter Firmstone.
Jukka Zitting wrote:
> Hi,
>
> On Thu, Mar 5, 2009 at 9:16 AM, Niclas Hedhman <ni...@hedhman.org>
wrote:
>
>> River PMC,
>> please note that the quarterly Board report is due in a few days;
>> Wednesday, 11 March 2009
>>
>
> We're already a bit late, so I just went ahead and filed the following
report.
>
> <report>
> River is aimed at the development and advancement of the Jini
> technology core infrastructure. Jini technology is a service oriented
> architecture that defines a programming model which both exploits and
> extends Java technology to enable the construction of secure,
> distributed systems which are adaptive to change. River has been
> incubating since December 2006.
>
> The River project is not doing well. Practically all original
> committers are inactive and while there are interested users and even
> some pretty active discussions about the future of River, that
> interest isn't showing up as patches or other more constructive
> contributions.
>
> We've seen some effort towards making the QA test suite more
> accessible, and there is interest in doing another release. However,
> nobody is actively working on new features or bigger improvements. It
> has been suggested that River needs a major new vision, but its
> debatable whether that would do better as a fresh new project. In any
> case nobody is actively pushing for anything like that.
>
> There is still hope for River, but at this rate the project is heading
> for termination.
>
> Issues before graduation:
>
> * Re-activate the development community
> * Migrate packages to org.apache.river
> * Another Apache release
> </report>
>
> BR,
>
> Jukka Zitting
>
>
www.sucden.co.uk
Sucden (UK) Limited, 5 London Bridge Street, London SE1 9SG
Telephone +44 20 7940 9400
Registered in England no. 1095841
VAT registration no. GB 446 9061 33
Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucden.co.uk immediately and delete it from your computer system.
We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
Sucden (UK) Ltd may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden’s monitoring the content of any emails you send to or receive from Sucden. Sucden is not liable for any opinions expressed by the sender where this is a non-business email.
The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
This message has been scanned for viruses by Mimecast.
Re: Board Report is due...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sat, Mar 14, 2009 at 7:34 PM, Gregg Wonderly <gr...@wonderly.org> wrote:
> What I think is interesting is the continued conversation about the code. I
> am really troubled by this, because, I personally have no problems looking
> through the code and making sense of it. I don't think that the code has
> problems as much as the developers' visible APIs are not "like everyone
> elses way of doing things."
Agree. The question is then; "Why should we ask the developer to
struggle with the 'not like everyone elses'?"
My PoV is not a rewrite in the sense of chucking away all the code.
That is plain stupid, since so much effort has gone into ironing out
small and subtle corner-cases. My argument is to chuck away everything
non-conventional, and move towards accepted approaches of
embeddability and away from RMI Activation.
1. Testing;
- All tests under the main source tree.
- All tests can be run with a directive to build system.
- Break tests into unit, function/integration and specification suites.
- All unit tests are run on every build.
2. Usability in a development environment;
- Simplify development, not by creating fancy new frameworks on
top, but having "Abstract Test classes", "Maven artifacts", "Security
Usecase" and "Simple Configuration" (see point 4 and 6), so that it
becomes easy to create your own River-dependent project.
3. Architecture;
- Currently there are some cyclic package dependencies. Clean that
up and modularize the build to enforce it not to re-appear.
4. Configuration;
- Leverage existing systems on the market.
- Drop the in-house, funky programming language (if keep, then
move to an existing scripting language)
5. Transports;
- JERI becomes a separate sub-project, with its own release artifacts.
- JERI becomes the primary and supported transport.
6. Security;
- The current model is very complex, and potentially too flexible.
- I suggest to simplify a couple of common usecases.
To me, the above is more than a handful and with the current paralysis
to act, and those suggesting to act being shot down for any number of
reasons, my suggestion is that the current 2.x is 'maintenance' and a
new trunk is opened up where active development has no restrictions on
compatibility and completeness.
> Others things can be done on top of the core. The fact that so many others
> have done this speaks clearly, for me to the separation points that the
> current River/Jini APIs provide. Jini should really be viewed as a platform,
> not as a "solution" or "service".
Well, viewing ServiceDiscoveryManager as "on top of Jini" is perhaps
an too extreme position. I would toss that into the bucket of "Must
Have". In fact, *I* would like to conceptually merge -core and -ext,
but doing so by creating many individual codebase modules.
> We can also just sit around and say that rewriting it or making something
> different or forking would solve all our problems. I'm not convinced that
> those choices do anything except further fragment the concepts into even
> more ways of doing similar things with no interworking standards.
"Interworking standards" ?? Uhhh... Sorry to break it to you, dude,
but Jini is not a standard interoperability platform... ;-)
Any fork, that manages to be spec compliant should be no material
problem to the technical side of Jini. However, forks dilute resources
(people, time) and very unfortunate if that becoming the case. In
fact, seeing all these 'add-ons' is indicative to me that community
fracture was built-in to the Jini game plan from the beginning, and it
may be that we are paying the price for that right now.
Cheers
Niclas
--
http://www.qi4j.org - New Energy for Java
Re: Board Report is due...
Posted by Gregg Wonderly <gr...@wonderly.org>.
On Mar 13, 2009, at 5:41 AM, Tom Hobbs wrote:
>> Perhaps it is time to restart the Jini/River project.
>
> Although that sounds sort of tempting, it didn't work for Netscape
> and I think such an approach should be avoided.
What I think is interesting is the continued conversation about the
code. I am really troubled by this, because, I personally have no
problems looking through the code and making sense of it. I don't
think that the code has problems as much as the developers' visible
APIs are not "like everyone elses way of doing things."
Clearly there are several large bits of code, built on top of Jini,
which provide a completely different programming experience/APIs as
their visible API than the core Jini APIs. Jini APIs are, on purpose,
low level APIs designed for putting together larger functionalities
built around the concepts of secure, mobile Java code in concert with
the core features which Jini provides, namely lookup, distributed 2PC
transactions, distributed leasing and remote eventing.
Things like the ConfigurationFile implementation of the Configuration
interface, remote eventing, ServiceDiscoveryManager,
LeaseRenewalManager and others, are things built on top of the core
Jini functions to provide more convenient access to these functions
for the developer.
Others things can be done on top of the core. The fact that so many
others have done this speaks clearly, for me to the separation points
that the current River/Jini APIs provide. Jini should really be viewed
as a platform, not as a "solution" or "service".
We clearly can take a lot of different convenience functions and
useful extensions that have gelled into many of these large Jini
projects and push them back into the River project as recommended ways
to do those things.
We can also just sit around and say that rewriting it or making
something different or forking would solve all our problems. I'm not
convinced that those choices do anything except further fragment the
concepts into even more ways of doing similar things with no
interworking standards.
Gregg Wonderly
RE: Board Report is due...
Posted by Tom Hobbs <to...@sucfin.com>.
> Perhaps it is time to restart the Jini/River project.
Although that sounds sort of tempting, it didn't work for Netscape and I think such an approach should be avoided.
-----Original Message-----
From: Jeremy Easton-Marks [mailto:coachjeremyeastonmarks@gmail.com]
Sent: 13 March 2009 04:37
To: river-dev@incubator.apache.org
Subject: Re: Board Report is due...
Perhaps it is time to restart the Jini/River project. Keep the specs but
start over with new code, new testing, new approach, and with new people
taking the lead. It is a daunting task but consider the lack of progress it
may be best to take a couple of steps back and start over again, fresh.
Anybody else have any thoughts on this?
Jeremy R. Easton-Marks
"être fort pour être utile"
On Thu, Mar 12, 2009 at 10:06 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Fri, Mar 13, 2009 at 10:34 AM, Peter Firmstone <ji...@zeus.net.au>
> wrote:
>
> > I certainly want to see River succeed, it'd be a terrible shame to see it
> > terminated, I think we just need to work on lowering the barriers to
> entry
> > for new developers as an urgent priority.
> >
> > Perhaps a page on the website to guide new developers?
>
> Your message has been re-iterated many times over the last couple of
> years... :-(
>
>
> Cheers
> Niclas
> --
> http://www.qi4j.org - New Energy for Java
>
www.sucden.co.uk
Sucden (UK) Limited, 5 London Bridge Street, London SE1 9SG
Telephone +44 20 7940 9400
Registered in England no. 1095841
VAT registration no. GB 446 9061 33
Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucden.co.uk immediately and delete it from your computer system.
We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
Sucden (UK) Ltd may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden’s monitoring the content of any emails you send to or receive from Sucden. Sucden is not liable for any opinions expressed by the sender where this is a non-business email.
The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
This message has been scanned for viruses by Mimecast.
Re: Board Report is due...
Posted by Jeremy Easton-Marks <co...@gmail.com>.
Perhaps it is time to restart the Jini/River project. Keep the specs but
start over with new code, new testing, new approach, and with new people
taking the lead. It is a daunting task but consider the lack of progress it
may be best to take a couple of steps back and start over again, fresh.
Anybody else have any thoughts on this?
Jeremy R. Easton-Marks
"être fort pour être utile"
On Thu, Mar 12, 2009 at 10:06 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Fri, Mar 13, 2009 at 10:34 AM, Peter Firmstone <ji...@zeus.net.au>
> wrote:
>
> > I certainly want to see River succeed, it'd be a terrible shame to see it
> > terminated, I think we just need to work on lowering the barriers to
> entry
> > for new developers as an urgent priority.
> >
> > Perhaps a page on the website to guide new developers?
>
> Your message has been re-iterated many times over the last couple of
> years... :-(
>
>
> Cheers
> Niclas
> --
> http://www.qi4j.org - New Energy for Java
>
Re: Board Report is due...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Fri, Mar 13, 2009 at 10:34 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> I certainly want to see River succeed, it'd be a terrible shame to see it
> terminated, I think we just need to work on lowering the barriers to entry
> for new developers as an urgent priority.
>
> Perhaps a page on the website to guide new developers?
Your message has been re-iterated many times over the last couple of
years... :-(
Cheers
Niclas
--
http://www.qi4j.org - New Energy for Java
Re: Board Report is due...
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi,
I'd like to contribute, I'm thinking about nio, SocketChannel and
SSLSocketChannel, however I'm still new to Jini, so there's a relatively
steep learning curve to overcome before I'll feel confident enough to do so.
The obstacles that a new developer faces:
1. Importing River into your preferred IDE, including the tools.jar into
your classpath on the correct tested jdk environment and building it.
2. Getting to know Rivers structure, how it all works, playing around
with it, writing some programs that use it to improve understanding.
3. Getting to know how the integration tests work to improve confidence
your not breaking anything. It'd be nice if there were some junit tests
for the newer developer to improve confidence and to perform some checks
before committing, unit tests could be added gradually by module and
reduce the burden on the integration test developers. I'm bogged down
here, I'm in the habit of using junit to assist in understanding code
intricacies.
4. Becoming confident enough to tackle some of the open issues.
There's heaps of documentation available regarding jini, what it is and
supposed to do, however there's a significant learning curve before one
can start using it.
On another front, I'm interested in using it for JavaME CDC embedded
devices, where I guess River has huge potential as these devices become
more powerful and plentiful.
I certainly want to see River succeed, it'd be a terrible shame to see
it terminated, I think we just need to work on lowering the barriers to
entry for new developers as an urgent priority.
Perhaps a page on the website to guide new developers?
Cheers,
Peter Firmstone.
Jukka Zitting wrote:
> Hi,
>
> On Thu, Mar 5, 2009 at 9:16 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
>> River PMC,
>> please note that the quarterly Board report is due in a few days;
>> Wednesday, 11 March 2009
>>
>
> We're already a bit late, so I just went ahead and filed the following report.
>
> <report>
> River is aimed at the development and advancement of the Jini
> technology core infrastructure. Jini technology is a service oriented
> architecture that defines a programming model which both exploits and
> extends Java technology to enable the construction of secure,
> distributed systems which are adaptive to change. River has been
> incubating since December 2006.
>
> The River project is not doing well. Practically all original
> committers are inactive and while there are interested users and even
> some pretty active discussions about the future of River, that
> interest isn't showing up as patches or other more constructive
> contributions.
>
> We've seen some effort towards making the QA test suite more
> accessible, and there is interest in doing another release. However,
> nobody is actively working on new features or bigger improvements. It
> has been suggested that River needs a major new vision, but its
> debatable whether that would do better as a fresh new project. In any
> case nobody is actively pushing for anything like that.
>
> There is still hope for River, but at this rate the project is heading
> for termination.
>
> Issues before graduation:
>
> * Re-activate the development community
> * Migrate packages to org.apache.river
> * Another Apache release
> </report>
>
> BR,
>
> Jukka Zitting
>
>
Re: Board Report is due...
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Mar 5, 2009 at 9:16 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> River PMC,
> please note that the quarterly Board report is due in a few days;
> Wednesday, 11 March 2009
We're already a bit late, so I just went ahead and filed the following report.
<report>
River is aimed at the development and advancement of the Jini
technology core infrastructure. Jini technology is a service oriented
architecture that defines a programming model which both exploits and
extends Java technology to enable the construction of secure,
distributed systems which are adaptive to change. River has been
incubating since December 2006.
The River project is not doing well. Practically all original
committers are inactive and while there are interested users and even
some pretty active discussions about the future of River, that
interest isn't showing up as patches or other more constructive
contributions.
We've seen some effort towards making the QA test suite more
accessible, and there is interest in doing another release. However,
nobody is actively working on new features or bigger improvements. It
has been suggested that River needs a major new vision, but its
debatable whether that would do better as a fresh new project. In any
case nobody is actively pushing for anything like that.
There is still hope for River, but at this rate the project is heading
for termination.
Issues before graduation:
* Re-activate the development community
* Migrate packages to org.apache.river
* Another Apache release
</report>
BR,
Jukka Zitting