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....
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....
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....
[ ] 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....
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
