Please add your patch to an issue instead of to attach it on an email. Thanks Emmanuel
On Fri, Aug 29, 2008 at 1:26 PM, Kiss Tibor <[EMAIL PROTECTED]> wrote: > Here is a possible extension of the svn-settings.xml. > > Overview: > Since SCM goals are generalisations of many version control provider's > commands, that enforces some limitation in using any of the extra parameters > of the underlaying command line tool. It would be ideal, that at the > configuration level of all SCM specific Mojos to be able to set extra > parameters to the underlaying version control command, but that somewhat > distroys the generalisation itself. Instead, there are the provider specific > ???-settings.xml files where there is nice to have such a possibility to set > extra parameters for any goals we consider useful to have open this > possibility. > > Example: > In my case I really need to be able to set some additional parameters to > svn status command. Such as "-uv > svnstatus.txt". In this way I am able to > obtain much more information than it is returned by the SvnStatusConsumer. > Moreover, I am able to prepare that intrinsic information right to be > packaged into my assembly. Otherwise there is no possibility to extract such > information from maven-scm plugin families. > > Proposal: > 1. Add extra parameters to svn-settings.mdo, such as statusExtraParams, > listExtraParams,.. with the following pattern: <goal>ExtraParams > 2. All of these new svn-settings parameters to be added to the end of the > corresponding Svn????Command. > > Has to be examined exactly which goals deserve to have such an extra > parametrizing, without distroying the functionality of the associated > consumer implementation. First, I think that those goals whose consumer > output plays a role mainly in the maven output console, just printing some > status information, or lists. Maybe there is worth to have such an extension > possibility to a more active family of goals like add, branch, checkin, > checkout. What do you think? > > THE PATCH (as a prototype only): > I made and attached to this email a patch only to have statusExtraParams, > only for status goal. > I tested it with the following settings.xml > <svn-settings> > <statusExtraParams>-uv > svnstatus.txt</statusExtraParams> > </svn-settings> > and I obtained the svnstatus.txt exactly as I would like to have on each > maven project while building a subset of maven projects. > > I would like to have such a possibility to extend the provider's commands. > That's why I raise the question to a discussion if it fit in scope of the > maven-scm-provider-svn project? > If seems to be acceptable, that let's discuss which other goals needs to > extend to have a somewhat complete feature implemented. If so, I will help > you by sending further patches. This patch mainly is only a prototype. I > tested whithout junit testing. > > Regards, > Tibor > > > > On Thu, Aug 28, 2008 at 12:08 PM, Dan Tran <[EMAIL PROTECTED]> wrote: > >> You may want to take a look at svn provider source to see if it can be >> extended to >> accept additional arguments via svn-settings.xml for scm:status command >> >> see >> >> http://maven.apache.org/scm/subversion.html >> >> -D >> >> On Thu, Aug 28, 2008 at 2:57 AM, Kiss Tibor <[EMAIL PROTECTED]> wrote: >> > Hi SCM team! >> > >> > I am involved in grounding a maven release management. So I have to keep >> > some backward functionality. >> > >> > I have to generate a textfile containing exactly what provide the "svn >> > status -uv" command. >> > >> > Looking at the SvnStatusCommand and SvnStatusConsumer implementation, it >> > seems that actually is not possible without further modification. I am >> > wrong? >> > >> > I would't like to migrate into a new maven plugin the Ant task based on >> > SVNKit wich does that, instead I would like to use the SCM plugin >> families. >> > >> > The entier maven-scm-providers-svn subset it would be affected by a >> possible >> > substitution, or is there a more elegant way to achieve my goals? >> > >> > At least some extra svn status parameters I would like to have, and of >> > course a new consumer which would capture the output in a file, which >> file >> > would be moved into META-INF directory of the output. (Please don't ask >> why >> > is necessary this stupidity to capture that information in a META-INF >> :-) ) >> > >> > Regards, >> > Tibor >> > >> > >
