Le 20 avr. 2014 13:09, "Stephen Connolly" <stephen.alan.conno...@gmail.com> a écrit : > > > > On Sunday, 20 April 2014, Robert Scholte <codeh...@sourcegrounds.com> wrote: >> >> Op Sat, 19 Apr 2014 23:04:33 +0200 schreef Karl Heinz Marbaise < khmarba...@gmx.de>: >> >>> Hi Baptiste, >>> >>> > Back to trying to keep going to be able to release as I said I would, >>>> >>>> I'm working on some jiras. >>>> The thing is, I noticed I have 3 ITs that fail locally. They also fail >>>> in Bamboo (https://bamboo-ci.codehaus.org/browse/MOJO-MBUILDNUM-45/log ). >>> >>> >>> The same here on my local machine.... >> >> Same here >>> >>> >>>> >>>> I think the issue with two of the ITs is about the svnkit version in use >>>> (1.3.5): it's too old and I guess it's not able to deal with the 1.7+. >>> >>> >>> yeah that looks so...this one has failed: * basic-it-svnjava/pom.xml >>> >>> and with those messages which affirmed your assumptions... >>> >>> at org.codehaus.mojo.build.CreateMojo.info(CreateMojo.java:770) >>> at org.codehaus.mojo.build.CreateMojo.getRevision(CreateMojo.java:706) >>> ... 22 more >>> Caused by: org.apache.maven.scm.ScmException: svn: E155021: This client is too old to work with the working copy at >>> '/Users/kama/workspace/buildnumber-maven-plugin' (format {1}). >>> at org.apache.maven.scm.provider.svn.svnjava.command.info.SvnJavaInfoCommand.executeSingleInfoCommand(SvnJavaInfoCommand.java:111) >>> >>> The same with MOJO-1668: >>> >>> Caused by: org.apache.maven.scm.ScmException: svn: E155021: This client is too old to work with the working copy at >>> '/Users/kama/workspace/buildnumber-maven-plugin' (format {1}). >>> at org.apache.maven.scm.provider.svn.svnjava.command.info.SvnJavaInfoCommand.executeSingleInfoCommand(SvnJavaInfoCommand.java:108) >>> at org.apache.maven.scm.provider.svn.svnjava.command.info.SvnJavaInfoCommand.executeInfoCommand(SvnJavaInfoCommand.java:71) >>> at org.apache.maven.scm.provider.svn.svnjava.command.info.SvnJavaInfoCommand.executeCommand(SvnJavaInfoCommand.java:48) >>> >>> >>>> >>>> So, to sum up, I guess I'm gonna have to touch some ITs to make them >>>> run. For example, I'm gonna have to modify the basic-it & MOJO-1668 ones >>>> from 1.7.4-v1 to 1.8.3-1 (that fixes the issue on my machine). >>>> >>> >>> I wouldn't see any alternative... >>> >>>> Another issue that surprised me: the current codebase configures the >>>> <cloneProjectsTo> property to src/it instead of target/it. Is this >>>> intended? It seems weird to me to write in some versionned directory >>>> during the build, but maybe there's a reason? I guess I'll fix that also >>>> in the go to separate sources and outputDirectory cleanly. See below >>>> about IT modification, btw. >>> >>> >>> Yes that's really weird.... >> >> This looks like a lazy solution because the .svn folder isn't copied. This calls for a better solution. > > > Yes, unzipping the test resources would be a better plan imho
OK. No problem and your right, I guess I'll proceed the same way I did for ARCHETYPE-456: have a "DotSVN" directory in the test tree that I'll rename ".svn" after copy using a prepare script as supported by m-invoker-p. IIUC, there's also a preference to just upgrade the IT configuration, so I'll do that too. Thanks > >>> >>> >>>> >>>> About those ITs, they're using the old invoker form, using goals.txt and >>>> so on. >>>> >>>> SO, the question: do we want to agree on something about modifying >>>> existing ITs in general? For example >>>> [ ] Upgrade them all to the up-to-date way of doing ? >>> >>> >>> I would suggest to upgrade them to the up-to-date way of doing cause this will make maintenance more easier in the future...and will remove the older plugin version over the time.... >>> >> With the introduction of svn 1.7 I've already seen several format changes. I'm not sure if it is stable enough right now. Maybe we should think of another approach where we have more control over the format. >> >>>> [ ] have two distinct IT directories, say it-old that we don't touch and >>>> configure another m-invoker-p execution with the latest version of the >>>> plugin (or using the same, another question?) ? >>> >>> >>> Hm...i don't like that idea...You might start on a local branch to be sure you don't break something but i don't see as a strategy.... >>> >>> >> Please don't, just fix it properly. Nobody will look to an old setup if the new one is used. >>>> >>>> >>>> Well, I don't know if I will get a lot of answers/opinions here, but I >>>> wanted at least to see if there were advices on some recommended way >>>> based on past experience here. >>> >>> >>> You get at least one ..;-) >>> >>> Kind regards >>> Karl-Heinz Marbaise >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > > -- > Sent from my phone
