Jason Van Zyl wrote: > > 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. > > This point will be moot once the Gump descriptor is created from the > Maven project descriptor. They will always be accurate.
As long as the process can be bootstrapped, I'm willing to work with it. Example: I used to build and execute your jar fetcher process from the tdk until the dependencies became circular. >> 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. Trust me, I have been following this closely for some time. What you describe only represents a small percentage of the issues identified. > 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. There is no reason to keep the number of contributors constant. >> 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. Perhaps a better example would be Avalon. Avalon has been hightly dynamic and hightly responsive. > 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? I would prefer a process that bootstraps - i.e., build maven's dependencies. Build maven. Execute maven. Incorporate the dependencies. Continue on. I realize that some invention would be required to make this all work, but I am willing to do my half of the bargain. > 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. I don't follow. Can you provide an example? > 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. Cool. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
