river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Easton-Marks" <coachjeremyeastonma...@gmail.com>
Subject Re: Deciding the Future
Date Mon, 08 Dec 2008 17:09:16 GMT
I have been watching the emails travel back and forth and figured I would
add my 2 cents on what I am seeing. Now keep in mind that my perspective is
from a potential developer and contributor to the River project. Since I am
new I have a clean perspective of a first time user of River.

I am impressed with the idea of River. I have been a fan for nearly a decade
now and have been keeping an eye on it. It is nice to see that a core group
of people who are so passionate about it.

I want to use River in my next major project and have posted this before but
nobody has addressed my concerns. I can guarantee you if I am having these
concerns then so other developers.

- How do I get started with River?
I have seen tutorials, and have visited the jini.org site but it looks old,
and unimpressive. Are the old tutorials for Jini still valid for the River
project? River does not seem approachable from an outside developer. This is
a shame since it will never be used if it appears to be unsupported and
complicated to use.

- What is the future of River?
I haven't seen a roadmap for development, specific future goals, or when
River is going to come out of incubation mode. This doesn't instill
confidence in River and makes it hard for me to justify using it. I don't
want to start using this amazing technology only to find out that it is
going to be dropped in 3 months when I am half way through developing with

- How do I help out?
I have joined the mailing lists, and watched emails being sent back and
forth. I have twice asked what I can do to help out and no one has
responded. I don't know what next steps I need to do to help out with River
and to help get it to the next steps.

Never to be one who presents problems without ideas for solutions here is
what I propose.

- Make River approachable.
Update jini.org, let developers know that this project is not dead. If the
tutorials, and quick start guides are not valid then update them so they are
valid. If they are valid then post that they are still valid and write new

- Define the Future of River or at least publicize it
The last update on the Apache River page is from April 27th, 2008. Granted
that is only 8 months ago but in internet time that might as well be 8 years
ago. On first glance it looks like this project is dead. A definitive
roadmap of goals, and dates need to be posted. If there isn't one then one
needs to be created. This document needs to be visible to all and constantly

- Recruit, and Promote
There needs to be a way of new potential developers to get involved. Perhaps
a mentoring program or a document that helps point them in the right
direction. If someone posts wanting to know what they need to do to help
then people should be jumping all over them to help them out.

I am willing to bet though that a lot of developers would be interested in
using River/Jini. The problem is that most developers have never heard of
either one and the ones that have believe the project is dead or have run
into the same difficulties getting started that I have. Jini/River will only
have a future if people know about it and can use it. The websites need to
be updated and documentation needs to be written to promote it. I believe
the java.net website is looking for people to write about Jini and I am sure
that other sites would be interested in the same.

If I can get started on River and feel confident about it then I will help
write, promote, and develop it.

This email is not a criticism of anyone or of River. If I didn't want River
to succeed then I wouldn't haven't spent part of my day working on it.

Once again someone please let me know what I have to do to help.

Jeremy R. Easton-Marks

"ĂȘtre fort pour ĂȘtre utile"

On Mon, Dec 8, 2008 at 10:19 AM, Michael McGrady <
mmcgrady@topiatechnology.com> wrote:

> I would organizing the build for Maven and then giving a choice of ANT with
> SVN or Maven.
> Mike
> On Dec 8, 2008, at 3:57 AM, Greg Trasuk wrote:
>> This reminds me of that quote - "Some people, when confronted with a
>> problem, think 'I know, I?ll use regular expressions.' Now they have two
>> problems".
>> I'm not in favour of Maven.  I can see restructuring the build somewhat
>> for Ant (remember, the structure really comes from being built with a
>> makefile, before there was an Ant).
>> Cheers,
>> Greg.
>> On Mon, 2008-12-08 at 03:44, Jools wrote:
>>> +1
>>> I've love to see the codebase move over to a maven build.
>>> Over the last 9 months we have moved all our projects over to maven, with
>>> great success.
>>> Our build and release procedures are greatly reduced, and getting
>>> developers
>>> up and running with their ide's.
>>> I'd be happy to Log a JIRA and take a lead on this, what do others think
>>> ?
>>> --Jools
>>> 2008/12/8 Jeff Ramsdale <jeff.ramsdale@gmail.com>
>>>  Niclas,
>>>> Once again I very much agree with you. Dan's got a good point about two
>>>> jars
>>>> (-dl and non-dl) resulting from each service component, though.
>>>> I know this will induce groans from some parties but Apache River would
>>>> really benefit from a Maven build. The dependencies between modules are
>>>> complex as is the generation of the artifacts. Maven would allow for a
>>>> restructuring that clarifies the source structure while supporting the
>>>> generation of composite artifacts. You might look into the Maven
>>>> Classdep
>>>> Plugin that Chris Sterling introduced several years ago: <
>>>> https://maven-classdep-plugin.dev.java.net/>. It could make sense to
>>>> bring
>>>> this plugin into the Apache River fold, incidentally. Use of this plugin
>>>> could also help increase uptake among the Maven developer crowd as it
>>>> simplifies the generation of artifacts for Jini services.
>>>> A huge benefit of a Maven-based build is the ability to generate
>>>> metadata
>>>> for most of the popular IDEs. This has proven to be incredibly useful on
>>>> my
>>>> teams and allows for a multiplicity of IDEs to be used against the same
>>>> codebase.
>>>>  --
>> Greg Trasuk, President
>> StratusCom Manufacturing Systems Inc. - We use information technology to
>> solve business problems on your plant floor.
>> http://stratuscom.com
> Michael McGrady
> Senior Engineer
> Topia Technology, Inc.
> 1.253.720.3365
> mmcgrady@topiatechnology.com
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message