----- Original Message ----

> From: Tom Hobbs <[EMAIL PROTECTED]>
> To: river-dev@incubator.apache.org
> Sent: Friday, December 5, 2008 9:24:03 AM
> Subject: RE: Deciding the Future
> 
> I can't speak for the person who made the original point - the "more
> complicated, less accessible build" bit, but when compared to other
> projects River is a more complicated project to build and test from
> source.
> 
> It might not be that the process /is/ difficult, it's just that it's
> /more/ difficult than other projects.  Maybe it has to be because River
> is unique and complicated enough that it can't work the same way as
> other projects.  I don't know.
> 
> From my experience with other projects, from Open Source to separate
> projects within my company; it's typical to check out "The Project" from
> the repository and the IDE magically presents you with a "src" and a
> "test" directory, with the right code in each.  Running the tests is
> then a simple case of right-clicking on something and selecting "Test".
> 
> (The above process is shortened for readability, if you're using
> NetBeans then much Clean-and-Building, restarting, shouting and crying
> is usually required.  :-)
>

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. Maybe even those things broken 
out into separate Ant projects with their own folders with a structure:
lib_or_component_name
-config
--config entries here
--other things
--possible other manifests to merge into the main one under src/META-INF
-src
--META-INF
---services
---manifest.mf
--packages here
-build.xml
-*.xml (ant)
-libs
-tests
--src
--libs
-docs (gets merged with top level docs at final build)
-build (disposable directory created at build time for artifacts to be kept and 
packaged from)

Then overall a main structure:
river
-build.xml
-*sub-components*
-docs (merged with sub-components docs at final build)
-libs (common libraries for entire project)
-*
-build (disposable directory created at build time for artifacts to be kept and 
packaged from..sub-componets all finally get here for massive distribution)
--classes (if this is important to some...merged everything, though manifests 
would be difficult)
-build.properties (includes some well know properties we can define such as 
build.subcomponents which can be a list of components to build automatically or 
build.ignored.subcomponents which are ones to ignore...important for continuous 
integration for non release modules)

Then each projects build.xml can follow some specific patterns, targets, etc 
and can be iterated over automatically with Ant and components can be added 
relatively easily from a project template which is kept some where versus all 
the things intermingled and broken out by build scripts. That does a few 
things, but most importantly makes things more compartmentalized/easier to look 
at and break apart, and two makes it easier for new contributors to add other 
pieces that don't interfere with the other stable and common parts or get 
intermingled. An easy to follow read me of the project structure wouldn't hurt.

Can even have custom Ant task classes if needed to help maintain the build 
structure. The first thing the build would do would be to build any needed Ant 
tasks and include them so the build scripts can automatically use them. We 
could technically have a specific ant sub directory under each project which 
these things could be done automatically so that sub components can create 
their own specific custom tasks if the need arises.

 
> The Readme that comes with the tests is easy enough to follow assuming
> you have everything setup in the right places.  Having said that, part
> of the incantation to run the tests asks for category name(s) - a
> complete list of which I couldn't find.
> 
> It would be nice (in my opinion and that's why I'm working on it at the
> moment) to have the tests in the same project as the source, using a
> common test framework (JUnit?) that the IDE can pick up and test with
> easy pointy-clickyness.  I think that this will make it easier for
> other/new developers to get involved with the River code.
>

Yes, but to have them in a different place (not subcomponent/src and 
subcomponent/tests/src above) to make it easy to split them out. Essentially 
you'll have the same packages just in different src directories so that folks 
don't have to write or keep updating build scripts just to separate tests from 
runtime logic in final libraries/jars.
 
Wade

Reply via email to