Jason van Zyl wrote:
>
> Could we move toward having repository descriptors instead of having cvs
> tree information repeated in files like rubix.xml and rubypad.xml? I
think
> this pattern is more normalized and would help me get my java version of
> gump working.
Done.
> Right now we have repository descriptors for dbxml, devworks, exolab and
> sourceforge. Could we add ones for jakarta, apache xml, tigris,
> whichever.com, the jdom repo, and the mozilla repo. I can whip these up,
but
> I'm not sure if gump will work with them yet.
It is easy enough to test. Run gen.{bat,sh}. Diff the generated scripts.
All you need is JAXP 1.1 and a JDK.
The problem I wanted to solve first (done) was the ability of workspaces to
override selected portions of the repository definition. The default
definition for jakarta is to use anoncvs. I prefer to use rubys. You
might prefer jvanzyl.
> If we can start work again on a format for project files and make a dtd
it
> would definitely make it easier for me to merge my java code with your
> existing work which is what I would like to do. Slowly move toward a java
> version of gump.
I find it fascinating that everybody focuses on the implementation of the
engine, but the area that really matters (IMHO) is the DTD. Examples of
areas where I see potentials for improvement:
1) The key difference between workspaces is where to find the installed
components. On my machines these tend to all be installed in a common
directory. The size of the workspace definition could be reduced
significantly if the name of the common directory was part of the workspace
definition, and the subdirectory information was factored out into the
project definitions.
2) More projects are adopting the convention of allowing the person
executing the build to specify the jarpath to specific jars. If I were to
allow <depend> elements inside an <ant> definition, with an additional name
and optionally id attribute, then I could reduce the amount of effort
required to produce such project definitions.
3) Home is misnamed. For buildable projects, this should probably be named
something like results, with the <jar> elements nested inside. For others,
I'm not sure what to name the element, but perhaps results would do.
4) There probably should be a way to do indirection on dependencies.
Instead of expressing a dependency on xerces, one should be able to depend
on one's favorite JAXP 1.1 and SAX 2 compliant parser. Or add to your
dependencies whatever velocity or stylebook2 happens to depend on.
I'm pretty confident that my next suggestion will be ignored, but I will
give it anyway: take a break from rewriting the engine. Spend a few
minutes actually trying the current implementation - even as a black box.
See what you like or don't like about it. Change what you can. Let me
know what you feel needs to be changed but don't feel comfortable (yet)
doing by yourself.
Then go back to your rewrite. I'll even help.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
