Niclas Hedhman wrote:
On Sat, Dec 6, 2008 at 8:31 PM, Wade Chandler
<[EMAIL PROTECTED]> 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
