> I'd really like to build Maven from the ground up, seems the > most Gump-like.
Fair enough. > As we get more Gumps (or remote hardware) this could become > an issue, but we can work on that if/when it becomes a scaling issue. When I said plugins interefering with each other, if a project depends on the most recent version of the cactus plugin - that gets installed into the Maven installation and all future runs will use it regardless of dependency. So gump probably needs to insure that directory is intact and clean ~/.maven/plugins after each project build if the main once changed. > Could you do us a favour and document: > > 1) The command line (e.g. "maven .... ") Pretty much the same as ant. maven -Dproperty=value [goal(s)] Run in the same directory as project.xml (there is a command-line option to use project.xml from a different directory, but I think it is broken in RC1). > Include: > 1.1) how to set properties, In this case, you should create a 'build.properties' file in the same directory as the project.xml. Project's shouldn't be including that in CVS - they'd be using project.properties. Global properties would be put in ~/build.properties for the running user. > 1.2) override ant properties [if needed] Not sure what you mean here. > 1.3) how to do 'jar overrides' This and the section following talk about dependencies and overrides. http://maven.apache.org/reference/user-guide.html#Overriding%20Stated%20Depe ndencies This will be the contents of the build.properties file genereated per project by gump. > 2) The working directory Location of base project.xml. If they are running a multiproject or tailored goal that builds subprojects, make sure you generate the build.properties files into the right directories - the parent ones are not currently inherited. > 3) The exit codes/outputs/etc. I think it is best to check for "BUILD SUCCESSFUL" as a sanity check, but the error codes are here: http://maven.apache.org/xref/org/apache/maven/cli/App.html#120 > > As for metadata, since Gump is goign to try to overide the > POM (which I suspect will be in CVS) I'd like *NOT* to try to > have Gump read a POM for a phase 1 implementation. > Personally, I'd like to see there be a <maven entry similar > to the <ant one today: http://jakarta.apache.org/gump/ant.html It would be very similar. Just replace buildfile with projectdescriptor and replace target with goals > One other thought, what say Maven generates a gump descriptor > with two projects (for each one it has today). One normal ant > [as now], and one with a <maven build element. That was we > can see the practicality/stability of the latter w/o > interrupting Gumping for the projects. Grab a mavenised project and run "maven gump". Then change the <ant /> tag to <maven /> according to how you've set it up. Let me know of any problems with the generated descriptor and I'll change the gump plugin. Hope this is enough to get it going! Cheers, Brett
