river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Rollo <danro...@gmail.com>
Subject Re: Deciding the Future
Date Mon, 08 Dec 2008 02:34:30 GMT
Niclas Hedhman wrote:
> On Sat, Dec 6, 2008 at 8:31 PM, Wade Chandler
> <hwadechandler-apache@yahoo.com> wrote:
> 
>> Looking over the build scripts, src directories, and other resource directories,
too the structure could be better laid out. For instance, there is a top level build.xml,
then below in src there is build.xml. Too, under src there are folders for manifest, configentry,
and then the Java packages are right there. There could be better separation.
> 
> Under TDD mantra this is a red flag; If it is hard to set up tests,
> then it is hard to work with the codebase.
> 
> And from my experience, that is exactly what comes to mind, and the
> way to get something up within a day is the "Launch All" convenience,
> which is more like a End-User Application than a system development
> kit.
> 
> Well, I still think that there are a lot of room for improvement, and
> instead of telling "each other"/"others" what should be done, I think
> it is time for us to move into action. The main problem I have is that
> there is need for a structural make-over, which is not suitable for
> small and evolutionary steps. Can we agree to open up a new branch?
> 
>  - Modularized into one 'module' per 'artifact'.
>  - Adoption of sound architectural principles.
>  - Testcases as near as possible to the code under test.
>  - JUnit as test framework.
>  - "Doers decide", i.e. "you don't like it, step up..."
> 
> 
> Cheers
> Niclas

I really like the sound of this. One thought: We may find a need to bend 
the 'module' per 'artifact' rule in the case of <module>.jar and 
<module-dl>.jar - where <module.jar> is a superset of the content of 
<module-dl>.jar (which contains only downloadable interfaces...). Then 
again, maybe not...

I expect the kind of structure you mention would also help make 
dependencies clearer - and with that in mind: We may also want to 
consider another explicit packaging principle:
"avoiding duplication of jar content where possible".
I hope this would lead to a tree where we can more clearly see which 
jars depend on which (and also make it easier to publish artifacts for 
repos like maven, et al...). The tricky part to me again is handling 
<module>.jar and <module-dl>.jar in a clean way. Given that a typical 
client must depend on classes in <module-dl>.jar, but also the client 
must NOT have <module>.jar on it's classpath, lest it break Jini's 
"mobile code" behaviors.

I noticed you created a branch (which I'm guessing is for POC of this 
sort of work). Could you send out an email when you have such a branch 
ready enough for others to tinker with?

Dan


Mime
View raw message