How about "gref"s for gump references (descriptors relative to gump home) and hrefs for true hrefs (e.g. "file://" or "http://";). Gump hrefs, right now, make assumptions as to where the files are located, I believe. I haven't looked at the code for expanding hrefs and the XSL for formatting those files in a while so this may already be addressed.
Cheers. -Naresh -----Original Message----- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 8:59 AM To: Alexandria Developers List Subject: RE: Time for jakarta-gump? (was project files in project CVSes?) Couldn't you just put the descriptors in CVS and then give an href to Gump? Scott > -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 25, 2002 8:18 AM > To: Alexandria Developers List > Subject: Re: Time for jakarta-gump? (was project files in > project CVSes?) > > > On Mon, 2002-02-25 at 10:20, Sam Ruby wrote: > > Jason van Zyl wrote: > > > > > >> I do believe that it is important to keep on top of > cross project > > >> dependencies. > > > > > > I suppose it's merely a dispute over frequency. I > occasionally, say > > > every two weeks, do something like a Gump build to eyeball things. > > > > Forgive me, but... > > > > Turbine hasn't built clean with Gump for over a month. > > This is because the Gump descriptor for Turbine has no direct > correlation to Turbine. It's a data entry job to keep it in > sync and I'm not interested in that approach. I'm more > interested in an integrated approach that ensures accuracy > from the project side. > > The question I have > > is whether this would improve or degrade by reducing the frequency? > > This point will be moot once the Gump descriptor is created > from the Maven project descriptor. They will always be accurate. > > > I must also admit to a bit of scepticism with respect to the claims > > made to Maven given this state. > > Fair enough, again I have to ardently stress that Gump not > being able to build a project is not an indication of > dissolution. The problem is the disconnect between the real > project information and the information in the Gump descriptor. > > And this is important because I disagree with you that you > will be able to stay on top of a list of packages that grows > to something to the scale of CPAN. There is just no way. > > > By contrast, I know that the Tomcat team(s) run their own > builds using > > their own processes, and rarely see Gump failures. > > They more than likely don't change dependencies often, or the > layout of the project. The Turbine build usually doesn't > build because the dep information isn't correct not because a > project that Turbine relies on has changed their contracts. I > hope to change this and I'm trying to make the Turbine Gump > builds work but I am not going to try and manually keep track > of 10 descriptors. > > > These teams, by > > contrast, are the most appreciative of the value add the Gump > > provides. > > > > I'd love to see you prove me wrong... > > All right. We'll start with this then: > > http://cvs.apache.org/viewcvs/jakarta-turbine-maven/jakarta-tu > rbine-maven.xml?rev=1.1&content-type=text/vnd.viewcvs-markup > > This is produced by Maven, taking a Maven descriptor and > converting it to a Gump descriptor. So I have a couple issues > I'd like to deal with. > > 1) How would you like these descriptors to arrive for use in > Gump. I would prefer not to mail in a patch, I would just > like to be able to push it somewhere for you to use. Or I > could automatically check it in to cvs. I haven't tried Tim > Endres cvs client lib but I could give it a shot. Thoughts? > > 2) The other issue is the the way Gump embeds projects inside > one another. Currently Maven depends on GNU regexp (we're > working on removing it) and wanted to know if a project > descriptor could be setup this instead of embedding the > project definition. The same issue is present in the Turbine > 2.x descriptor (webmacro, freemarker, helma > xmlrpc) So can I break out the embedded projects and make > descriptors for them that live on their own? So that they can > be reused? I want to add support back in for webmacro and > freemarker in Turbine 3.x so I would rather not define the > project in each project. I assume I can just break them out. > > If we can work this out then I will start sending you > accurate descriptors and we'll change the way Turbine > generally behaves with Gump. > > > - Sam Ruby > > > > > > -- > > To unsubscribe, e-mail: > <mailto:alexandria-dev-> [EMAIL PROTECTED]> > > For > additional commands, > e-mail: > > <mailto:[EMAIL PROTECTED]> > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://tambora.zenplex.org -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
