How interesting, quite a few projects have managed to do it. In fact I think we've not had very much trouble getting POI to build in it in months. And really GUMP helped us test out some flaws in our dependencies (improper dependency directly on log4j which was rapidly changing its interfaces) and drastically improve things (partly by switching to commons logging -- poi-user's are raving about it -- its wonderful). I agree the documentation could be better, and perhaps if you're having trouble you should work to improve the documentation. I'm a documentation fascist so I completely agree documentation is important, but I think its up to each contributer in the community to work on it. On the POI project we have an unofficial policy of not blessing things into an official release unless they are sufficiently documented and unit tested.
I've not had much direct interaction with GUMP (others on the project have done that fine work) but I will shortly (probably going to push for it at work....we REALLY need it). I think that GUMP's pain pays off more than it costs. Say I want to use Maven, but one of its dependencies turns out to be incompatible with something I'm using in my project. I think despite the really nice documentation that I'll find it a bigger pain if I can't use a version of a library that I want because the Maven guys didn't know it wasn't working with that version. (because they're not on GUMP). GUMP provides a drastic improvement in the way your project plays with others. GUMP is part of the answer to JAR-hell. I think I'd be resistant to trying an Apache project that wasn't committed to working on GUMP. Previous to GUMP most projects were known to be painfully tied to particular versions of particular libraries. This has gotten a lot better since GUMP came on line. So while I wish centipede and Maven would work together to create a better project (like I said, I'm but a pebble in the avalanche), I don't care which build a project uses. But I do care if Maven has decided not to build through GUMP as sooner or later I'm going to want to use a project that uses Maven (assuming its successful) and boy I'll be ticked if Maven causes dependancy problems that would have been self-resolving had GUMP been properly used to test it. Am I volunteering, well no (I can't as continuous integration has to be an active commitment by a community, and I'm not a part of that community...partly because builds bore me), but I think I'll change my position into actively dissuading Maven's use if it isn't integrated with GUMP as it could have a cascading effect on creating dependency problems for the projects that use it. And thats all I have to say about that, Andy PS these points are more elegantly stated here: http://www.martinfowler.com/articles/continuousIntegration.html James Taylor wrote: >Yeah, I love wading through GUMP's mess of ant build files, transformed >xml, generated perl and shell scripts and such, all of which is barely >documented at BEST. Especially when otherwise I'd have to spend that >time on things that actually make my project better... > >Perhaps that's why (from a Maven guy perspective) centipede is so scary. >It looks like that nightmare GUMP all over again. Two pages of >documentation and a 1.0 beta release?! Bah! > >-- jt > >On Wed, 2002-05-01 at 08:33, Andrew C. Oliver wrote: > >>Dude...you seriously need to get in line with GUMP. You want to make >>sure Maven works and works with other Jakarta stuff, well GUMP + Junit >>is "The Answer". Trust me. I don't feel its sam's job to fix >>everyone's bugs for them. Sam's pretty good, but I don't think he's >>that good, I think the rumors of him being omnipresent are exaggerated. >> Though its rumored that he can be in Redmond, NC and Apache all at once >>;-) (not a small feat). >> >>(so Sam is that worth those slides you promised?) >> > >>>I'll believe it when I see it here... >>>http://jakarta.apache.org/builds/gump/latest/ >>> >>>- Sam Ruby >>> > > > >-- >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]>
