Jim Ray wrote: > > Is there any way to currently extend GUMP? Kind of like tasks for > Ant? Or was that not part of the design? Mostly for Perforce use.
The intent was never to be cvs specific, but so far another use case has never arisen. Perhaps now would be the time... ;-) What changes to the <repository> element do you think would be helpful for perforce? What would attributes would you think would be appropriate for a <perforce> tag in a <module>? What perforce commands are the rough analogs for cvs checkout and extract? If you want to help code this, I can point you in the right direction and will fold in the results. Otherwise, if you can tell me what you want, I can take a stab at it. > And how hard would it be to make it generic enough that it could do > C/C++? I already have the Ant task to do this. Or do I just > need the Ant build file, and substitute in the <jar name=""> the name > of the binary I'm trying to generate. Again, the requirement was originally intended to be anything that can be built from the command line (as I use Linux, Solaris, and Windows, personally I add the additional requirement of being able to be done in a portable manner, but for your own projects, this is not a requirement). The easy part would be adding some sort of command like <make>. The part that requires more thought is the constructing of INCLUDE and LIB enviroronment variables (the purpose of jar is to aid in the construction of CLASSPATH, so new elements would have to be defined.) > Another thing, I'm wondering is if you thought about adding a "mail" > element in a "project.xml" to notify the owner of a module or project. > I know that > it has the "nag" capability but I can't figure out where to configure it. Oops! I forgot to document the naglist! I'll have to go fix that. Meanwhile, the general thought is that you might have projects and profiles that are shared by multiple workspaces. I certainly build the gump profile on multiple machines. For me, nagging is something that is done on one machine independent of the description of the project. Ultimately, when projects contain their own build information, this will become more important. Meanwhile, you can get a feel for how nagging works by looking at two files: http://cvs.apache.org/viewcvs/~checkout~/jakarta-alexandria/proposal/gump/naglist http://cvs.apache.org/viewcvs/~checkout~/jakarta-alexandria/proposal/gump/nag.pl - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
