river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Ramsdale" <jeff.ramsd...@gmail.com>
Subject Re: Deciding the Future
Date Mon, 08 Dec 2008 08:12:05 GMT
Once again I very much agree with you. Dan's got a good point about two jars
(-dl and non-dl) resulting from each service component, though.

I know this will induce groans from some parties but Apache River would
really benefit from a Maven build. The dependencies between modules are
complex as is the generation of the artifacts. Maven would allow for a
restructuring that clarifies the source structure while supporting the
generation of composite artifacts. You might look into the Maven Classdep
Plugin that Chris Sterling introduced several years ago: <
https://maven-classdep-plugin.dev.java.net/>. It could make sense to bring
this plugin into the Apache River fold, incidentally. Use of this plugin
could also help increase uptake among the Maven developer crowd as it
simplifies the generation of artifacts for Jini services.

A huge benefit of a Maven-based build is the ability to generate metadata
for most of the popular IDEs. This has proven to be incredibly useful on my
teams and allows for a multiplicity of IDEs to be used against the same


On Sun, Dec 7, 2008 at 6:34 PM, Dan Rollo <danrollo@gmail.com> wrote:

> 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

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