Maven2 release goal not working with SubVersion

We have configured TeamCity to build a maven2 project which is configured to use SubVersion. When we specify goals of release:prepare and release:perform we get the following error:

BUILD FAILURE
org.apache.maven.reactor.MavenExecutionException: Unable to check for local modifications Provider message: The svn command failed. Command output: svn: '.' is not a working copy org.apache.maven.reactor.MavenExecutionException: Unable to check for local modifications Provider message: The svn command failed. Command output: svn: '.' is not a working copy at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:174) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:689) at jetbrains.maven.Maven21Launcher.executeMaven(Maven21Launcher.java:116) at jetbrains.maven.Maven21Launcher.main(Maven21Launcher.java:49) Caused by: org.apache.maven.BuildFailureException: Unable to check for local modifications Provider message: The svn command failed. Command output: svn: '.' is not a working copy at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) at

It appears that the checkout location that TeamCity creates is not a valid svn checkout location so the release goals fail. What is the cause and how can I resolve this error?

15 comments
Comment actions Permalink

please check your version.
i saw the same error when using a build before latest(1529 i think)

0
Comment actions Permalink

After installing build 1529 our server shows 0 build agents (and reinstalling using webstart is broken). How did you get your build agent to work with this build?

0
Comment actions Permalink

Okay, I got the build agent to work but I still have the same problem (build 1529) with TeamCity and SVN in that the release goal does not work.

BUILD FAILURE
org.apache.maven.reactor.MavenExecutionException: Unable to check for local modifications Provider message: The svn command failed. Command output: svn: '.' is not a working copy

My pom.xml is configured to use SVN as:
scm:svn:https://xrite18/svn/components/xrite-commons/trunk/ scm:svn:https://xrite18/svn/components/xrite-commons/trunk/ https://xrite18/svn/components/xrite-commons/trunk/ https://xrite18/svn/components/xrite-commons/tags/ ]]>

How can I configure SVN so that TeamCity can make a release of a snapshot project?

-dh

0
Comment actions Permalink

i have been manually installing the build agents, without java webstart

0
Comment actions Permalink

In this case Maven itself tries to perform svn operations, so you need to switch off the option "checkout on server" for the build
configuration.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

The maven release goal does not chekout sources. How am I supposed to have TeamCity watch for svn checkins and enable checkout so maven2's release can do it's job? I'm not clear how to do this.

0
Comment actions Permalink

The maven release goal does not chekout sources. How am I supposed to have TeamCity watch for svn checkins and enable checkout so
maven2's release can do it's job? I'm not clear how to do this.


While it does not perform checkout, it labels the version in the svn. To do this, there must be a directory structure on the agent
with the .svn meta-data. If you have checkout-on-server option enabled for your build configuration, the checkout is done on the
server and sources are later sent to the agent machine where the maven starts. Of course, svn meta-data is not sent along with the
sources.
On the other hand, if checkout-on-server option is turned off, the agent assumes that the build script itself handles communication
with VCS and simply starts your maven build. That way there will be a "properly" checked out directory structure on the agent with
svn meta-data, so the "release" goal won't be confused when performing version labeling. Note that since you have VCS roots properly
configured, the server will detect changes in your VCS no matter whether "checkout-on-server" option turned off or on.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Eugene,

Thanks for the reply. I think I understand your reply but am not clear how to make this implementation work in practice. Perhaps, on Monday I can review this issue with our development team can propose some solutions.

The issue for me is how/where to do the chekout. There is no build script in a maven project; that is the main reason for using maven in the first place; there are no scripts to maintain. All there is in a maven build system is the pom and the continuous build tool (i.e. TeamCity in this case). The pom knows where the vcs is located as does TeamCity (this also seems like poor implementation on the part of TeamCity as it would be able to get the vcs info from the pom).

Back to your suggestion 'assumes that the build script itself handles communication
with VCS', since there is no build script where does the checkout go?

-dh

0
Comment actions Permalink

Hi David,

Back to your suggestion 'assumes that the build script itself handles communication
with VCS', since there is no build script where does the checkout go?


Bu build-script here I mean anything that is started by the Agent (in our case this is Maven).

First, let's define the purpose for what the Build Configuration is created in the TeamCity. One of the purposes may be continuously
running tests and getting statistics about tests failures (artifacts does not matter in this case). For this purpose we can set up
the build configuration that gets sources from a vcs and starts Maven with the only goal "test".
Another use-case is creating a build configuration which will run from time to time and its "main" result would be build artifacts.
What is the purpose of your build configuration?

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

I have been configuring TeamCity(TC) to perform three goals, install, deploy & release (this needs to work in batch mode so no user interaction is required). The install has minimal use for me at this point, I have been using it to verify that everything works.
I think that deploy and release are the key goals that need to work with TC. I don't have much problem with deploy. The TC checkout works and the maven goal creates and deploys the artifact.
The big problem is the release goal...due to the fact that the TC checkout is not a valid working directory for the maven goal. It seems we need an option to checkout sources to a valid working directory in TC.

The other issue that needs help is the build versions that TC displays...these have nothing to do with the maven build versions...and I think they should.

0
Comment actions Permalink

The big problem is the release goal...due to the fact that the TC checkout is not a valid working directory for the maven goal.
It seems we need an option to checkout sources to a valid working directory in TC.


As I wrote this problem can be solved by setting "checkout on server" option to 'false' and configuring Maven's SCM plugin to do svn
checkout (or update) instead.

>

The other issue that needs help is the build versions that TC displays...these have nothing to do with the maven build
versions...and I think they should.


Currently Maven2 for TC is just another runner (like Ant or MSBuild) that can be started by the Agent. Therefore, the abstract
versioning scheme is implemented on the server side. Current "build number" and "build number format" settings indeed does not
affect the way Maven works. Make TC aware of Maven2 versioning scheme and even setting it to use it, is a separate feature, which we
will definitely consider.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Regarding the first issue...I understand your point of setting "checkout on server" option to 'false'. However regarding your point of 'configuring Maven's SCM plugin to do svn checkout (or update) instead' how is this accomplished? Is this something I can do now with the current build of TC or does this require a change to TC?

Regarding the versioning issue...I understand this is a different issue for your consideration.

-dh

0
Comment actions Permalink

Regarding the first issue...I understand your point of setting "checkout on server" option to 'false'. However regarding your
point of 'configuring Maven's SCM plugin to do svn checkout (or update) instead' how is this accomplished? Is this something I
can do now with the current build of TC or does this require a change to TC?



Hmm, I understand this is not the "clean" solution but.... In the "goals" field of the build configuration specify: "scm:update
release:perform"
Unfortunately, the first checkout of the project needs to be done manually on the Agent machine (to obtain the pom.xml).

In the next TC version the problem could have been solved by using dependent build configuration: one configuration is a "bootstrap"
one and the second one will depend on it.

By the way, why do you need to perform "release" goal continuously? I'd thought about Maven "test" goal as the best candidate for
continuos execution.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Well, let me cover your last question first. In my view the two maven goals with the most usage for continous execution are deploy and release (release has two phases prepare & perform).

My reasons for thinking these are the two major goals are...
- These are the only goals that publish anything (plus site but I care about publishing of artifacts not documentation mostly).
- I see the deploy goal being run continously upon source checkin (of the main project code) so developers/testers have a new SNAPSHOT build to work with.
- I see the release goal being run nightly (of the main project code) so developers/testers have a new release build to work with.
- I see the release goal being run continously upon source checkin (of shared component code) so developers have a new release build published. The main project code then will refer to these released components by version (likely using set notation to get the latest version). I think it is key that these components are released (i.e. not SNAPSHOTS) because the maven release process only 'releases' artifacts in the current poms (including parents). It does not release dependent components.

Regarding the first part...it is important that TC support the release:prepare & release:perform phases of the release goal. There is a batch-mode switch that will allow this to be automated (user accepts all default release questions/answers). (Neither of these phases does the source checkout.) I will try your explaination of...'In the "goals" field of the build configuration specify: "scm:update release:perform'. I understand that for now I will have to checkout the pom.xml on the agent machine.

-dh

0
Comment actions Permalink

Okay I tried your suggestion of manually checking out the project from subversion and then running the build configuration of "scm:update release:perform'. I get an error.

- I manually checked out project into ./buildAgent/work/ - In the TC configuration the pom file directory is set to %build.working.dir% - In the TC configuration I turned off the checkout sources automatically option - In the goals edit box I tried various combinations of scm:checkout/update release:release/perform I always get the following error: jetbrains.buildServer.RunBuildException: java.io.FileNotFoundException: C:\WINDOWS\TEMP\587\pom.xml (The system cannot find the file specified) jetbrains.buildServer.RunBuildException: java.io.FileNotFoundException: C:\WINDOWS\TEMP\587\pom.xml (The system cannot find the file specified) at jetbrains.buildServer.agent.runner.GenericProgramRunner.run(GenericProgramRunner.java:64) at jetbrains.buildServer.agent.impl.BuildAgentImpl$2.run(BuildAgentImpl.java:381) at java.lang.Thread.run(Unknown Source) Caused by: java.io.FileNotFoundException: C:\WINDOWS\TEMP\587\pom.xml (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.]]>(Unknown Source) at com.intellij.openapi.util.JDOMUtil.loadDocument(JDOMUtil.java:185) at jetbrains.maven.MavenRunner.createPomCopy(MavenRunner.java:208) at jetbrains.maven.MavenRunner.getProgramParameters(MavenRunner.java:89) at jetbrains.buildServer.agent.runner.JavaProgramRunner.buildCommandLine(JavaProgramRunner.java:89) at jetbrains.buildServer.agent.runner.GenericProgramRunner.run(GenericProgramRunner.java:58)

0

Please sign in to leave a comment.