Re: suggestion refactor SCM
Trygve Laugstøl a écrit : On Wed, 2005-09-28 at 16:56 +0100, Jose Alberto Fernandez wrote: From: Steve Loughran [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: But here we seem to be talking about a new family of generic tasks, If this works well, we could deprecate the old tasks and eventually in a couple of versions remove them. Jose Alberto generic is good, provided -we can have a conceptual model that is consistent across all SCM systems. -we can deal with extensibility through antlibs. I suppose you'd have a new type, SCMbackend that every backend would implement; declaring a new backend would let you register it. Question: could you just get away with some mixin import lib that declared the appropriate macros for the appropriate platform? Well, it seems that the maven people have such a thing to some extend already. This new antlib tasks could use that support. Hey, maybe maven-scm could host and provide the antlib for these tasks. Or maybe they are willing to move it to our sandbox. I still think, it will be a good idea if we continue to get involved to help define the overall picture from the ANT perspective. With my Maven SCM Committer hat on I would not object to hosting the Ant tasks under Maven SCM if that's what you guys feel is right. Your call but I'm +1 to having them under Maven SCM. I'm +1 too At the end of the day we would have to decide if we would like to provide these libraries as part of our release, provide some 3rd party goodies that you can download as part of ANT, or just tell people about their existence somewhere. -- Trygve Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestion refactor SCM
Great news. So you'll can provide new providers. Emmanuel jerome lacoste a écrit : On 9/27/05, Emmanuel Venisse [EMAIL PROTECTED] wrote: Jose Alberto Fernandez a écrit : I think that it will be a very good idea, mostly as a stepping stone to higher level functionality. The main reason for not having such a thing is the fact that each project knows in advance what kind of repository is being in used. So why do we need something abstract? On the other hand, once you have such an abstracted functionality, I am sure we could envision higher level tasks stored on other antlibs that may provide project management style functionality irrespective of the underlying repository. That would be a very good thing to have. So I am all for it. The question is what are the concepts that can be ported across all different SCMs? In Maven-SCM, we have some abstract beans for each commands (checkout, checkin, update, changelog...) in an abstract api, Each provider implement these beans for obtain an accessible command in framework for this provider. We support actually clearcase, cvs, local, perforce, starteam and in few weeks, Serena Dimension (PVCS). For your information, I am about to propose CruiseControl to reuse this library. We currently support 14 SCM, but most of the time only the changelog functionality is supported. Cheers, Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestion refactor SCM
Jose Alberto Fernandez a écrit : I think that it will be a very good idea, mostly as a stepping stone to higher level functionality. The main reason for not having such a thing is the fact that each project knows in advance what kind of repository is being in used. So why do we need something abstract? On the other hand, once you have such an abstracted functionality, I am sure we could envision higher level tasks stored on other antlibs that may provide project management style functionality irrespective of the underlying repository. That would be a very good thing to have. So I am all for it. The question is what are the concepts that can be ported across all different SCMs? In Maven-SCM, we have some abstract beans for each commands (checkout, checkin, update, changelog...) in an abstract api, Each provider implement these beans for obtain an accessible command in framework for this provider. We support actually clearcase, cvs, local, perforce, starteam and in few weeks, Serena Dimension (PVCS). I think it will be great if we can contribute together to it. Maven-SCM is totally independant of an other framework, so it can simply be used in ant, maven, continuum, standalone app... We actually use it in maven1, maven2 and continuum Emmanuel As per syntax, I would much prefer something like: scm:commit ./ Now, can this be done in such a way as to figure out by itself what is the underlying repository is. That would limit the need for magic stuff. Jose Alberto -Original Message- From: Kev Jackson [mailto:[EMAIL PROTECTED] Sent: 27 September 2005 07:34 To: Ant Developers List Subject: suggestion refactor SCM Hi I've been playing with darcs recently and I've almost finished an antlib for it (though I keep being distracted, first Haskell, now Lisp). 'darcs get' is roughly similar to 'cvs checkout' or 'svn co' I was wondering if it would make sense to refactor the SCM tasks into an interface (scm) and have a set of antlibs that implement that interface in a vendor specific manner. Such that scm command=commit is handled appropriately by each SCM system in it's own way, whilst at the same time exposing a common API to simplify this (very common) set of tasks. I'm thinking it'd be similar to how the javac task simplifies compiling regardless of which compiler you want to use. Is this: a - a stupid idea and a colossal waste of time b - a not too stupid idea, but still a colossal waste of time c - not stupid, a colossal waste of time, but it'd be worth doing anyway d - none of the above Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
