ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob van Oostrum" <li...@springwellfarms.ca>
Subject RE: Directory structure best practices
Date Wed, 24 Sep 2003 22:34:22 GMT
Actually what Fowler's saying about maintaining a single source point is
something completely different from what you seem to be suggesting. All it
means is that everything necessary to build an application on a clean box
should be stored in one configuration management environment (e.g. CVS). In
no way does Fowler say that everything should be within one CVS module (to
use CVS as a concrete example), just that everything necessary to perform a
build should be accessible using one single command. One possible scheme
that I've used that is perfectly consistent with this looks something like
this:

- build
  build.xml
- module1
  build.xml
  + src
- module2
  build.xml
  + src
- module3
  build.xml
  + src
- all (an ampersand module defined in the CVS module file as consisting of
build, module1, module2 and module3)

So a single 'cvs checkout all' would give me all 3 modules necessary to
build my application. Each module (except build) has its own source tree and
the build module contains a build file which triggers the module builds and
does whatever else needs to be done to complete the overall build. All this
is still consistent with Fowler's single source point principle.

The issues that Fowler addresses concerning splitting up modules on the
storage structure level are valid IMO. In other words: don't use multiple
CVS modules unless you really really need to (i.e. you need the freedom to
build your application from version x of component A and version y of
component B). In all other cases, use package separation and clever
buildfile writing. From personal experience, very large applications tend to
favor the multiple module approach (if for no other reason than making it
very very visible where the seperation between modules lies). This resembles
the approach that Maven appears to favor (each module would have a single
output, i.e.  a jar/war/ear). My guess is the optimum is somewhere in that
big grey area. As a man I used to work with would answer any question
(including the seemingly obvious yes/no ones): it depends ...


Hope this helps
Rob



> -----Original Message-----
> From: Kyle Adams [mailto:kadams@gfs.com]
> Sent: September 24, 2003 4:47 PM
> To: user@ant.apache.org
> Subject: Directory structure best practices
>
>
> This subject has been covered in previous threads, most notably:
>
> http://marc.theaimsgroup.com/?l=ant-user&m=104492657316475&w=2
>
> I would like to discuss the various approaches highlighted in this
> e-mail.  For convenience, I'll be copying examples from the
> initial e-mail
> in the  thread above, though I would recommend reading through it.
> As I see it, the four approaches (letters a-d) are essentially
> variations on
> two different build philosophies.
>
> The first philosophy (largly exemplified in a and b) states that within
> a sufficiently large project, each subproject has it's own build
> directories (source, test, build, etc.).  This is also the approach
> Maven takes, attempting to limit projects to one artifact (ie, JAR, WAR,
> EAR, etc.) per project (see
> http://wiki.codehaus.org/maven/WhyYouCantCreateMultipleArtifactsIn
> OneProject)
>
> Example:
> -Projects/
>   -HumanResourcesProject/
>      build.xml
>     +bin/
>     +build/
>     +src/
>      (etc)
>   -Payroll/
>      build.xml
>     +bin/
>     +build/
>     +src/
>      (etc)
>   -PensionsAdmin/
>      build.xml
>     +bin/
>     +build/
>     +src/
>      (etc)
>    (etc)
>
> The second build philosophy is most apparent in letter d.  This approach
> specifies that the parent has the combined set of build directories and
> subprojects are only separated out in the java packaging structure.
>
> Example:
>
> -Projects/
>   -HumanResourcesProject/
>      build.xml
>     +bin/
>     +build/
>     -src/
>       -java/
>         -com/
>           -domain/
>             -hrproject/
>               +payroll/
>               +pensionsadmin/
>               +hrutilities/
>                (etc)
>       +webapp/
>       +conf/
>      (etc)
>
> So my question - in the Ant user community's experience, which approach
> works better for very large, complex projects?  Maven favors the "each
> subproject is pretty much independent", but it seems like that's a
> violation of Martin Fowler's "Single Source Point"
> (http://www.martinfowler.com/articles/continuousIntegration.html#N4000B9)
> principle.  On the other hand, if you want to be able to do independent
> release management (ie, version tagging, branching, etc.) of the various
> subprojects, it would almost seem to be a necessity to keep them
> separate.
>
> Perhaps some of this discussion could also supplement/take place on
> ElementsOfAntStyle
> (http://nagoya.apache.org/wiki/apachewiki.cgi?TheElementsOfAntStyle)?
>
> Thanks,
> Kyle
>
> _____
>
> Kyle Adams | Java Developer  |  Gordon Food Service  |  616-717-6162
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message