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-turbine-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:[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]>
