Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
We really gotta start thinking about our build system and gump integration.
Vadim Gritsenko wrote:
Unico Hommes wrote:
I've completed the changes to the build system discussed earlier [1]. In order to do so I have extended the gump descriptor with additional information that allows the build system to locate one or more dependency jars per <depend> project within ./lib/optional. See for an example the cocoon-block-axis project definition in gump.xml
Every block now *must* declare all the dependencies it requires to compile in gump.xml just in order for it to build properly.
Since I am not very familiar with gump.xml and I had to add a lot of information it is very probable that I made a mistake or two with the way local projects are declared.
I thought you'll add <libary/> element which would be independent of <depend/> element and thus avoid any possible conflicts with Gump. But now I see that you'd added bunch of new <depend/> elements - which are not currently required by Gump - I don't think we should do that.
I'd sleep better if instead of:
+ <depend project="db-ojb"/> + <depend project="antlr"/> + <depend project="commons-dbcp"/> + <depend project="commons-pool"/>
We'd have:
+ <library project="db-ojb"/> + <library project="antlr"/> + <library project="commons-dbcp"/> + <library project="commons-pool"/>
this will make our descriptor being invalid, but since I control the DTDs we can change that on the other hand.
but there is something that bothers me: the above really doesn't make any sense. What would be a lot more useful would be something like
<depend project="antlr" version="1.0"/>
or
<depend project="antlr" timestamp="20040349"/>
or
<depend project="antlr" tag="V1_0_RELEASE"/>
then it would be up to gump to give you the version you want (and we might indicate what versions we expose in our gump.xml description).
Two points;
* Gump is about continuous integration, i.e. always trunk, right?
so far ;-)
And our build does not need version information too. Then, who needs it?
My idea is the following: gump should be *both* a build system and a continous integration system. It should build your project in two phases:
1) run against the dependencies with the versions you specify (since they will never change, they can be built once and their packages kept in place forever). If broken send nightly build error and stop.
2) if nightly built was successful, perform continous integration by running against the latest and greatest. If broken, send continous integration warning and stop.
* gump.xml currently does not record dependency on antlr. Do you think
it should be added?
yep.
Why?
see above.
That's what I meant above - I'm not sure we should add bunch of dependencies.
Another issue is that dependency project name might not match library name...
well, that's your concern only if you specify the version (and, even in this case, it's enough to create a mapping between a version and a tag/timestamp).
If you specify a timestamp or a tag, gump can figure it out by itself since it has all the metadata it needs to figure out where the builds write their jars and how they name them.
Hope this helps.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
