I like the following organization:
build.xml
src
build.xml
module A
build.xml
module B
build.xml
module C
build.xml
test
build.xml
class
jars
build.xml
jar1.xml
jar1
some
resource
stuff
jar2.xml
release
lib
test
build.xml
All the compiled classes go under class, where I use the genjar task to
divide them up in jars. The definition of what the jars are stored
under the jars directory, in their individual build files. If there are
resources, they go under the jars directory in a directory of the same
name as the jar.
This way, all the source is centralized under the root, packaged into
individual module directories which contain multiple classes and
packages - even the test source. The test directory is where the test
scenarios are run.
It's worked for me for about a decade (except I was using make back
through
most of it), and is almost identical to the
structure I found when I started working with 600 other developers (in
various languages) when I went to work for 30,000 person organization.
----- Original Message -----
From: "Greg Hassan" <[EMAIL PROTECTED]>
> Our current repository (StarTeam) is poorly organized and makes it
almost
> impossible to automate our builds. Our product is divided into three
> separate packages, each one distributed as two JARs (one source code,
and
> one for classes). I would like to separate our test code, non-code
resources
> (i.e. PDF documents) and unused code from production code.
>
> Below is an example of the structure I am considering:
>
> --- BEGIN DIAGRAM ----
> projectx
> implementation
> production
> package-A
> subpackage-A1
> src
> subpackage-A2
> src
> package-B
> subpackage-B1
> src
> testing
> package-A
> subpackage-A1
> src
> subpackage-A2
> src
> package-B
> subpackage-B1
> src
> unused
> package-A
> subpackage-A1
> src
> subpackage-A2
> src
> package-B
> subpackage-B1
> src
>
> --- END DIAGRAM ----
>
> the build should result in 6 jar files created:
> package-A.jar, package-A-src.jar
> package-B.jar, package-B-src.jar
> package-c.jar, package-c-src.jar
>
> Can anyone provide feedback and illustrate benefits and drawbacks to
the
> above solution?
>
> Thanks.
> Greg
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
