Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Users List" <ant-user@jakarta.apache.org>
Date: Mon, 19 Nov 2001 21:36:39 +1100
From: Jeff Turner <jeff@socialchange.net.au>
To: ant-user@jakarta.apache.org
Subject: [POLL] jakarta-ant-templates (Generic Ant-based project templates)
Message-ID: <20011119213639.A2556@socialchange.net.au>
Mail-Followup-To: ant-user@jakarta.apache.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.23i

Hi,

I was wondering, how do people feel about developing "common",
"universal", "generic" build.xml scripts for common needs?

I have hordes of mini-projects on the go, the end result of each is:
 - a jar file
 - some javadocs
 - some config files
 - the above all packaged as a .tar.gz and .zip


My very first build.xml was copied from an Apache project, and hacked to
meet my needs. Subsequent projects were all cut-and-paste affairs. Over
time, as I noticed that most projects are pretty similar, I formalized
this by creating a "generic" build.xml, and an associated template
project structure.

This system has been working nicely for many months.  Project-specific
customizations are all kept to an external build.properties file, which
allows the build.xml to evolve independently.

I'm sure other people have evolved similar solutions. Sooo.. how about
evolving some _shared_ solutions?

Of course, what constitutes a "good" build.xml is extremely subjective,
and even if the scope is strictly regulated I doubt we could reach
"consensus". Multiple solutions are fine with me. But *whatever* we can
achieve together is better than what we can achieve independently.

The big winner should be newcomers, who just want to get their code
building. They can now download a "turnkey" solution; plug your code in
and go :) Ant gains new users, and today's newbies are tomorrow's
contributors.


So what I'd like to know from y'all:

1) Does this sound workable? (and for what definition of "this"?)
2) Do you have a generic build system to contribute?


If there's critical mass, let's wander off and form a sourceforge
project to discuss it; come up with categories, associated solutions,
document pros and cons; then come back here and twist arms until they
let us form a jakarta-ant-template subproject :)


To get the ball rolling, I've put up my attempt at:

http://opensource.socialchange.net.au/build/

I've attached -projecthelp output at the end, to give you a brief idea of what
it does. But let's discuss the general concept on this thread, rather than my
implementation.

Looking forward to everyone's comments :)


--Jeff


jeff@expresso:~/sco/share/doctype$ ant -projecthelp
Buildfile: build.xml
Default target:

 main           Main (default) target

Main targets:

 clean          Cleans the build result.
 compile        Compiles the source code
 compile-tests  Compile the unit tests
 dist           Create a distribution with documentation
 dist.lite      Create a minimal distribution with no documentation
 dist.tgz       Creates a .tar.gz distribution
 dist.zip       Creates a zipped distribution
 docs           Build the non-javadoc docs
 jar            Creates a jar of the code
 javadocs       Creates the API documentation
 main           Main (default) target
 prepare        Prepare the directories
 prepare-tests  Create minimal unit test directories
 test           Run the unit tests
 test-report    Run the unit tests and generate HTML reports

Subtargets:

 clean-test
 copy-bin
 copy-conf
 copy-docs
 copy-licenses
 copy-resources
 ctags
 define-tokens
 docs_check
 docs_delegate
 init
 javadoc_check


BUILD SUCCESSFUL

Total time: 1 second


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