Jon Steven wrote:
>
> You also don't have the source code available to this
> system available anywhere I can see. :-(
It currently is ugly shell script, but it the URL as my future intentions
have been posted a number of times. Here's perhaps the first attempt to be
comprehensive about it.
It did not trigger much in the way of dicussion at the time.
- Sam Ruby
---------------------- Forwarded by Sam Ruby/Raleigh/IBM on 11/27/2000
10:51 PM ---------------------------
Sam Ruby/Raleigh/[EMAIL PROTECTED] on 06/16/2000 09:43:48 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Composing a system out of projects
Disclaimer:
I'm intentionally publishing this as work in progress. Don't get hung
up on the fact that the current implementation is using shell scripts or
on the name of the URLs. I'm looking to get feedback to influence the
evolution of this work. Also note that the initial focus is Apache,
Java based projects. I expect this to expand over time.
Also forgive the cross-posting, please direct any discussion to ant-dev.
Vision:
I would like to see us get to the point where a user can design their
own custom system. Simple example: building a system consisting of
JetSpeed plus Cocoon. Users should be able to specify this using either
the command line or a system.xml file. This system.xml would reference
projects, and the build system (presumably based on Ant) would order the
building of projects much in the same way that the current Ant orders
the execution of targets.
Project.xml files would be checked into the same cvs tree as the source,
and would essentially be declarative. At a minimum, they would describe
what projects they depend on, and what outputs (typically jar files) are
produced. Optional overrides for such things as the default target and
name of the destination directory should be supported. These
project.xml files could also either contain the build instructions
directly, or delegate to an existing build.xml via an <ant> task.
Build.xml files would essentially remain as they are today. Some
enhancements are discussed below.
Progress:
You can see the current state of evolution of this at the following
URLs. These are set up to update nightly at 1:00 a.m. EDT, and may be
updated at other times if I run the script manually. Per the disclaimer
above, I realize that everything should be converted to Java and XML
(both the inputs and outputs), but I chose to do it the "hard way" first
so that I could understand the issues.
Without further ado, here are the URLs:
Script:
http://oss.software.ibm.com/developerworks/opensource/jakarta/buildall.html
Log:
http://oss.software.ibm.com/developerworks/opensource/jakarta/buildlog.html
Output: ftp://[EMAIL PROTECTED]/
Todos:
In addition to the parsing of the new XML elements and ordering of
projects, the highest priority items as I see it deal with the
processing of jar files. We need a standard way to modify the class
path when executing a nested build.xml - this internally could either be
based on java fork=yes, or on a custom class loader. Additionally I
would like to see a new task which scanned the classpath and copied the
actual jar files used in the build process to the destination directory;
today most projects will happily compile with your choice of
dependencies, then copy the developer's (possibly incompatible) choice
of jar files to the destination directory.
I'd also like to see a global approach to the choice of compiler, debug
options, and the like. And other user level choices like whether the
javadocs or source are to be part of the custom distribution. Many
projects also can conditionally compile in support for other projects,
so following the lead of many install programs, I would like a
project.xml be able to define "minimal", "typical", and "full"
configurations.
Longer term, a GUI front end, and back ends which produce installable
images.
Ok, that should be enough to get the discussion started...
- Sam Ruby
