On 8/5/01 11:21 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> 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:
I agree with you :-) I haven't really done any work on the engine per se in
quite a while, I've basically been playing with the XML files which is
why I asked for the repository descriptors.
> 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.
I think all you should need is a gump.properties file for your machine setup
and a profile for what you want to build. I don't think there's a need for a
workspace descriptor at all.
> 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.
I have been trying to use Gump to build the TDK for close to six months
now,I can get it to work. It's the configuration that's a PITA because the
workspace was bound to your machine. If you remember I sent a (somewhat
crude) set of patches that allowed a set of properties to be fed into the
workspace so that it would make it easier for me to build the TDK. It worked
but you wanted to use an XML description and the patches were never applied.
We discussed this briefly, you said I shouldn't give up just because the
patches weren't applied, yada yada yada ... and I haven't given up I just
really don't like XSL and the config issues just became overly irritating
(not insurmountable by any means) but I have slowly been trying to help with
this.
I am totally into helping with Gump and I will definitely help over the next
while and give you some constructive feedback because I would really like to
integrate it into my daily cycle of testing. And I am interested in making a
build system based on gump/jjar that every project can use.
> Then go back to your rewrite. I'll even help.
Deal :-)
> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
