Oleg wrote: > We will be more than happy to play by the rules, as long as they are clearly articulated and agreed upon, not just imposed upon us.
I completely agree, and like I said -- these aren't even "mandatory rules" more "here is how to play nicely w/ other Gumpers". I also agree it is upon the Gump folk to agree and document/communicate these things. I think this has been in the heads of "those in the know" for too long... > There is one thing I really have an issue with: why do we have to have separate CVS > modules per version under development, where a more natural way for me (very GUMP > illiterate person) is to have a CVS branch per version being developed. It may happen that > we will end up having yet another development stream in addition to version 2.0 and 2.1 > development. Would that require yet another CVS module to remain GUMP friendly? Yikes, did I communicate this? No, not at all! I think we have a terminology miscommunication... Upon investigating how I see that one has to have multiple gump module descriptors for separate tags/branches in one CVS module, but that is doable. I beleive you can "alias" (via depends) to set the commons-httpclient to any one of your two (or three) tags. I will find some time to check this all out, and write it up/document it on the gump site. That said, the Jakarta POI recently did this with two module descriptors, but the same effect (although no aliasing): http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/jakarta-poi.xml?rev=1.29&content-type=text/vnd.viewcvs-markup se <module tag=.. http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/jakarta-poi3.xml?rev=1.4&content-type=text/vnd.viewcvs-markup There are (at least) two ways to get a tag/branch for a module (I am still investigating on project). For reference see: http://jakarta.apache.org/gump/module.html w/ the "tag" on module and the "cvs" information. IF you look here I think you'll see a number of such examples: http://cvs.apache.org/viewcvs.cgi/jakarta-gump/project/#dirlist As I said, I care about this sort of stuff so am happy to try to help and/or document. regards, Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
