ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@us.ibm.com>
Subject Composing a system out of projects
Date Tue, 28 Nov 2000 03:53:27 GMT
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/IBM@IBMUS on 06/16/2000 09:43:48 AM

Please respond to pmc@xml.apache.org

To:   ant-dev@jakarta.apache.org
cc:   pmc@jakarta.apache.org, pmc@xml.apache.org
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://anonjakarta@oss.software.ibm.com/

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





Mime
View raw message