> As long as you don't believe you could solve the social problem of > "don't like to rely on others" via a technical solution ...
No. As I said, I'd just like to try to swing the balance a bit closer to re-use through good clean communications (including statistics). Maybe I am more trying to help folk prior ro making the build/borrow decision. If a team is trying to make a decision to use (say) some XML bean thingie, and some members of the team argue aginst re-use 'cos XYZ isn't blah, it'd be nice to have some facts to make a proper decision upon. For example -- N folks are already using it, it has M stability/maturity, etc. Getting developers to use one's toothbrush will still be easier than getting them to use one's software, but perhaps we can get it to rank above flossing. ;-) > You said that projects could switch components they rely upon if those > components would consistently fail to build with Gump and I said that > would be unlikely. Maybe, at the level of the examples you've given. I'm working with others to re-write Ruper making commons VFS (cool, but perhaps overkill) an optional component. The final straw was an ongoing gump issue [making all ruper dependees crash horribly] that saw no action for way too long. I'm not saying it is easy, but it is an option and some times it is mandatory. Gump helps demonstrate divergences, and having statistics/communications that clearly document 'recent history' (saving humans from using gut feelings alone) have potential to be a good thing (IMHO). > >> Are you aware that almost all krysalis-* projects fail every night > >> "because Centipede has not been not initialized"? 8-) > Every night. You don't see them as nagging doesn't work at all (the > one from Sam's machine) as nightly Gumps are broken, currently. Maybe > I should publish my nightly results until Sam's builds are up again. > > But then again, you should be able to see the failures un > gump.covalent.net as well. I looked into to the problem (thanks for the posting it). Annoying that this must've started happening about when nags stopped, and that Nick's gump (he didn't have resources to build the ant stack) -- or perhaps when Ruper and above was a mess due to VFS/HttpClient. I was thinking it was environmental on your machine, but no, it is (as you say) on Covalent also. What is so interesting is that it is complaining about a static variable that one ant task sets (and I see it called in the logs) that another tests. For that variable not to be set, an exception would have to occur (at best) but I see nothing from ant on that, so maybe there is something deeper. Any chance you could think of anything that has changed within Ant, to do with including ant taks and such, that might (possible) give us a starting point? > > If you are running latest Ant, > > You are joking, right? ;-) > Sometimes it is more recent than CVS HEAD. No, just demonstrating that the contents of my e-mails are sometimes more recent than the contents in my HEAD. ;-) regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
