How to use envrionment variables in build definitions

When Maven is launched from JBE (i.e. you configured the build definition for Maven), we do essentially the same as what mvn.bat (or the mvn script) does: launch the Java VM on the main Launcher class, with certain options. The options include defining a couple of well-known properties, e.g.
-Dclassworlds.conf=...
-Dmaven.home=...
where the values are derived from the Maven home specified in the build definition.

So using ${maven.home} in the POM should work.

As with an Ant build, we don't convert arbitrary environment variables to properties visible from the POM. However, Maven apparently supports this directly using: ${env.X}. See http://maven.apache.org/pom.html#Properties

Another option is to define properties on the build definition and/or build engine, and substitute them in as properties on the Maven command line.
For example, if you define a property foo=bar, then this can be passed as a property by setting the Java VM arguments field in the build definition to:
-Dfoo=${foo}

Or you can configure the build definition to output all properties to a properties file, then refer to it from a <filter> element in the POM. See http://maven.apache.org/pom.html#BaseBuild_Element

Hope this helps,
Nick

Thanks for the enlightening tips. It covers parts of my needs.

However my understanding is that the jvm to use for maven cannot be specified that way, as maven is launched by the JBE (within its own jvm if I understand clearly):

...we do essentially the same as what mvn.bat (or the mvn script) does: launch the Java VM on the main Launcher class...

But I can specify it in the build specification (in the maven tab, maven configuration section, java home property). Unfortunately it is not in the same place in all machines.

May be I can specify a vm with the -vm argument in the jbe command file, and have a JAVA_HOME pointing to another place. I am not sure if jbe will honor the JAVA HOME when laumching MAVEN or will lauch it in its own vm. I will try.

jm

You are correct, since the Java Home property is used in JBE when launching Maven, there's no opportunity to use environment variables. You can, however, use properties. e.g. define a JAVA_HOME property on each build -engine-, then use ${JAVA_HOME} in the Java Home field of the build definition.

I am running my RTC server on RHEL 5.7 and the build engine on CentOS release 5.5. I am getting the "Unable to create symbolic link" errors. I have looked at your build topics/forums/tutorials and have only seen a comment about that lead me to believe that this error should not happen if you are running everything on a linux machine. In my setup, the server, the client -- all are linux. No windows machines are in the mix at all. So, can you please let me know what I need to do (aside from replacing all my symbolic links in my source store) to make this work as is.

thank you,
Carol

Hi Carol, could you clarify:
- which version of RTC are you using?
- is the fetch being done by JBE, or using the teamFetch Ant task?

If using JBE, it should "just work". If using teamFetch, you're likely running into 161782: teamFetch fail in loading symbolic links

Hi Carol, could you clarify:
- which version of RTC are you using?
- is the fetch being done by JBE, or using the teamFetch Ant task?

If using JBE, it should "just work". If using teamFetch, you're likely running into 161782: teamFetch fail in loading symbolic links

It is version 3.0.1 of RTC. I am using JBE. I am new to this environment and am trying to set up my build for the first time. Nowhere in my log does it say anything about TeamFetch as in the link you provided. It says when it is fetching the files.

Thank you so much for your response. I look forward to hearing how to fix this problem.

Hi Carol, could you clarify:
- which version of RTC are you using?
- is the fetch being done by JBE, or using the teamFetch Ant task?

If using JBE, it should "just work". If using teamFetch, you're likely running into 161782: teamFetch fail in loading symbolic links

It is version 3.0.1 of RTC. I am using JBE. I am new to this environment and am trying to set up my build for the first time. Nowhere in my log does it say anything about TeamFetch as in the link you provided. It says when it is fetching the files.

Thank you so much for your response. I look forward to hearing how to fix this problem.

Could you post a small section of the log around the error?

Brent Ulbricht
RTC Build Lead

Hi Carol, could you clarify:
- which version of RTC are you using?
- is the fetch being done by JBE, or using the teamFetch Ant task?

If using JBE, it should "just work". If using teamFetch, you're likely running into 161782: teamFetch fail in loading symbolic links

It is version 3.0.1 of RTC. I am using JBE. I am new to this environment and am trying to set up my build for the first time. Nowhere in my log does it say anything about TeamFetch as in the link you provided. It says when it is fetching the files.

Thank you so much for your response. I look forward to hearing how to fix this problem.

Could you post a small section of the log around the error?

Brent Ulbricht
RTC Build Lead

Absolutely!!

2011-09-18 21:11:52 running on host: cl04_lemv
2011-09-18 21:11:52 Should build occur?
2011-09-18 21:11:52 Yes: Always build a user initiated request.
2011-09-18 21:11:52 Invoking pre-build participant "com.ibm.team.build.jazzscm"
2011-09-18 21:11:52 Accepting changes into workspace "base_test_1 Building_Workspace" ...
2011-09-18 21:11:52 Deleting fetch destination "/home/p28503/buildBase" before fetching ...
2011-09-18 21:11:52 Fetching files to fetch destination "/home/p28503/buildBase" ...
com.ibm.team.build.internal.scm.SourceControlUtility$2: Status INFO: com.ibm.team.filesystem.client code=0 There were 93 errors. After correcting the problems, it is recommended that components be reloaded. The reload will be incremental, loading only the missing items. You can further reduce the reload time by reloading just the projects out of sync. null children=
at com.ibm.team.build.internal.scm.SourceControlUtility.updateFileCopyArea(SourceControlUtility.java:625)
at com.ibm.team.build.internal.engine.JazzScmPreBuildParticipant.preBuild(JazzScmPreBuildParticipant.java:238)
at com.ibm.team.build.internal.engine.BuildLoop.invokePreBuildParticipants(BuildLoop.java:844)
at com.ibm.team.build.internal.engine.BuildLoop$2.run(BuildLoop.java:650)
at java.lang.Thread.run(Thread.java:662)
Contains : 0 Unable to create symbolic link /cots/gnat/lib64/libssp.so.0 to libssp.so.0.0.0 because the underlying platform does not support symbolic links
Contains : 1 Unable to create symbolic link /cots/gnat/lib64/libssp.so to libssp.so.0.0.0 because the underlying platform does not support symbolic links
Contains : 2 Unable to create symbolic link /cots/gnat/lib64/libgcc_s.so to libgcc_s.so.1 because the underlying platform does not support symbolic links
Contains : 3 Unable to create symbolic link /cots/gnat/lib64/libgomp.so to libgomp.so.1.0.0 because the underlying platform does not support symbolic links
Contains : 4 Unable to create symbolic link /cots/gnat/lib64/libstdc++.so.6 to libstdc++.so.6.0.14 because the underlying platform does not support symbolic links
Contains : 5 Unable to create symbolic link /cots/gnat/lib64/libstdc++.so to libstdc++.so.6.0.14 because the underlying platform does not support symbolic links
Contains : 6 Unable to create symbolic link /cots/gnat/lib64/libgomp.so.1 to libgomp.so.1.0.0 because the underlying platform does not support symbolic links
Contains : 7 Unable to create symbolic link /cots/geotrans/geotrans2/suse_linux/libgeotrans.so to libgeotrans.so.1 because the underlying platform does not support symbolic links


these errors go on for several dozen more lines. Again, both the RTC server and the JBE are both being run on Linux machines. Red Hat and CentOS, respectively. So, it shouldn't have a problem creating a symbolic link. But, yet it does!

Thank you,
Carol

Hi Carol, could you clarify:
- which version of RTC are you using?
- is the fetch being done by JBE, or using the teamFetch Ant task?

If using JBE, it should "just work". If using teamFetch, you're likely running into 161782: teamFetch fail in loading symbolic links

It is version 3.0.1 of RTC. I am using JBE. I am new to this environment and am trying to set up my build for the first time. Nowhere in my log does it say anything about TeamFetch as in the link you provided. It says when it is fetching the files.

Thank you so much for your response. I look forward to hearing how to fix this problem.

Could you post a small section of the log around the error?

Brent Ulbricht
RTC Build Lead

Absolutely!!

2011-09-18 21:11:52 running on host: cl04_lemv
2011-09-18 21:11:52 Should build occur?
2011-09-18 21:11:52 Yes: Always build a user initiated request.
2011-09-18 21:11:52 Invoking pre-build participant "com.ibm.team.build.jazzscm"
2011-09-18 21:11:52 Accepting changes into workspace "base_test_1 Building_Workspace" ...
2011-09-18 21:11:52 Deleting fetch destination "/home/p28503/buildBase" before fetching ...
2011-09-18 21:11:52 Fetching files to fetch destination "/home/p28503/buildBase" ...
com.ibm.team.build.internal.scm.SourceControlUtility$2: Status INFO: com.ibm.team.filesystem.client code=0 There were 93 errors. After correcting the problems, it is recommended that components be reloaded. The reload will be incremental, loading only the missing items. You can further reduce the reload time by reloading just the projects out of sync. null children=
at com.ibm.team.build.internal.scm.SourceControlUtility.updateFileCopyArea(SourceControlUtility.java:625)
at com.ibm.team.build.internal.engine.JazzScmPreBuildParticipant.preBuild(JazzScmPreBuildParticipant.java:238)
at com.ibm.team.build.internal.engine.BuildLoop.invokePreBuildParticipants(BuildLoop.java:844)
at com.ibm.team.build.internal.engine.BuildLoop$2.run(BuildLoop.java:650)
at java.lang.Thread.run(Thread.java:662)
Contains : 0 Unable to create symbolic link /cots/gnat/lib64/libssp.so.0 to libssp.so.0.0.0 because the underlying platform does not support symbolic links
Contains : 1 Unable to create symbolic link /cots/gnat/lib64/libssp.so to libssp.so.0.0.0 because the underlying platform does not support symbolic links
Contains : 2 Unable to create symbolic link /cots/gnat/lib64/libgcc_s.so to libgcc_s.so.1 because the underlying platform does not support symbolic links
Contains : 3 Unable to create symbolic link /cots/gnat/lib64/libgomp.so to libgomp.so.1.0.0 because the underlying platform does not support symbolic links
Contains : 4 Unable to create symbolic link /cots/gnat/lib64/libstdc++.so.6 to libstdc++.so.6.0.14 because the underlying platform does not support symbolic links
Contains : 5 Unable to create symbolic link /cots/gnat/lib64/libstdc++.so to libstdc++.so.6.0.14 because the underlying platform does not support symbolic links
Contains : 6 Unable to create symbolic link /cots/gnat/lib64/libgomp.so.1 to libgomp.so.1.0.0 because the underlying platform does not support symbolic links
Contains : 7 Unable to create symbolic link /cots/geotrans/geotrans2/suse_linux/libgeotrans.so to libgeotrans.so.1 because the underlying platform does not support symbolic links


these errors go on for several dozen more lines. Again, both the RTC server and the JBE are both being run on Linux machines. Red Hat and CentOS, respectively. So, it shouldn't have a problem creating a symbolic link. But, yet it does!

Thank you,
Carol

Are you running the JBE on CentOS 5.5 64-bit or 32-bit?

Brent Ulbricht
RTC Build Lead

Hi Carol, could you clarify:
- which version of RTC are you using?
- is the fetch being done by JBE, or using the teamFetch Ant task?

If using JBE, it should "just work". If using teamFetch, you're likely running into 161782: teamFetch fail in loading symbolic links

It is version 3.0.1 of RTC. I am using JBE. I am new to this environment and am trying to set up my build for the first time. Nowhere in my log does it say anything about TeamFetch as in the link you provided. It says when it is fetching the files.

Thank you so much for your response. I look forward to hearing how to fix this problem.

Could you post a small section of the log around the error?

Brent Ulbricht
RTC Build Lead

Absolutely!!

2011-09-18 21:11:52 running on host: cl04_lemv
2011-09-18 21:11:52 Should build occur?
2011-09-18 21:11:52 Yes: Always build a user initiated request.
2011-09-18 21:11:52 Invoking pre-build participant "com.ibm.team.build.jazzscm"
2011-09-18 21:11:52 Accepting changes into workspace "base_test_1 Building_Workspace" ...
2011-09-18 21:11:52 Deleting fetch destination "/home/p28503/buildBase" before fetching ...
2011-09-18 21:11:52 Fetching files to fetch destination "/home/p28503/buildBase" ...
com.ibm.team.build.internal.scm.SourceControlUtility$2: Status INFO: com.ibm.team.filesystem.client code=0 There were 93 errors. After correcting the problems, it is recommended that components be reloaded. The reload will be incremental, loading only the missing items. You can further reduce the reload time by reloading just the projects out of sync. null children=
at com.ibm.team.build.internal.scm.SourceControlUtility.updateFileCopyArea(SourceControlUtility.java:625)
at com.ibm.team.build.internal.engine.JazzScmPreBuildParticipant.preBuild(JazzScmPreBuildParticipant.java:238)
at com.ibm.team.build.internal.engine.BuildLoop.invokePreBuildParticipants(BuildLoop.java:844)
at com.ibm.team.build.internal.engine.BuildLoop$2.run(BuildLoop.java:650)
at java.lang.Thread.run(Thread.java:662)
Contains : 0 Unable to create symbolic link /cots/gnat/lib64/libssp.so.0 to libssp.so.0.0.0 because the underlying platform does not support symbolic links
Contains : 1 Unable to create symbolic link /cots/gnat/lib64/libssp.so to libssp.so.0.0.0 because the underlying platform does not support symbolic links
Contains : 2 Unable to create symbolic link /cots/gnat/lib64/libgcc_s.so to libgcc_s.so.1 because the underlying platform does not support symbolic links
Contains : 3 Unable to create symbolic link /cots/gnat/lib64/libgomp.so to libgomp.so.1.0.0 because the underlying platform does not support symbolic links
Contains : 4 Unable to create symbolic link /cots/gnat/lib64/libstdc++.so.6 to libstdc++.so.6.0.14 because the underlying platform does not support symbolic links
Contains : 5 Unable to create symbolic link /cots/gnat/lib64/libstdc++.so to libstdc++.so.6.0.14 because the underlying platform does not support symbolic links
Contains : 6 Unable to create symbolic link /cots/gnat/lib64/libgomp.so.1 to libgomp.so.1.0.0 because the underlying platform does not support symbolic links
Contains : 7 Unable to create symbolic link /cots/geotrans/geotrans2/suse_linux/libgeotrans.so to libgeotrans.so.1 because the underlying platform does not support symbolic links


these errors go on for several dozen more lines. Again, both the RTC server and the JBE are both being run on Linux machines. Red Hat and CentOS, respectively. So, it shouldn't have a problem creating a symbolic link. But, yet it does!

Thank you,
Carol

Are you running the JBE on CentOS 5.5 64-bit or 32-bit?

Brent Ulbricht
RTC Build Lead

JBE is running on CentOS 5.5 64-bit.

thank you,
Carol