Mark wrote:
I wanted to to attempt to coordinate with Gump folks concerning nightly builds, the new maven repository on the apache server and other interesting tidbits.
I needed some time to mull this over before I responded. I see you have good intentions to try to pull a bunch of things together, and I respect that. That said, I don't think they should fit.
Every time I try to match Gump with nightly builds, I come up against a philosophical problem which Stefan explained. Gump isn't doing nightly builds (against a stable base), it is doing nightly integration test builds (an unstable 'box of chocolates' :). Gump's output jars aren't for general use (few folks could/should live on the edge that much, each morning getting a shifting base). IMHO they probably ought not have been distributed (in the past) but for the future I see them as key to scaling a cascade of Gumps. As such, although I think the Gump repository ought be open/available (no point thinking for users) I envisage it's use only by other downstream Gumps.
regards,
Adam
The best example I can give of developer requirements this scenario is the following:
I work on the commons-math project, which is dependent on commons-collections and commons-logging.
The way I have it configured, I do all my development against either "dated version snapshot builds" that are archived in the maven repository.
commons-collections-20040102.233541.jar 29-Jan-2004 19:46 842k commons-collections-20040102.233541.jar.md5 29-Jan-2004 19:46 1k commons-collections-SNAPSHOT.jar 29-Jan-2004 19:46 842k commons-collections-SNAPSHOT.jar.md5 29-Jan-2004 19:46 1k commons-collections-snapshot-version 29-Jan-2004 19:46 1k
or actual released versions when cutting a release:
commons-collections-3.0.jar 25-Jan-2004 01:50 506k commons-collections-3.0.jar.md5 26-Jan-2004 15:53 1k
Currently the production of these dated builds is not automated. Its up to each project to release snapshots into the maven repository.
My position is that it would be nice to have this snapshot process automated in a nightly build such that these were generated on a regular basis. The most important feature I see that it would be difficult to maintain, is that the jars produced have to maintain the same content and tructure as those tht would be produced normally by maven as configured in the projects project.xml If gumps jars are very different. then that could be an issue.
My thoughts are along these lines
1.) In a daily build process for maven projects, we'ed want either Maven or the Ant build.xml that can be generated by maven to get called (this is actually what happens in Craig's nightly build process right now, an Ant build.xml file is required in the proect with a "dist" target avalaible in it, and maven can actually produce thsi properly). This way the artifacts would be comperable for a project across the various build processes.
2.) Integration testing is on a very different scale and distribution than nightly or weekly build releasing. So it may be the case that these approaches remain different processes simply because they run at different times, duration and scale. But, theres alot to be gained sharing the automation approaches applied and exploring areas of consolidation or standardization in process.
-Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
