FYI, just committed the associated modification in r19666. Now the IT run in target/it as usually found. The CI still fails, but at least now I have a BUILD SUCCESS locally.
If someone can confirm buildnumber-m-p 'mvn clean verify' now run correctly on their machine, that'd be great. About the CI envt, IIRC, I have to configure something like "artifacts" to be able to retrieve a part of the remote workspace? Can't find the login button anymore... So, I'm currently unable to know what's making the CI fail (and I don't like it, I miss you Jenkins :)). Cheers 2014-04-20 13:57 GMT+02:00 Baptiste Mathus <bmat...@batmat.net>: > > 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 > > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
