Jason van Zyl wrote:
>
> 1) Could we make the whole process an Ant task?
http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/antgump/
> 2) Project descriptors need to be normalized, the project file is really a
> set of targets. Right now there is a top level project and nested projects
> in a project XML descriptor. I would like to be able to readily convert the
> XML descriptors into java objects and this makes it difficult. So the
> project XML descriptor should actually look more like the build.xml file for
> a project. Maybe we could eventually move toward using a projects build.xml
> file for the descriptor if we got a little more standard.
The are not just targets, often they have their own dependencies, and quite
often completely different build.xml files. In many cases
(jakarta-commons), they essentially *ARE* multiple projects in the same cvs
repository.
I don't see how this makes conversion into java objects harder. And if it
helps, the current gen.java code already unnests and flattens this into a
list of independent projects already. Perhaps you could use that as your
starting point? If you run the "gen" script, this intermediate result is
output in the work directory as "merge.xml".
> 3) Allow a directory with overriding repository descriptors, so that your
> customized configuration matches the form of the anonymous access repository
> descriptors. Again so that it's easier to convert the XML to a Java object.
I don't know what you intend by "a directory" of overriding repository
descriptors. What I was thinking of was a simple "tag" attribute on a
project definition which would override the tag attribute on the cvs line.
This would allow the default version to be defined at the project level,
and optionally overridden at the profile or workspace level.
In fact, I just committed the code. I'm sorry that this is in the section
which has not been converted to java yet, but it is functional; and all
things in good time.
> 4) Use ${lib.repo} as defined in ~/build.properties as the place to look for
> external jar files so that we can remove that info from the workspace.
I already made the suggestion that I should have default directory defined
in the workspace (and that you can certainly generate a workspace on the
fly from a properties file, if that is your desire); but I sense that there
is a more fundamental disconnect here.
If I understand your proposal correctly, this would be a flat directory
into which one places all of the jars that one might depend on. What I was
envisioning was a directory in which one unpacks - into subdirectories -
each of the things one might "install", such as JAAS, JDBC, JMS, ... or
perhaps even Ant. These installations are likely to have an internal
directory structure.
> 5) Make it so that updating the gump repository doesn't affect a local setup
> so that I can get any new dependency information and just build again.
Either I don't follow, or this is already possible today. I can certainly
do a cvs update of gump, gen, and build of the project desired without
requiring anything in that project to be updated.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
