My Maven2 build fails

I created a project, pointed it to the SVN repo and specified M2 builder with default config.

When I ran the build, it failed - I saw that it was looking for settings.xml in the plugin directory and for user serrings in "C:\.m2" . Since I have customized both global and user level settings, I set %system.maven.home% to point to my local M2 installation and it fix to solve it (the app-level config is read from there).

I still could not get TC to find my user settings and my existing repo - they are in the standard location - "%USERPROFILE%/.m2", while TC is trying to find them under "C:\m2".

I tried to specify the full path to settings.xml in the build config form, but this doesn't help:

LOG:

(let me know if you need more)

QUESTIONS

1 - is the %system.maven.home% property used only to resolve settings.xml and plugin-registry.xml or is it also used for the Maven classpath?

2 - what is the best way to specify global settings - copy the setting.xml to the agent's maven2/conf directory or specify the system.maven.home variable per project? Can I use property references when I specify property values (e.g., system.maven.home=%env.M2_HOME%)?

5 comments
Comment actions Permalink

Hello Dimitar,

see my comments inline

I created a project, pointed it to the SVN repo and specified M2
builder with default config.

When I ran the build, it failed - I saw that it was looking for
settings.xml in the plugin directory and for user serrings in "C:\.m2"
. Since I have customized both global and user level settings, I set
%system.maven.home% to point to my local M2 installation and it fix to
solve it (the app-level config is read from there).

I still could not get TC to find my user settings and my existing repo
- they are in the standard location - "%USERPROFILE%/.m2", while TC is
trying to find them under "C:\m2".


Looks like you run the agent under a different user, whose home directory
is C:\.
Are you running the agent as a windows service?


I tried to specify the full path to settings.xml in the build config
form, but this doesn't help:

LOG:

 
> [16:03:09]: Building Maven user-level plugin registry from:
> 'C:\.m2\plugin-registry.xml'
> 
> [16:03:09]: Building Maven global-level plugin registry from:
> 'c:\tools\maven-2.0.6\conf\plugin-registry.xml'
> 
> [16:03:10]: Building Maven global-level settings from:
> 'c:\tools\maven-2.0.6\conf\settings.xml'
> 
> [16:03:10]: Building Maven user-level settings from:
> 'C:\.m2\settings.xml'
> 
> ]]>


(let me know if you need more)


Specifying an alternate settings path in the build configuration page should
work. I've checked this again on my side and it works. The message "Building
Maven user-level settings from: ..." is actually quite confusing, because
it's generated by Maven BEFORE it processes the alternate path. So don't
worry, you can ignore this.

Alternatevely, you can set the user settings path via system property "org.apache.maven.user-settings".
It has the same effect, but in this case the message "Building Maven user-level
settings from: ..." shows the proper path.

Please note, that the form field overrides the system property.


QUESTIONS

1 - is the %system.maven.home% property used only to resolve
settings.xml and plugin-registry.xml or is it also used for the Maven
classpath?


Setting maven.home (as well as M2_HOME) implies the full use of targeted
Maven, not only its configuration.


2 - what is the best way to specify global settings - copy the
setting.xml to the agent's maven2/conf directory or specify the
system.maven.home variable per project? Can I use property references
when I specify property values (e.g.,
system.maven.home=%env.M2_HOME%)?


If you have a Maven installation on the agent's machine that is used not
only by TeamCity (for example, there are users running Maven from command
line), and you want TeamCity to use the same configuration, then the best
way is to set maven.home or M2_HOME targeting that installation.

Otherwise, if you want to use non-default settings, it's better to set them
in user's settings.xml, not in the global settings. User specific settings
are located by default in ]]>\.m2\settings.xml. You can
also specify an alternate location to user settings in the build configuration
page.
The reason of not using global settings for the bundled Maven installation
is simple - when you upgrade the agent your global settings will be overwritten
and lost. We have a correspoding issue in our Jira. As a workaround use an
external installation.

You can reference env. variables in system property definitions like maven.home=%env.M2_HOME%,
but in this partucular case there is no need in this. Maven runner uses both
the env. variable and the system property (M2_HOME takes precedence).


WBR,
Sergey Anchipolevsky


0
Comment actions Permalink

Thank you, it was the user used by the agent service. Once I changed it to run under my account, everything was fine.


Two more questions:

Is there a reference of the properties that can be used to customize the agents and the different runners?

If a property is defined in the runner configuration, will it override the one on the agent? (we assume that the agent meets the requirements)

Thanks,
Dimitar

0
Comment actions Permalink

Hello Dimitar,

Thank you, it was the user used by the agent service. Once I changed
it to run under my account, everything was fine.

Two more questions:

Is there a reference of the properties that can be used to customize
the agents and the different runners?


All information about tuning agent runners is published at http://www.jetbrains.net/confluence/display/TCD/Build+Runners.


If a property is defined in the runner configuration, will it override
the one on the agent? (we assume that the agent meets the
requirements)


Not sure I understood you correctly, but I'll try to answer.

Each build is executed in a separate JVM. The system properties defined for
the agent's JVM aren't propagated to runners' JVMs. If you want a system
property to have effect during a build, the only way is to define it in a
build configuration form.


Thanks, Dimitar

WBR,
Sergey Anchipolevsky


0
Comment actions Permalink

Thanks, this answered my question. Just to make it clear - is it true that:

The properties defined in the build-agent configuration are set into the agent's JVM and not into the build-runner JVM. They are used for describing agent's capabilities and helping to pick the appropriate agent for a build.

Q: Some properties are automatically defined based on the environment - can we have more details please (I've noticed the .NET properties, there might be others)?

Q: Some of the properties are used for configuring the agent itself - are they documented?

Q: Does the agent use any env variables?

The properties defined in the build-runner config are passed to the runner JVM and they actually affect the build itself. All public properties are documented in the runner's documentation. Any environment variables defined on runner level override the OS ones.

0
Comment actions Permalink

Hello Dimitar,

Thanks, this answered my question. Just to make it clear - is it true
that:

The properties defined in the build-agent configuration are set into
the agent's JVM and not into the build-runner JVM. They are used for
describing agent's capabilities and helping to pick the appropriate
agent for a build.


true


Q: Some properties are automatically defined based on the environment
- can we have more details please (I've noticed the .NET properties,
there might be others)?


see http://www.jetbrains.net/confluence/display/TCD/SystemPropertiesofaBuild+Configuration


Q: Some of the properties are used for configuring the agent itself -
are they documented?


Unfortunately they aren't documented yet. This is a pending task.
All of them (or almost all) are listed with comments in the default buildAgent.properties.


Q: Does the agent use any env variables?


no


The properties defined in the build-runner config are passed to the
runner JVM and they actually affect the build itself. All public
properties are documented in the runner's documentation. Any
environment variables defined on runner level override the OS ones.


true

WBR,
Sergey Anchipolevsky


0

Please sign in to leave a comment.