Re: [vote] move the descriptors in our hands
On Thu, 7 Oct 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: ant-contrib comes and goes (I think) as it's gump descriptor fails to get read from SF.net's viewcvs. If it is of any help, go ahead and move the descriptors to Gump's CVS (I'm with a customer and without my ssh keys right now). I'm the one maintaining the ant-contrib descriptors (ant-contrib and cpptasks) anyway. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move the descriptors in our hands
Stefan Bodewig wrote: On Thu, 7 Oct 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: ant-contrib comes and goes (I think) as it's gump descriptor fails to get read from SF.net's viewcvs. If it is of any help, go ahead and move the descriptors to Gump's CVS (I'm with a customer and without my ssh keys right now). I'm the one maintaining the ant-contrib descriptors (ant-contrib and cpptasks) anyway. So, should we go ahead and move all the descriptors in our hands? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [vote] move the descriptors in our hands
If it is of any help, go ahead and move the descriptors to Gump's CVS (I'm with a customer and without my ssh keys right now). I'm the one maintaining the ant-contrib descriptors (ant-contrib and cpptasks) anyway. So, should we go ahead and move all the descriptors in our hands? I've not voted on this, mainly 'cos I am -/+0. But, did you resolve the issues with Forrest guys? Are they able to do their thing, yet have the file in our repository? I doubt many folks would mind centralizing, initially in CVS, later in SVN, but we oughtn't cause folk grief to do it. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] move the descriptors in our hands
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: 08 October 2004 16:58 To: Gump code and data Subject: Re: [vote] move the descriptors in our hands Stefan Bodewig wrote: On Thu, 7 Oct 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: ant-contrib comes and goes (I think) as it's gump descriptor fails to get read from SF.net's viewcvs. If it is of any help, go ahead and move the descriptors to Gump's CVS (I'm with a customer and without my ssh keys right now). I'm the one maintaining the ant-contrib descriptors (ant-contrib and cpptasks) anyway. So, should we go ahead and move all the descriptors in our hands? Please do not move the avalon-trunk.xml descriptor - it's automatically generated and does not need any human tweaking. Stephen. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move the descriptors in our hands
On Wed, 06 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: So, two votes: three ;-) 1) move the metadata to SVN I guess most of us Gumpers are comfortable with this, not sure about the other occasional committers. I also don't know whether write access for everybody really works right now. I'm leaning towards +1 but we really need to ensure that every Apache committer can change descriptors. 2) move the descriptors into that module 3) give all committers write access to the /metadata folder (DTD will *NOT* reside there!) If 1) then 2) and 3), yes. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move the descriptors in our hands
David Crossley wrote: Stefano Mazzocchi wrote: There are 4 ASF descriptos that currently don't reside in our repository: 1) avalon_trunk 2) cocoon 3) forrest 4) lenya and a few others (3) from outside. I would strongly suggest that we start moving them. The only problematic one is cocoon's since it's a central piece of the build system. But this can be easily solved with svn:external if we move the metadata in SVN. At Forrest our module.xml is an integral part of our build. I gather that we could use the svn:externals property too. yes, if that's the need, yes. note however, how svn:external works only on a folder (or, at least, I couldn't make it work on a single file) an alternative, which I'm considering for cocoon too, is to use a get operation in the build.xml that fetches the file directly from the CVS repository via viewCVS. This would allow us to avoid moving the metadata to SVN entirely! We could instead re-structure our build system at Forrest to not depend on the module.xml file. At first glance it is just to grab our version number. However, we are just about to enter a release process, so not yet. hmmm, if it's just the version number, it's a trivial change, as you can place that into the build.properties files and be as happy. in any case, it is failing so I will start moving it over anyway. you guys can decide what to do on your own. Anyway, +1 from me (still need to raise on forrest-dev) please do for moving our metadata to the Gump repository and +1 for moving all Gump metadata to SVN. with the above get trick it might not be necessary for now. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [vote] move the descriptors in our hands
Stefano Mazzocchi wrote: David Crossley wrote: At Forrest our module.xml is an integral part of our build. I gather that we could use the svn:externals property too. yes, if that's the need, yes. note however, how svn:external works only on a folder (or, at least, I couldn't make it work on a single file) Drat, no good then, because we only want the one file. an alternative, which I'm considering for cocoon too, is to use a get operation in the build.xml that fetches the file directly from the CVS repository via viewCVS. This would allow us to avoid moving the metadata to SVN entirely! Sounds good. We could instead re-structure our build system at Forrest to not depend on the module.xml file. At first glance it is just to grab our version number. However, we are just about to enter a release process, so not yet. hmmm, if it's just the version number, it's a trivial change, as you can place that into the build.properties files and be as happy. Yes. We do not have build.properties, but can do something. in any case, it is failing so I will start moving it over anyway. you guys can decide what to do on your own. As far as i can tell, it is failing because ant-contrib is failing and we get some previous build of that. Not our failure, so i didn't do anything. We have had this one before. Anyway, +1 from me (still need to raise on forrest-dev) please do for moving our metadata to the Gump repository and +1 for moving all Gump metadata to SVN. with the above get trick it might not be necessary for now. Will investigate. As i said we are not doing any change for now, due to imminent release. -- David Crossley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move the descriptors in our hands
David Crossley wrote: As far as i can tell, it is failing because ant-contrib is failing and we get some previous build of that. Not our failure, so i didn't do anything. We have had this one before. no, it's not because ant-contrib is failing, but because it's no longer there! where did ant-contrib go btw? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [vote] move the descriptors in our hands
no, it's not because ant-contrib is failing, but because it's no longer there! where did ant-contrib go btw? ant-contrib comes and goes (I think) as it's gump descriptor fails to get read from SF.net's viewcvs. One days that service barfs ant-contrib is missing (it was for a month when they had a hardware failure). I checked yesterday and I think it is back. Is it not being found by others? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move the descriptors in our hands
On Thursday 07 October 2004 02:39, Stefano Mazzocchi wrote: There are 4 ASF descriptos that currently don't reside in our repository: 1) avalon_trunk 2) cocoon 3) forrest 4) lenya and a few others (3) from outside. The only problematic one is cocoon's since it's a central piece of the build system. Not entirely correct (not withstanding the eminent changes to Avalon itself), the Gump descriptor for the avalon projects are in the Avalon source repository, as it is auto-generated from the project models, and committed upon change. We considered that a manual copy would be prone to human errors (for instance, forgotten). I guess we could make an effort to have the buildsystem more strongly understand that it should go elsewhere. So, two votes: 1) move the metadata to SVN 2) move the descriptors into that module 3) give all committers write access to the /metadata folder (DTD will *NOT* reside there!) with svn:external, it should be rather painless for the cocoon project to allow the descriptor to be moved here. I guess I need to read up on that property. If it works for Cocoon it sure would work for Avalon as well. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move the descriptors in our hands
So, two votes: 1) move the metadata to SVN 2) move the descriptors into that module 3) give all committers write access to the /metadata folder (DTD will *NOT* reside there!) with svn:external, it should be rather painless for the cocoon project to allow the descriptor to be moved here. Since we have, in Gump SVN, a ./metadata (albeit an empty directory) into which we CVS update, could we not start populating it as we need? Does this not give us the ability to experiment with svn:external (and whatever else) yet not disrupt folks comfortably in CVS? Just a random idea... regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move the descriptors in our hands
Stefano Mazzocchi wrote: There are 4 ASF descriptos that currently don't reside in our repository: 1) avalon_trunk 2) cocoon 3) forrest 4) lenya and a few others (3) from outside. I would strongly suggest that we start moving them. The only problematic one is cocoon's since it's a central piece of the build system. But this can be easily solved with svn:external if we move the metadata in SVN. At Forrest our module.xml is an integral part of our build. I gather that we could use the svn:externals property too. We could instead re-structure our build system at Forrest to not depend on the module.xml file. At first glance it is just to grab our version number. However, we are just about to enter a release process, so not yet. Anyway, +1 from me (still need to raise on forrest-dev) for moving our metadata to the Gump repository and +1 for moving all Gump metadata to SVN. -- David Crossley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
