Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Users List" <user@ant.apache.org>
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337022B15CC@mail.sandvine.com>
From: David McTavish <dmctavish@sandvine.com>
To: 'Ant Users List' <user@ant.apache.org>
Subject: RE: Directory structure best practices
Date: Wed, 24 Sep 2003 17:12:49 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"


We use a hybrid with the emphasis on distinct separation of projects based
on functionality provided. In your example, HumanResourcesProject and
PayrollProject would definitely be peer top-level projects.  That said,
these projects MAY contain several independent components within their
respective projects (ie: perhaps the HR contains server and client code that
is separated by package scope). Also, this allows us an easier means of
refactoring code into 

The overhead in supporting this structure has proven to be fairly minimal,
and the flexibility gained has been extremely beneficial. Don't
underestimate the ability to independently release projects, or be able to
test interoperability between varying versions.  Fowler has some good ideas
in general, but I believe that is what you need to view them as, just ideas.
Extrapolate and take the ones that are suited to your own needs, and you
should result in a reliable build environment.


Regards,
d.


-----Original Message-----
From: Kyle Adams [mailto:kadams@gfs.com]
Sent: Wednesday, 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/WhyYouCantCreateMultipleArtifactsInOneProject
)

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