Leo wrote plenty -- with this just being a snippet:
= The Human Factor =
What I really like about gump is the principle that we emulate developer behaviour as much as possible.
Yup, me too, I liked it when you posted to Avalon-Dev also. Maybe we need a logo of some crazied gung-ho half-blind half-carpel-tunneled geek who just can't see a CVS commit message they don't want to tinker with. ;-)
The rest of what you wrote -- made me reconsider my last posting. I'm not saying that aspects of Gump aren't broken, and we need just promote, I just think we need to promote for those happily using Gump right now. For those with simple build systems things really aren't that that bad. I wonder if that is the majority or not.
Adam, that's why I dislike those numbers so much: they give a false impression. Having 60% of the tree built is useless if that 40% is where the juice is.
Where is the juice? where it is hardest to keep track of dependencies.
Cocoon didn't have a single gump run in 6 months or more.
Focus on fixing that and you'll see how thing change.
That said, Gump is very sensetive to the build system, and I like the IDE comparison/analogy/proposal. Doing a build is a compile plus a jar (plus perhaps unit tests/others?). I'd like Stefan's input on if we allowed a <gump to be like <ant|<maven -- to have Gump just build/archive. We'd loose the ant regression test suite. Maybe we just keep Gump IDE-like simple, and say that if you want to 'plug-in' then use <ant. (Yes Leo, I read you blog entry ;-)
BTW: I suspect that <gump could implemented by writting the ant script on the fly w/o us having to reinvent the wheel.
I think we should focus on using what the projects have. It's harder to start with, but much more solid in the longer run.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
