On Mon, Nov 19, 2001 at 09:36:39PM +1100, Jeff Turner wrote:
> I was wondering, how do people feel about developing "common",
> "universal", "generic" build.xml scripts for common needs?
i've had this exact need.
> 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.
guess what i did this weekend :) my idea was to also supply
a skeleton generator, which would prompt for some
project-specific information, and perform mangling of the
template (token substitution), the end result being a
compilable skeleton app.
> 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.
i think we should focus on the ultimate goal, which as i see
it woudl be is creating a userfriendly framework for providing seamless,
no-effort builds of redistributable distributions.
anything not contributing to this would be out of scope.
> 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
one addition i'd want:
'fetch-build-depends'
- download application build dependencies
used Debian Linux's apt-get build? the
very same idea.
the reason being that i don't generally put JARs except
required to bootstrap the build system into
source control systems, being of the pristine source
school.
regards,
leon.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
