river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jools <jool...@gmail.com>
Subject Re: Deciding the Future
Date Wed, 10 Dec 2008 10:28:14 GMT
2008/12/9 Mark Brouwer <mark.brouwer@marbro.org>

> 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).
> I fail to see the need for Maven here too, the River codebase has no
> dependencies on anything else but J2SE 1.4. If people want to have
> artifacts published I can see the value of that.

Not sure that argument stacks up to be honest. Just because we don't have a
huge external dependency graph, it does not mean that building the project
using maven is not applicable.
if we break the codebase up into separate components, then they will have a
dependency on each other.

Can you be more specific ?

> I personally don't have that much problems with the build (only takes me
> 3 times to find the right target :-) ) and given the fact the test
> framework is not a unit test framework but a test framework to test
> controlled deployed services I don't see the need to shoehorn those into
> JUnit. Of course JUnit for unit testing is fine. Testing service
> deployments from within an IDE gives me the shivers anyhow, it seems to
> result too many times in troubleshooting codebase problems and when you
> get it working, the same test seem to fail outside the IDE.

Personally, I hate having to work on the source tree. It's cluttered, and
difficult to work on.

As for the JUnit tests, I'd be inclined not to run service tests from the
basic builds but create a set of integration tests used once the build is
The Junit tests which come as part of the build should really test local
functionality, and mock where possible IMHO.

> I'm hesitating though to break up the Jini source, given the current
> participations of those who should oversee this project and lack of
> their response. I'm mainly interested in enhancements in the codebase,
> things really lacking in the core such as lookup discovery and proxying
> over HTTP which will be very hard work to get in. So far it seems hard
> to get even patches reviewed (RIVER-160, RIVER-296, anyone) and at the
> same time people are proposing large changes or ideas. For many of the
> things I hear I wonder whether these are not already 'solved' by
> projects based on River (or most likely the JTSK codebase). And I fail
> to see why River should be the vehicle for all that.

I see comments on this list all the time about things which are being worked
on, but I never see anything new.
Dennis Reedy came up with a patch to move us away from the com.sun
namespace, something I think we should do ASAP BTW, but others had code they
were working on which they didn't want to change.
However, I've not seen any of these checked in since. (I may be wrong)

I'd love to see some of the new features you mentioned, and if I could use
them by simply added a new dependency to my project and some config, then
I'd be happy.
Rather than sifting through a load of jars in a tar ball I downloaded from
the website.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message