It is probably enough, thanks, but not for a few days (minimum) I'm breaking for Thanksgiving...
I'm assume project.properties is in standard properties format, as with your global properties. Any other places for them than user's directory? Any way to place them somewhere and tell Maven where to look for them? Any pointers on what one might put into each? BTW: A cut-n-paste to mail of some of all these things would be useful. Happy Thanksgiving all... regards, Adam ----- Original Message ----- From: "Brett Porter" <[EMAIL PROTECTED]> To: "'Gump code and data'" <[EMAIL PROTECTED]> Sent: Wednesday, November 26, 2003 3:11 PM Subject: RE: Maven and gump > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
