river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Deciding the Future
Date Sat, 06 Dec 2008 12:31:25 GMT
----- Original Message ----

> From: Tom Hobbs <tom.hobbs@sucden.co.uk>
> 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


Mime
View raw message