But since we're going by leaps and bounds right now...we need a wiki-style workflow. Ditch CVS and provide me with an "edit this descriptor" page. The task of finding the right descriptor to edit can be several minutes of work. That should change to several seconds.
Leo: do you realize the potential security implications of this?
= The Human Factor =
What I really like about gump is the principle that we emulate developer behaviour as much as possible.
We could just let the metadata point to the sources, do away with ant alltogether, and implement an IDE-like compiler. But then gump would be able to build lots of things that might fail to build on the commandline.
yes, this is why I'm kinda reluctant to make gump more aware of what's going on internally. the fact that gump is dumb and proud to be is a lovely feature, IMO.
= The friggin' broken buildsystem =
It's not always a classfile change that broke things. In the avalon case, for example, the projects that are failing to build haven't seen very significant API change. The build itself is broken.
Maybe we should fall back to trying a non-ant build when that happens. Is it possible to detect an ant (or maven) failure as opposed to an api change? Is it worthwhile to seperate it out.
not unless we analyze the output.
= Let's go relational =
We want to build a complex, flexible, relational model of all these builds. Maybe its just me, but XML doesn't express that too well. It's much easier to express some fomrs of "intelligence" in SQL.
My "let's go relational" was for the history data, not for the project descriptors.
Going relational there would buy us only more effort (unless you write a web application to handle those things directly ;-)
Enough brainstorming for tonight.
I have more to say, but gotta run right now :-D
keep it coming :-)
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
