river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@marbro.org>
Subject Re: Deciding the Future
Date Tue, 09 Dec 2008 23:23:04 GMT
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.

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.

If we decide it is a good thing to break up the current starter kit in a
Jini Platform, the deployment framework and the individual services that
implements the specs there are indeed some improvements that could be
made. If people are willing to spend energy in the reorganization I
think it is possible for me to bring in the code for an Ant task I
mentioned a few times in jini-users for generating download JAR files
(this one goes a bit further than the wrapper around ClassDep, extends
Jar and has support for platforms and preferred list). If people want
for some reason want to make a Maven module out of that they can do that
too.

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.

Regards,
-- 
Mark

Mime
View raw message