river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Hobbs" <tom.ho...@sucden.co.uk>
Subject RE: Deciding the Future
Date Fri, 05 Dec 2008 14:24:03 GMT
I can't speak for the person who made the original point - the "more
complicated, less accessible build" bit, but when compared to other
projects River is a more complicated project to build and test from

It might not be that the process /is/ difficult, it's just that it's
/more/ difficult than other projects.  Maybe it has to be because River
is unique and complicated enough that it can't work the same way as
other projects.  I don't know.

>From my experience with other projects, from Open Source to separate
projects within my company; it's typical to check out "The Project" from
the repository and the IDE magically presents you with a "src" and a
"test" directory, with the right code in each.  Running the tests is
then a simple case of right-clicking on something and selecting "Test".

(The above process is shortened for readability, if you're using
NetBeans then much Clean-and-Building, restarting, shouting and crying
is usually required.  :-)

The Readme that comes with the tests is easy enough to follow assuming
you have everything setup in the right places.  Having said that, part
of the incantation to run the tests asks for category name(s) - a
complete list of which I couldn't find.

It would be nice (in my opinion and that's why I'm working on it at the
moment) to have the tests in the same project as the source, using a
common test framework (JUnit?) that the IDE can pick up and test with
easy pointy-clickyness.  I think that this will make it easier for
other/new developers to get involved with the River code.

And that's what I think is meant by "more difficult, less accessible"
and "barrier to entry".



-----Original Message-----
From: Dan Creswell [mailto:dan@dcrdev.demon.co.uk] 
Sent: 05 December 2008 11:23
To: river-dev@incubator.apache.org
Subject: Re: Deciding the Future

Jeff Ramsdale wrote:
> On Mon, Nov 24, 2008 at 4:02 PM, Jukka Zitting
<jukka.zitting@gmail.com> wrote:
>>> But is there a step beyond that, beyond the here and now which is
>>> direction "the community/project" should be taken to salve
>>> itches?
>> That's perfectly valid, and all projects should have those
>> every now and then. I'm just worried that currently there doesn't
>> to be too many people in River who'd actually start implementing any
>> of the proposed changes.
> Have you tried to make changes to Jini? In an IDE (I use Eclipse)? I
> would love to try to participate in Apache River development, but I
> have never run across a more complicated, less accessible build! The
> barrier to entry is significant...

Can you explain more about this?

I don't recall having any problems but I'm an old-timer.....

> -jeff

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.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message