On Mon, 2002-02-25 at 11:58, Scott Sanders wrote: > Couldn't you just put the descriptors in CVS and then give an href to > Gump?
I think it's better that the project give the info rather then gump take it. Again, responsibility at the project end. The name of the reference would change constantly if you used hrefs generated by viewcvs. Gump would also need to be modified. I would prefer something that could work today. > 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]> -- 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]>
