Topic
  • 18 replies
  • Latest Post - ‏2013-01-28T11:14:30Z by mattia
SystemAdmin
SystemAdmin
14225 Posts

Pinned topic How does RBU support classpath variables in Java build path of a project?

‏2012-12-20T20:39:00Z |
I'm using Rational Build Utility 8.0.4 on Linux. One of the projects uses some Ant classes provided in the Ant 1.7.1 jar that is installed in the SDPShared plugins directory. So in RSA 8.0.4, under Java Build Path in the project properties window, I have this library referenced using a classpath variable that is defined within RSA and not within the project. In this case, I have

SHARED_PLUGIN_DIR/plugins/org.apache.ant_1.7.1.v20100518-1145/lib/ant.jar

If I run the projectBuild task in my build.xml I get an error:

projectGetErrors: Unbound classpath variable 'SHARED_PLUGIN_DIR/plugins/org.apache.ant_1.7.1.v20100518-1145/lib/ant.jar'

So how do I tell RBU that SHARED_PLUGIN_DIR is a classpath variable and how do I set the variable? I have a shell script that calls the runAnt.sh so I can set an environment variable if need be.
Updated on 2013-01-28T11:14:30Z at 2013-01-28T11:14:30Z by mattia
  • TroyBishop
    TroyBishop
    104 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2012-12-20T22:32:13Z  
    Hello,

    Classpath variables (defined in Windows > Preferences > Java > Build Path > Classpath Variables) are persisted as workspace preferences, so you need to know the underlying preference string and then import it in your Build Utility workspace.

    The "easy" answer to your question is to do the following in your ant script (before doing a build):

    <workspacePreferenceSet useEclipsePrefs="true" preferenceScope="instance" preferenceQualifier="org.eclipse.jdt.core" preferenceName="org.eclipse.jdt.core.classpathVariable.SHARED_PLUGIN_DIR" preferenceValue="C\:/Program Files/IBM/Rational/SDPShared" />

    (make sure you set useEclipsePrefs=true and notice the name of your variable is at the end of the preferenceName attribute value)

    This will set the SHARED_PLUGIN_DIR classpath variable to the value C:/Program Files/IBM/Rational/SDPShared.

    Now for the longer answer:

    As an alternative (and more flexible solution for the future), you could also import this using a preference file. If you decide to use the preference file (which is easier to maintain in the long run as each preference wouldn't need to be set via an individual Ant call like above) then you need to know the full preference string. In my example above, that string would be:

    /instance/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.SHARED_PLUGIN_DIR=C\:/Program Files/IBM/Rational/SDPShared

    I was able to find this string by defining the classpath variable in RAD and then exporting all preferences to disk (File > Export > General > Prefrences). Unfortunately there is no export preference filter for only the classpath variable strings (there are for other Java preferences... just not one specifically for classpath variables) which means you need to export all preferences.

    If you go with this approach then you can import the entire set of preferences from the file by using:

    <workspacePreferenceFile useEclipsePrefs="true" preferenceFileName="/path/to/prefs.epf" />

    but you'll likely want to manually manage your preference file so that you are not importing unnecessary preferences (or ones that may override the default behaviour in build utility). With that said, be careful of which strings you remove from your preference file - you'll likely want to keep the timestamp comment at the top and you need these two lines in the preference file:

    \!/=
    file_export_version=3.0

    in additional to any other preferences you need. Those 2 mentioned above are necessary when importing into a workspace (order does not matter).

    To give an example, the preference file you would want for this classpath variable would be something like:

    #Thu Dec 20 17:13:34 EST 2012
    \!/=
    /instance/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.SHARED_PLUGIN_DIR=C\:/Program Files/IBM/Rational/SDPShared
    file_export_version=3.0

    -Troy
  • SystemAdmin
    SystemAdmin
    14225 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2012-12-21T20:54:10Z  
    Hello,

    Classpath variables (defined in Windows > Preferences > Java > Build Path > Classpath Variables) are persisted as workspace preferences, so you need to know the underlying preference string and then import it in your Build Utility workspace.

    The "easy" answer to your question is to do the following in your ant script (before doing a build):

    <workspacePreferenceSet useEclipsePrefs="true" preferenceScope="instance" preferenceQualifier="org.eclipse.jdt.core" preferenceName="org.eclipse.jdt.core.classpathVariable.SHARED_PLUGIN_DIR" preferenceValue="C\:/Program Files/IBM/Rational/SDPShared" />

    (make sure you set useEclipsePrefs=true and notice the name of your variable is at the end of the preferenceName attribute value)

    This will set the SHARED_PLUGIN_DIR classpath variable to the value C:/Program Files/IBM/Rational/SDPShared.

    Now for the longer answer:

    As an alternative (and more flexible solution for the future), you could also import this using a preference file. If you decide to use the preference file (which is easier to maintain in the long run as each preference wouldn't need to be set via an individual Ant call like above) then you need to know the full preference string. In my example above, that string would be:

    /instance/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.SHARED_PLUGIN_DIR=C\:/Program Files/IBM/Rational/SDPShared

    I was able to find this string by defining the classpath variable in RAD and then exporting all preferences to disk (File > Export > General > Prefrences). Unfortunately there is no export preference filter for only the classpath variable strings (there are for other Java preferences... just not one specifically for classpath variables) which means you need to export all preferences.

    If you go with this approach then you can import the entire set of preferences from the file by using:

    <workspacePreferenceFile useEclipsePrefs="true" preferenceFileName="/path/to/prefs.epf" />

    but you'll likely want to manually manage your preference file so that you are not importing unnecessary preferences (or ones that may override the default behaviour in build utility). With that said, be careful of which strings you remove from your preference file - you'll likely want to keep the timestamp comment at the top and you need these two lines in the preference file:

    \!/=
    file_export_version=3.0

    in additional to any other preferences you need. Those 2 mentioned above are necessary when importing into a workspace (order does not matter).

    To give an example, the preference file you would want for this classpath variable would be something like:

    #Thu Dec 20 17:13:34 EST 2012
    \!/=
    /instance/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.SHARED_PLUGIN_DIR=C\:/Program Files/IBM/Rational/SDPShared
    file_export_version=3.0

    -Troy
    Hi Troy,

    I was starting to look at using a preferences file that I had exported from RSA but it wasn't working for me. I couldn't find any good examples for what I was trying to do. Fortunately, you have provided an excellent example of how to get these classpath variables working in the RBU. I was able to get the SHARED_PLUGIN_DIR variable to work using your workspacePreferenceSet example. I tweaked it a bit so that the actual path on Linux is passed in via an environment variable that I set in my build script:

    
    <!--- Check 
    
    if using Rational Build Utility --> <condition property=
    "rbu.running"> <equals arg1=
    "${eclipse.application}" arg2=
    "com.ibm.etools.j2ee.ant.RunAnt" /> </condition>   <target name=
    "set_cp_var" if=
    "rbu.running"> <property environment=
    "env"/> <echo message=
    "Setting SHARED_PLUGIN_DIR for RBU to ${env.SHARED_PLUGIN_DIR}"/> <workspacePreferenceSet useEclipsePrefs=
    "true" preferenceScope=
    "instance" preferenceQualifier=
    "org.eclipse.jdt.core" preferenceName=
    "org.eclipse.jdt.core.classpathVariable.SHARED_PLUGIN_DIR" preferenceValue=
    "${env.SHARED_PLUGIN_DIR}" /> </target>
    


    I do have a few more classpath variables that need to be set for some other projects so I may end up just loading a preferences file. I have one question: why the need for the \!/= line in the .epf file?

    Also one another issue I'm trying to figure out at the moment. For one of my ant tasks, I am calling <workspaceBuild> but it fails for one of the projects. In the dependent project's .classpath, I see:

    
    <classpathentry kind=
    "con" path=
    "org.eclipse.jst.server.core.container/com.ibm.ws.ast.st.runtime.runtimeTarget.v61/was.base.v61"/> <classpathentry kind=
    "con" path=
    "org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere v6.1 JRE"/>
    


    I'm guessing it cannot find these class path entries on the server with just RBU since I see this build error:
    
    [workspaceBuild] [0].. Message=The project was not built since its build path is incomplete. Cannot find the 
    
    class file 
    
    for java.lang.Object. Fix the build path then 
    
    try building 
    
    this project
    

    It works fine on my Linux laptop where I have both RSA and RBU installed.

    Is this where I need to use the <createWSRuntime> and tie it into the build?

    I should mention that I'm trying to use just one build.xml that will run on a system with both RSA and RBU and a Linux server with just RBU.

    Thanks for your help.
  • TroyBishop
    TroyBishop
    104 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2012-12-27T20:04:12Z  
    Hi Troy,

    I was starting to look at using a preferences file that I had exported from RSA but it wasn't working for me. I couldn't find any good examples for what I was trying to do. Fortunately, you have provided an excellent example of how to get these classpath variables working in the RBU. I was able to get the SHARED_PLUGIN_DIR variable to work using your workspacePreferenceSet example. I tweaked it a bit so that the actual path on Linux is passed in via an environment variable that I set in my build script:

    <pre class="jive-pre"> <!--- Check if using Rational Build Utility --> <condition property= "rbu.running"> <equals arg1= "${eclipse.application}" arg2= "com.ibm.etools.j2ee.ant.RunAnt" /> </condition> <target name= "set_cp_var" if= "rbu.running"> <property environment= "env"/> <echo message= "Setting SHARED_PLUGIN_DIR for RBU to ${env.SHARED_PLUGIN_DIR}"/> <workspacePreferenceSet useEclipsePrefs= "true" preferenceScope= "instance" preferenceQualifier= "org.eclipse.jdt.core" preferenceName= "org.eclipse.jdt.core.classpathVariable.SHARED_PLUGIN_DIR" preferenceValue= "${env.SHARED_PLUGIN_DIR}" /> </target> </pre>

    I do have a few more classpath variables that need to be set for some other projects so I may end up just loading a preferences file. I have one question: why the need for the \!/= line in the .epf file?

    Also one another issue I'm trying to figure out at the moment. For one of my ant tasks, I am calling <workspaceBuild> but it fails for one of the projects. In the dependent project's .classpath, I see:

    <pre class="jive-pre"> <classpathentry kind= "con" path= "org.eclipse.jst.server.core.container/com.ibm.ws.ast.st.runtime.runtimeTarget.v61/was.base.v61"/> <classpathentry kind= "con" path= "org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere v6.1 JRE"/> </pre>

    I'm guessing it cannot find these class path entries on the server with just RBU since I see this build error:
    <pre class="jive-pre"> [workspaceBuild] [0].. Message=The project was not built since its build path is incomplete. Cannot find the class file for java.lang.Object. Fix the build path then try building this project </pre>
    It works fine on my Linux laptop where I have both RSA and RBU installed.

    Is this where I need to use the <createWSRuntime> and tie it into the build?

    I should mention that I'm trying to use just one build.xml that will run on a system with both RSA and RBU and a Linux server with just RBU.

    Thanks for your help.
    To be honest, I'm not sure of the exact purpose of the \!/= entry. It comes from the Eclipse preference mechanism and all I know is that it is a flag which sets the 'export root' state to 'true', see:

    http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Fruntime%2Fpreferences%2FIExportedPreferences.html

    but I do not what that exactly means... it's just always there when you export a preference file from the UI :)

    As for your compilation error, yes, you need to define a workspace server runtime (using createWSRuntime) with an id of 'was.base.v61' (pointing to your WebSphere Application Server v6.1 install) to fix it. A server runtime is bound to your classpath using this ID (as seen in your .classpath entry). The Rational Application Developer UI automatically creates this runtime for you but, at the moment, RBU does not (it should though). Defining the server runtime will automatically create the JRE and runtime classpath containers so that all of the necessary classes are available to reference by the underlying compiler when it compiles your projects.

    -Troy
  • SystemAdmin
    SystemAdmin
    14225 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-08T16:26:07Z  
    To be honest, I'm not sure of the exact purpose of the \!/= entry. It comes from the Eclipse preference mechanism and all I know is that it is a flag which sets the 'export root' state to 'true', see:

    http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Fruntime%2Fpreferences%2FIExportedPreferences.html

    but I do not what that exactly means... it's just always there when you export a preference file from the UI :)

    As for your compilation error, yes, you need to define a workspace server runtime (using createWSRuntime) with an id of 'was.base.v61' (pointing to your WebSphere Application Server v6.1 install) to fix it. A server runtime is bound to your classpath using this ID (as seen in your .classpath entry). The Rational Application Developer UI automatically creates this runtime for you but, at the moment, RBU does not (it should though). Defining the server runtime will automatically create the JRE and runtime classpath containers so that all of the necessary classes are available to reference by the underlying compiler when it compiles your projects.

    -Troy
    Okay, so I'm getting tons of java errors because it cannot find java.lang.Object. So I tried adding a server runtime using the createWSRuntime task but am having a few problems. First, if I simply have this:

    
    <createWSRuntime targetId=
    "was.base.v7" path=
    "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId=
    "com.ibm.ws.ast.st.runtime.v70" />
    


    I get the following error:

    BUILD FAILED
    <workspace>/build.xml:5: A runtime already exists for the runtime type id 'was.base.v7'.

    I also tried to build the demo application found at A guide to the Rational build utility but I get the same error.

    So it seems RBU already has its stub runtimes defined? So if that's the case why doesn't the projectBuild task find java.lang.Object?

    I can do this:
    
    <createWSRuntime targetId=
    "was.base.v7_stub" path=
    "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId=
    "com.ibm.ws.ast.st.runtime.v70" />
    


    That will work only for the first build. After that, on subsequent builds it complains about the was.base.v7_stub runtime already existing.

    I have not installed WAS on the Linux server where RBU installed. I only have the stub runtimes I installed along with RBU.
  • SystemAdmin
    SystemAdmin
    14225 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-08T16:26:24Z  
    To be honest, I'm not sure of the exact purpose of the \!/= entry. It comes from the Eclipse preference mechanism and all I know is that it is a flag which sets the 'export root' state to 'true', see:

    http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Fruntime%2Fpreferences%2FIExportedPreferences.html

    but I do not what that exactly means... it's just always there when you export a preference file from the UI :)

    As for your compilation error, yes, you need to define a workspace server runtime (using createWSRuntime) with an id of 'was.base.v61' (pointing to your WebSphere Application Server v6.1 install) to fix it. A server runtime is bound to your classpath using this ID (as seen in your .classpath entry). The Rational Application Developer UI automatically creates this runtime for you but, at the moment, RBU does not (it should though). Defining the server runtime will automatically create the JRE and runtime classpath containers so that all of the necessary classes are available to reference by the underlying compiler when it compiles your projects.

    -Troy
    Okay, so I'm getting tons of java errors because it cannot find java.lang.Object. So I tried adding a server runtime using the createWSRuntime task but am having a few problems. First, if I simply have this:

    
    <createWSRuntime targetId=
    "was.base.v7" path=
    "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId=
    "com.ibm.ws.ast.st.runtime.v70" />
    


    I get the following error:

    BUILD FAILED
    <workspace>/build.xml:5: A runtime already exists for the runtime type id 'was.base.v7'.

    I also tried to build the demo application found at A guide to the Rational build utility but I get the same error.

    So it seems RBU already has its stub runtimes defined? So if that's the case why doesn't the projectBuild task find java.lang.Object?

    I can do this:
    
    <createWSRuntime targetId=
    "was.base.v7_stub" path=
    "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId=
    "com.ibm.ws.ast.st.runtime.v70" />
    


    That will work only for the first build. After that, on subsequent builds it complains about the was.base.v7_stub runtime already existing.

    I have not installed WAS on the Linux server where RBU installed. I only have the stub runtimes I installed along with RBU.
  • SystemAdmin
    SystemAdmin
    14225 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-08T16:31:32Z  
    Okay, so I'm getting tons of java errors because it cannot find java.lang.Object. So I tried adding a server runtime using the createWSRuntime task but am having a few problems. First, if I simply have this:

    <pre class="jive-pre"> <createWSRuntime targetId= "was.base.v7" path= "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId= "com.ibm.ws.ast.st.runtime.v70" /> </pre>

    I get the following error:

    BUILD FAILED
    <workspace>/build.xml:5: A runtime already exists for the runtime type id 'was.base.v7'.

    I also tried to build the demo application found at A guide to the Rational build utility but I get the same error.

    So it seems RBU already has its stub runtimes defined? So if that's the case why doesn't the projectBuild task find java.lang.Object?

    I can do this:
    <pre class="jive-pre"> <createWSRuntime targetId= "was.base.v7_stub" path= "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId= "com.ibm.ws.ast.st.runtime.v70" /> </pre>

    That will work only for the first build. After that, on subsequent builds it complains about the was.base.v7_stub runtime already existing.

    I have not installed WAS on the Linux server where RBU installed. I only have the stub runtimes I installed along with RBU.
    Excuse the double post. I got a strange error when I posted the message the first time and thought it didn't work.
  • mattia
    mattia
    38 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-09T11:52:38Z  
    Excuse the double post. I got a strange error when I posted the message the first time and thought it didn't work.
    Hello

    The "was.base.v7" id is a reserved one for Server tooling within RAD/RSA and you are not able to use it.

    You should use your own id (was.base.v7_stub like you tried should be fine)

    In order to get those successive errors with the runtime being "already" present you can do two things:

    1) Delete the <workspace>/.metatada folder before each run to start with a fresh workspace

    2) Change your call to <createWSRuntime> to include also failOnError attribute and set that to false. From what you have, it will look something like:

    
    <createWSRuntime targetId=
    "was.base.v7_stub" path=
    "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId=
    "com.ibm.ws.ast.st.runtime.v70" *failOnError=
    "false"* />
    


    The failOnError set to FALSE will basically skip over the runtime creation (the runtime is already there anyway)

    This problem was also fixed in version v8.5.1.
    You can also upgrade to that version if you wish.
  • SystemAdmin
    SystemAdmin
    14225 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-09T20:15:06Z  
    • mattia
    • ‏2013-01-09T11:52:38Z
    Hello

    The "was.base.v7" id is a reserved one for Server tooling within RAD/RSA and you are not able to use it.

    You should use your own id (was.base.v7_stub like you tried should be fine)

    In order to get those successive errors with the runtime being "already" present you can do two things:

    1) Delete the <workspace>/.metatada folder before each run to start with a fresh workspace

    2) Change your call to <createWSRuntime> to include also failOnError attribute and set that to false. From what you have, it will look something like:

    <pre class="jive-pre"> <createWSRuntime targetId= "was.base.v7_stub" path= "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId= "com.ibm.ws.ast.st.runtime.v70" *failOnError= "false"* /> </pre>

    The failOnError set to FALSE will basically skip over the runtime creation (the runtime is already there anyway)

    This problem was also fixed in version v8.5.1.
    You can also upgrade to that version if you wish.
    Thanks mattia for that info. I wish the RBU documentation would mention these tidbits. The documentation is rather terse in many areas. I've also been using the RAD 8.0 Programming Guide RedBook but the the RBU chapter (24) refers to a build.xml that is not in the referenced zip file.

    The projectBuild task stills fails from compilation errors because it cannot find java.lang.Object

    From my build.xml:
    
    <!--- Check 
    
    if using Rational Build Utility --> <condition property=
    "rbu.running"> <equals arg1=
    "${eclipse.application}" arg2=
    "com.ibm.etools.j2ee.ant.RunAnt" /> </condition>   <target name=
    "setupRuntime" if=
    "rbu.running"> <createWSRuntime targetId=
    "was.base.v7_stub" path=
    "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId=
    "com.ibm.ws.ast.st.runtime.v70" failOnError=
    "false"/> </target>   <target name=
    "compile" depends=
    "setupRuntime"> <eclipse.convertPath fileSystemPath=
    "${basedir}" property=
    "project.path" /> <echo>Building workspace ...</echo> <projectBuild projectName=
    "App_Domain" buildType=
    "full" disableValidators=
    "true"/> </target>
    

    Build output:
    
    setupRuntime: [createWSRuntime] A runtime already exists 
    
    for the runtime type id 
    'was.base.v7_stub'. [createWSRuntime] Creating a 
    
    new server runtime. (Begin) [createWSRuntime] ... subtask: Saving WebSphere Application Server v7.0 [createWSRuntime] Creating a 
    
    new server runtime. (Done)   compile: [echo] Building workspace ... [projectBuild] Building project: App_Domain (Begin) [projectBuild] ... subtask: Refreshing 
    '/App_Domain'. [projectBuild] ... subtask: Invoking 
    'Faceted Project Validation Builder' on 
    '/App_Domain'. [projectBuild] ... subtask: Invoking 
    'Java Builder' on 
    '/App_Domain'. [projectBuild] ... subtask: Preparing to build App_Domain [projectBuild] ... subtask: Cleaning output folder 
    
    for App_Domain [projectBuild] ... subtask: Copying resources to the output folder [projectBuild] ... subtask: Analyzing sources [projectBuild] ... subtask: Compiling App_Domain/src/com/mycompany/product/domain/util [projectBuild] ... subtask: (Found 95 errors) Compiling App_Domain/src/com/mycompany/product/domain/util ... [projectBuild] ... subtask: (Found 10900 errors + 3 warnings) Build done [projectBuild] ... subtask: Invoking 
    'Validation' on 
    '/App_Domain'. [projectBuild] The user operation is waiting 
    
    for background work to complete. (Begin) [projectBuild] The user operation is waiting 
    
    for background work to complete. (Done) [projectGetErrors] ---------- [projectGetErrors] 1. ERROR in /App_Domain [projectGetErrors] (at line 0)    org.eclipse.jdt.core.problem [projectGetErrors] The project was not built since its build path is incomplete. Cannot find the 
    
    class file 
    
    for java.lang.Object. Fix the build path then 
    
    try building 
    
    this project
    


    I have confirmed java.lang.Object is in /opt/ibm/BuildUtility/runtimes/base_v7_stub/java/jre/lib/vm.jar

    $ jar tvf /opt/ibm/BuildUtility/runtimes/base_v7_stub/java/jre/lib/vm.jar | grep lang.Object
    1555 Sun Aug 17 00:30:06 CST 2008 java/lang/Object.class

    So why can't the build task find it?

    In the project's .classpath for the JRE I have:
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere Application Server v7.0 JRE"/>

    What does the projectBuild task do with this entry? Does it try to associate it with a matching runtime or is it totally ignored?
  • SystemAdmin
    SystemAdmin
    14225 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-10T21:18:51Z  
    Thanks mattia for that info. I wish the RBU documentation would mention these tidbits. The documentation is rather terse in many areas. I've also been using the RAD 8.0 Programming Guide RedBook but the the RBU chapter (24) refers to a build.xml that is not in the referenced zip file.

    The projectBuild task stills fails from compilation errors because it cannot find java.lang.Object

    From my build.xml:
    <pre class="jive-pre"> <!--- Check if using Rational Build Utility --> <condition property= "rbu.running"> <equals arg1= "${eclipse.application}" arg2= "com.ibm.etools.j2ee.ant.RunAnt" /> </condition> <target name= "setupRuntime" if= "rbu.running"> <createWSRuntime targetId= "was.base.v7_stub" path= "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId= "com.ibm.ws.ast.st.runtime.v70" failOnError= "false"/> </target> <target name= "compile" depends= "setupRuntime"> <eclipse.convertPath fileSystemPath= "${basedir}" property= "project.path" /> <echo>Building workspace ...</echo> <projectBuild projectName= "App_Domain" buildType= "full" disableValidators= "true"/> </target> </pre>
    Build output:
    <pre class="jive-pre"> setupRuntime: [createWSRuntime] A runtime already exists for the runtime type id 'was.base.v7_stub'. [createWSRuntime] Creating a new server runtime. (Begin) [createWSRuntime] ... subtask: Saving WebSphere Application Server v7.0 [createWSRuntime] Creating a new server runtime. (Done) compile: [echo] Building workspace ... [projectBuild] Building project: App_Domain (Begin) [projectBuild] ... subtask: Refreshing '/App_Domain'. [projectBuild] ... subtask: Invoking 'Faceted Project Validation Builder' on '/App_Domain'. [projectBuild] ... subtask: Invoking 'Java Builder' on '/App_Domain'. [projectBuild] ... subtask: Preparing to build App_Domain [projectBuild] ... subtask: Cleaning output folder for App_Domain [projectBuild] ... subtask: Copying resources to the output folder [projectBuild] ... subtask: Analyzing sources [projectBuild] ... subtask: Compiling App_Domain/src/com/mycompany/product/domain/util [projectBuild] ... subtask: (Found 95 errors) Compiling App_Domain/src/com/mycompany/product/domain/util ... [projectBuild] ... subtask: (Found 10900 errors + 3 warnings) Build done [projectBuild] ... subtask: Invoking 'Validation' on '/App_Domain'. [projectBuild] The user operation is waiting for background work to complete. (Begin) [projectBuild] The user operation is waiting for background work to complete. (Done) [projectGetErrors] ---------- [projectGetErrors] 1. ERROR in /App_Domain [projectGetErrors] (at line 0) org.eclipse.jdt.core.problem [projectGetErrors] The project was not built since its build path is incomplete. Cannot find the class file for java.lang.Object. Fix the build path then try building this project </pre>

    I have confirmed java.lang.Object is in /opt/ibm/BuildUtility/runtimes/base_v7_stub/java/jre/lib/vm.jar

    $ jar tvf /opt/ibm/BuildUtility/runtimes/base_v7_stub/java/jre/lib/vm.jar | grep lang.Object
    1555 Sun Aug 17 00:30:06 CST 2008 java/lang/Object.class

    So why can't the build task find it?

    In the project's .classpath for the JRE I have:
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere Application Server v7.0 JRE"/>

    What does the projectBuild task do with this entry? Does it try to associate it with a matching runtime or is it totally ignored?
    One other note I would to make is that I was able to build the project in question on a different Linux system that had RBU, RSA 8.0.4 and WAS 7 FP 19 installed (i.e. it worked fine on my development system). I also did not need to create a runtime for the compiler to find the Java system libraries. So I'm not understanding why I need to define a runtime on the RBU-only Linux system and but is not needed for the Linux development system.

    The A guide to the Rational build utility article does a pretty good job of comparing how things work in RSA vs the equivalent RBU task. However, it does not compare the JRE system library project configuration with how RBU figures out where to find the JRE system library that was given in the .classpath file.
  • mattia
    mattia
    38 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-11T02:46:45Z  
    One other note I would to make is that I was able to build the project in question on a different Linux system that had RBU, RSA 8.0.4 and WAS 7 FP 19 installed (i.e. it worked fine on my development system). I also did not need to create a runtime for the compiler to find the Java system libraries. So I'm not understanding why I need to define a runtime on the RBU-only Linux system and but is not needed for the Linux development system.

    The A guide to the Rational build utility article does a pretty good job of comparing how things work in RSA vs the equivalent RBU task. However, it does not compare the JRE system library project configuration with how RBU figures out where to find the JRE system library that was given in the .classpath file.
    Hi Craig

    One other possible issue I see with your script is that you are not performing the import of your App_Domain project but you are building straight away which is where your classpath settings may be getting bypassed.

    Please see and use our projectImport task, http://publib.boulder.ibm.com/infocenter/radhelp/v8/topic/com.ibm.ant.tasks.doc/topics/tantprojectimport.html. Use it before the call to projectBuild.

    For reasons why it is working on your other Linux machine, I am not sure. Is your workspace .metadata folder already in place when you build on your other system or are you starting with a fresh workspace also in that case? If not, it might be that your runtime is already present, and that your import was already "performed" thereby leaving your classpaths properly configured.
  • SystemAdmin
    SystemAdmin
    14225 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-14T16:46:16Z  
    • mattia
    • ‏2013-01-11T02:46:45Z
    Hi Craig

    One other possible issue I see with your script is that you are not performing the import of your App_Domain project but you are building straight away which is where your classpath settings may be getting bypassed.

    Please see and use our projectImport task, http://publib.boulder.ibm.com/infocenter/radhelp/v8/topic/com.ibm.ant.tasks.doc/topics/tantprojectimport.html. Use it before the call to projectBuild.

    For reasons why it is working on your other Linux machine, I am not sure. Is your workspace .metadata folder already in place when you build on your other system or are you starting with a fresh workspace also in that case? If not, it might be that your runtime is already present, and that your import was already "performed" thereby leaving your classpaths properly configured.
    Hi mattia,

    Actually I do have projectImport in my build.xml just that I somehow copied an older version of the compile task when I posted here. It is done in the refresh task which is a compile task dependency.

    
    <target name=
    "info"> <echo message=
    "workspace=${workspace}" /> <echo message=
    "basedir=${basedir}" /> </target>   <target name=
    "refresh" depends=
    "info"> <projectImport projectname=
    "App_Domain" /> <eclipse.refreshLocal resource=
    "App_Domain"/>   <eclipse.convertPath fileSystemPath=
    "${basedir}" property=
    "project.path" /> <echo>Refreshing $
    {project.path
    }...</echo> <eclipse.refreshLocal resource=
    "${project.path}" depth=
    "infinite" /> </target>   <target name=
    "setupRuntime" if=
    "rbu.running"> <createWSRuntime targetId=
    "was.base.v7_stub" path=
    "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId=
    "com.ibm.ws.ast.st.runtime.v70" failOnError=
    "false"/> </target>   <target name=
    "compile" depends=
    "refresh,setupRuntime"> <eclipse.convertPath fileSystemPath=
    "${basedir}" property=
    "project.path" /> <echo>Building workspace ...</echo> <projectBuild projectName=
    "App_Domain" buildType=
    "full" disableValidators=
    "true"/> </target>
    


    Build output:
    
    info: [echo] workspace=<workspace> [echo] basedir=<workspace>/App_Domain   refresh: [projectImport] projectName=App_Domain projectLocation=
    
    null [projectImport] project.refresh [projectImport] ... subtask: Refreshing 
    '/App_Domain'. [echo] Refreshing /App_Domain...   setupRuntime: [createWSRuntime] A runtime already exists 
    
    for the runtime type id 
    'was.base.v7_stub'. [createWSRuntime] Creating a 
    
    new server runtime. (Begin) [createWSRuntime] ... subtask: Saving WebSphere Application Server v7.0 [createWSRuntime] Creating a 
    
    new server runtime. (Done)   compile: [echo] Building workspace ... [projectBuild] Building project: App_Domain (Begin) [projectBuild] ... subtask: Refreshing 
    '/App_Domain'. [projectBuild] ... subtask: Invoking 
    'Faceted Project Validation Builder' on 
    '/App_Domain'. [projectBuild] ... subtask: Invoking 
    'Java Builder' on 
    '/App_Domain'. [projectBuild] ... subtask: Preparing to build App_Domain [projectBuild] ... subtask: Cleaning output folder 
    
    for App_Domain [projectBuild] ... subtask: Copying resources to the output folder [projectBuild] ... subtask: Analyzing sources [projectBuild] ... subtask: Compiling App_Domain/src/com/mycompany/myapp/domain/util ...
    

    Build fails because java.lang.Object cannot be found

    I can modify App_Domain's .classpath and manually add the JRE jars to get java.lang.Object and java.util.* resolved but of course this is not the road I wish to take:
    
    <classpathentry kind=
    "lib" path=
    "/opt/ibm/BuildUtility/runtimes/base_v7_stub/java/jre/lib/vm.jar"/> <classpathentry kind=
    "lib" path=
    "/opt/ibm/BuildUtility/runtimes/base_v7_stub/java/jre/lib/java.util.jar"/>
    


    If I add a task to show all the defined runtimes using <listWSRuntimes>, everything looks fine there:
    
    list: [listWSRuntimes] Listing all servers (4) (Begin) [listWSRuntimes] [1] WebSphere Application Server v6.1 stub [listWSRuntimes]        Runtime ID: was.base.v61 [listWSRuntimes]        Is a stub: 
    
    true [listWSRuntimes]        Location: /opt/ibm/BuildUtility/runtimes/base_v61_stub [listWSRuntimes] [listWSRuntimes] [2] WebSphere Application Server v7.0 stub [listWSRuntimes]        Runtime ID: was.base.v7 [listWSRuntimes]        Is a stub: 
    
    true [listWSRuntimes]        Location: /opt/ibm/BuildUtility/runtimes/base_v7_stub [listWSRuntimes] [listWSRuntimes] [3] WebSphere Application Server v8.0 stub [listWSRuntimes]        Runtime ID: was.base.v8 [listWSRuntimes]        Is a stub: 
    
    true [listWSRuntimes]        Location: /opt/ibm/BuildUtility/runtimes/base_v8_stub [listWSRuntimes] [listWSRuntimes] [4] WebSphere Application Server v7.0 [listWSRuntimes]        Runtime ID: was.base.v7_stub [listWSRuntimes]        Is a stub: 
    
    false [listWSRuntimes]        Location: /opt/ibm/BuildUtility/runtimes/base_v7_stub [listWSRuntimes] [listWSRuntimes] Listing all servers (4) (Done)
    

    One difference is that for the runtime I defined, "Is a stub" is false while all the other pre-defined runtimes are set to true. I tried to use the isStub parameter but I get the error: createWSRuntime doesn't support the "isStub" attribute
    Yet, the v8 online help clearly shows it being a valid parameter. Not sure if it would make a difference.
    There doesn't seem to be a way to tell it to use one of the pre-defined runtimes.

    Is there any diagnostic info I can turn on for RBU by setting some property?
  • mattia
    mattia
    38 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-16T13:47:43Z  
    Hi mattia,

    Actually I do have projectImport in my build.xml just that I somehow copied an older version of the compile task when I posted here. It is done in the refresh task which is a compile task dependency.

    <pre class="jive-pre"> <target name= "info"> <echo message= "workspace=${workspace}" /> <echo message= "basedir=${basedir}" /> </target> <target name= "refresh" depends= "info"> <projectImport projectname= "App_Domain" /> <eclipse.refreshLocal resource= "App_Domain"/> <eclipse.convertPath fileSystemPath= "${basedir}" property= "project.path" /> <echo>Refreshing $ {project.path }...</echo> <eclipse.refreshLocal resource= "${project.path}" depth= "infinite" /> </target> <target name= "setupRuntime" if= "rbu.running"> <createWSRuntime targetId= "was.base.v7_stub" path= "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId= "com.ibm.ws.ast.st.runtime.v70" failOnError= "false"/> </target> <target name= "compile" depends= "refresh,setupRuntime"> <eclipse.convertPath fileSystemPath= "${basedir}" property= "project.path" /> <echo>Building workspace ...</echo> <projectBuild projectName= "App_Domain" buildType= "full" disableValidators= "true"/> </target> </pre>

    Build output:
    <pre class="jive-pre"> info: [echo] workspace=<workspace> [echo] basedir=<workspace>/App_Domain refresh: [projectImport] projectName=App_Domain projectLocation= null [projectImport] project.refresh [projectImport] ... subtask: Refreshing '/App_Domain'. [echo] Refreshing /App_Domain... setupRuntime: [createWSRuntime] A runtime already exists for the runtime type id 'was.base.v7_stub'. [createWSRuntime] Creating a new server runtime. (Begin) [createWSRuntime] ... subtask: Saving WebSphere Application Server v7.0 [createWSRuntime] Creating a new server runtime. (Done) compile: [echo] Building workspace ... [projectBuild] Building project: App_Domain (Begin) [projectBuild] ... subtask: Refreshing '/App_Domain'. [projectBuild] ... subtask: Invoking 'Faceted Project Validation Builder' on '/App_Domain'. [projectBuild] ... subtask: Invoking 'Java Builder' on '/App_Domain'. [projectBuild] ... subtask: Preparing to build App_Domain [projectBuild] ... subtask: Cleaning output folder for App_Domain [projectBuild] ... subtask: Copying resources to the output folder [projectBuild] ... subtask: Analyzing sources [projectBuild] ... subtask: Compiling App_Domain/src/com/mycompany/myapp/domain/util ... </pre>
    Build fails because java.lang.Object cannot be found

    I can modify App_Domain's .classpath and manually add the JRE jars to get java.lang.Object and java.util.* resolved but of course this is not the road I wish to take:
    <pre class="jive-pre"> <classpathentry kind= "lib" path= "/opt/ibm/BuildUtility/runtimes/base_v7_stub/java/jre/lib/vm.jar"/> <classpathentry kind= "lib" path= "/opt/ibm/BuildUtility/runtimes/base_v7_stub/java/jre/lib/java.util.jar"/> </pre>

    If I add a task to show all the defined runtimes using <listWSRuntimes>, everything looks fine there:
    <pre class="jive-pre"> list: [listWSRuntimes] Listing all servers (4) (Begin) [listWSRuntimes] [1] WebSphere Application Server v6.1 stub [listWSRuntimes] Runtime ID: was.base.v61 [listWSRuntimes] Is a stub: true [listWSRuntimes] Location: /opt/ibm/BuildUtility/runtimes/base_v61_stub [listWSRuntimes] [listWSRuntimes] [2] WebSphere Application Server v7.0 stub [listWSRuntimes] Runtime ID: was.base.v7 [listWSRuntimes] Is a stub: true [listWSRuntimes] Location: /opt/ibm/BuildUtility/runtimes/base_v7_stub [listWSRuntimes] [listWSRuntimes] [3] WebSphere Application Server v8.0 stub [listWSRuntimes] Runtime ID: was.base.v8 [listWSRuntimes] Is a stub: true [listWSRuntimes] Location: /opt/ibm/BuildUtility/runtimes/base_v8_stub [listWSRuntimes] [listWSRuntimes] [4] WebSphere Application Server v7.0 [listWSRuntimes] Runtime ID: was.base.v7_stub [listWSRuntimes] Is a stub: false [listWSRuntimes] Location: /opt/ibm/BuildUtility/runtimes/base_v7_stub [listWSRuntimes] [listWSRuntimes] Listing all servers (4) (Done) </pre>
    One difference is that for the runtime I defined, "Is a stub" is false while all the other pre-defined runtimes are set to true. I tried to use the isStub parameter but I get the error: createWSRuntime doesn't support the "isStub" attribute
    Yet, the v8 online help clearly shows it being a valid parameter. Not sure if it would make a difference.
    There doesn't seem to be a way to tell it to use one of the pre-defined runtimes.

    Is there any diagnostic info I can turn on for RBU by setting some property?
    Hi Craig

    Sorry for my late reply.

    First of all a suggestion, could yoo please invoke the createWSRuntime task before calling the projectImport task. This might help to start with.

    Second, I see that you are using many Eclipse defined Ant task to change classpath. Why is that? I am thinking this could be a source of problems. Could we try the script without those Eclipse task calls and see if it work with just the our RAD Ant tasks being used.
    I ask you because I know that classpaths are set with the ProjectImport call and based on the setup runtime (which you set post-import).
    In particular, I do not like the <eclipse.convertPath> call...

    One more thing, if you open your projects up in RAD (ie in the GUI workbench) , are you getting the same errors?

    Finally, I will try to follow up and help you on this issue by using this forum but if you have a greater urgency requirement please open up an IBM PMR by contacting RAD support: http://www.ibm.com/software/rational/support/contact.html?rcss=rtlrad

    Regarding the "isStub" parameter, not sure why you are getting that error (and will investigate), but in any case it should not make any significant difference whether you use that or not. Please omit it.
  • SystemAdmin
    SystemAdmin
    14225 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-16T19:44:32Z  
    • mattia
    • ‏2013-01-16T13:47:43Z
    Hi Craig

    Sorry for my late reply.

    First of all a suggestion, could yoo please invoke the createWSRuntime task before calling the projectImport task. This might help to start with.

    Second, I see that you are using many Eclipse defined Ant task to change classpath. Why is that? I am thinking this could be a source of problems. Could we try the script without those Eclipse task calls and see if it work with just the our RAD Ant tasks being used.
    I ask you because I know that classpaths are set with the ProjectImport call and based on the setup runtime (which you set post-import).
    In particular, I do not like the <eclipse.convertPath> call...

    One more thing, if you open your projects up in RAD (ie in the GUI workbench) , are you getting the same errors?

    Finally, I will try to follow up and help you on this issue by using this forum but if you have a greater urgency requirement please open up an IBM PMR by contacting RAD support: http://www.ibm.com/software/rational/support/contact.html?rcss=rtlrad

    Regarding the "isStub" parameter, not sure why you are getting that error (and will investigate), but in any case it should not make any significant difference whether you use that or not. Please omit it.
    Hi mattia,

    Yesterday or the day before, I already tried putting createWSRuntime before projectImport after I noticed in your article that this is what you had done. However, this did not fix the problem.

    The build.xml I started with is what we currently use to package our application components into jars, war and ear files using external tool configurations in RSA. This xml was created by someone several years ago who has since left the project well before I joined the team. I believe the Eclipse tasks are in there because the build won't work properly otherwise when we run it as an external tool in RSA. Perhaps the issues are fixed and they are not needed anymore in RSA 8, but I haven't tried that yet.

    I commented out all the Eclipse tasks in build.xml but the class not found problem remains.

    There are no errors when the projects are open in RSA 8.

    Our application suite is comprised of more than a dozen projects in RSA. We have several build.xml scripts to build each component of this suite (e.g. one to build the ear for our web app, others to build jars containing non-GUI components).

    When running the RBU standalone on our Linux server, I created some shell scripts which checks out projects from Subversion into the build workspace, sets the workspace variable and call RBU's runAnt.sh script passing it the build.xml. One of these shell scripts first calls RBU to build a dependent project jar before it invokes RBU a second time to build one of our domain libraries using its separate build.xml. It's this domain project library that the compiler is failing on in the projectBuild task. I have no compiler errors when I build the dependent project jar.

    This morning I looked at the .classpath file for this dependent project and noticed that it simply referred to the JRE as follows:
    
    <classpathentry kind=
    "con" path=
    "org.eclipse.jdt.launching.JRE_CONTAINER"/>
    


    If I look at the project build path for it in RSA, it has "JRE System Library [jdk]" listed. In the domain project, we are referring to the WAS 7 JRE and not the JDK System Library. So the build path has "JRE System Library [WebSphere Application Server v7.0 JRE]". Looking at the project's .classpath for this I see:
    
    <classpathentry kind=
    "con" path=
    "org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere Application Server v7.0 JRE"/>
    


    I think this is where the problem lies because if I change the .classpath for the project on the Linux server to instead use the entry from the dependent project .classpath shown above, the java compiler now finds the JRE classes!

    So it seems the problem arises when we have a Server runtime defined in the .classpath rather than a JRE System Library. RBU can't seem to associate a Server runtime defined in .classpath to that specified by a createWSRuntime task.

    I should also mention that for the dependent project build.xml, I don't even have a createWSRuntime task. However, that project doesn't use any Java EE libraries. I suspect if it did, I would get compiler errors for the Java EE classes.

    In any case, none of the RBU documentation mentions this .classpath issue that can arise when running RBU standalone. I get the impression that running RBU standalone is the exception rather than the rule. Thus my other related post about Standalone RBU is broken in Linux as I couldn't find any example uses in this scenario. I was also diverging away from the original topic so I thought it best to start a new thread to see if anyone else had tried this other than myself.

    Are you able to provide any details on how RBU matches up the JRE container in .classpath to any runtimes defined with createWSRuntime? While I may have solved the compilation problem for the domain project, I'm probably going to have the problem with our web app project since it uses Java EE classes. I can't change the .classpath to switch from the Server runtime to the JRE System Library because then the project won't build in RSA. So I still need the correct solution for mapping a Server runtime to a runtime setup by createWSRuntime in RBU.
  • TroyBishop
    TroyBishop
    104 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-16T22:19:09Z  
    • mattia
    • ‏2013-01-11T02:46:45Z
    Hi Craig

    One other possible issue I see with your script is that you are not performing the import of your App_Domain project but you are building straight away which is where your classpath settings may be getting bypassed.

    Please see and use our projectImport task, http://publib.boulder.ibm.com/infocenter/radhelp/v8/topic/com.ibm.ant.tasks.doc/topics/tantprojectimport.html. Use it before the call to projectBuild.

    For reasons why it is working on your other Linux machine, I am not sure. Is your workspace .metadata folder already in place when you build on your other system or are you starting with a fresh workspace also in that case? If not, it might be that your runtime is already present, and that your import was already "performed" thereby leaving your classpaths properly configured.
    Sorry but I've been unable to reply to this thread for the past while. Sit back and relax while I attempt to explain this - it may take awhile ;)

    Runtime to classpath mapping is based on the internal ID of the runtime and the runtime type (which you cannot see in the .classpath file). It is applied to the classpath via the org.eclipse.jst.server.core.container classpath container entry; for example:

    
    <classpathentry kind=
    "con" path=
    "org.eclipse.jst.server.core.container/com.ibm.ws.ast.st.runtime.runtimeTarget.v85/WebSphere Application Server v8.5"> ... </classpathentry>
    


    The path of this classpathentry has 3 segments, where each segment string is separated by the forward slash. The first segment shows that its a server container, the second segment defines the id of the provider (which is responsible for populating the list of JAR files, i.e. in this case the WAS 8.5 JAR files), and the third segment maps to the id of the runtime being used (WebSphere Application Server v8.5).

    This means that there needs to be a runtime defined of type 'com.ibm.ws.ast.st.runtime.v85' (which you can only find via the listRuntimeTypes task output) and has an id of 'WebSphere Application Server v8.5' in order for this container to properly resolve. There is some internal code that maps the runtime type to the classpathentry provider id (i.e. in this example, the runtime type com.ibm.ws.ast.st.runtime.v85 maps to the provider type of com.ibm.ws.ast.st.runtime.runtimeTarget.v85)

    In order to replicate the runtime definition needed for this project via an Ant task you would need to call:

    
    <createWSRuntime typeId=
    "com.ibm.ws.ast.st.runtime.v85" path=
    "/path/to/WAS8.5" targetId=
    "WebSphere Application Server v8.5" />
    


    Creating a runtime will automatically create the corresponding JRE (which maps using the JRE name, not its id). In my example above it would be to resolve an entry like this in the .classpath file:

    
    <classpathentry kind=
    "con" path=
    "org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere Application Server v8.5 JRE"> ... </classpathentry>
    


    Notice the 3rd segment is the JRE name (not id), which is the same name as the runtime name.

    If your project was created in RAD and you targeted it to a runtime version (i.e. like I did above, targeting a WAS 8.5 instance) then running the createWSRuntime task should be sufficient to setup everything you need. However, there is one problem (which is likely the issue you are seeing) :).
    When RAD automatically creates a runtime for you then the runtime id is defined as was.base.v[61 | 7 | 8 | 85]. This is meant to be a reserved id for the IDE to use so that each developer in your organization doesn't need to define their own runtime manually (in which case the id of the runtime is the name of the runtime) and ensures that the id (which is hidden) matches for all users and projects. Otherwise, you'd be getting into situations where one person defined their runtime as "WAS 8" and another "AppServer 8", and if the "WAS 8" person created a JavaEE project then it would not compile in the other persons workspace until that person created a runtime called "WAS 8" (remember the classpath mapping is based on the runtime ID, which is the runtime name when manually created).

    With all that said, I think RBU has a defect where it is not handling the IDE reserve ids properly. If RBU only has access to the stubs then it should create a runtime automatically for you with the reserved id (which will depend on the server version); however, right now I do not think it does. If you want to compile against a real WAS install, then you will need to create a runtime and specify the proper id (which is likely the internal id mentioned before); however, RBU (at least in 8.5) doesn't allow you to use the internal ID (I think the 8.0.x releases do, which is why I recommended it awhile ago). RBU (and indirectly RAD) needs to revisit this situation to handle it properly so, if you need a fix, then I would recommend opening a PMR against the Rational Application Developer product (RBU is supported by the same team). You can find information on how to do that here:

    http://www.ibm.com/software/rational/support/contact.html?rcss=rtlrad

    I hope that helps...

    -Troy
  • SystemAdmin
    SystemAdmin
    14225 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-18T17:17:06Z  
    Sorry but I've been unable to reply to this thread for the past while. Sit back and relax while I attempt to explain this - it may take awhile ;)

    Runtime to classpath mapping is based on the internal ID of the runtime and the runtime type (which you cannot see in the .classpath file). It is applied to the classpath via the org.eclipse.jst.server.core.container classpath container entry; for example:

    <pre class="jive-pre"> <classpathentry kind= "con" path= "org.eclipse.jst.server.core.container/com.ibm.ws.ast.st.runtime.runtimeTarget.v85/WebSphere Application Server v8.5"> ... </classpathentry> </pre>

    The path of this classpathentry has 3 segments, where each segment string is separated by the forward slash. The first segment shows that its a server container, the second segment defines the id of the provider (which is responsible for populating the list of JAR files, i.e. in this case the WAS 8.5 JAR files), and the third segment maps to the id of the runtime being used (WebSphere Application Server v8.5).

    This means that there needs to be a runtime defined of type 'com.ibm.ws.ast.st.runtime.v85' (which you can only find via the listRuntimeTypes task output) and has an id of 'WebSphere Application Server v8.5' in order for this container to properly resolve. There is some internal code that maps the runtime type to the classpathentry provider id (i.e. in this example, the runtime type com.ibm.ws.ast.st.runtime.v85 maps to the provider type of com.ibm.ws.ast.st.runtime.runtimeTarget.v85)

    In order to replicate the runtime definition needed for this project via an Ant task you would need to call:

    <pre class="jive-pre"> <createWSRuntime typeId= "com.ibm.ws.ast.st.runtime.v85" path= "/path/to/WAS8.5" targetId= "WebSphere Application Server v8.5" /> </pre>

    Creating a runtime will automatically create the corresponding JRE (which maps using the JRE name, not its id). In my example above it would be to resolve an entry like this in the .classpath file:

    <pre class="jive-pre"> <classpathentry kind= "con" path= "org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere Application Server v8.5 JRE"> ... </classpathentry> </pre>

    Notice the 3rd segment is the JRE name (not id), which is the same name as the runtime name.

    If your project was created in RAD and you targeted it to a runtime version (i.e. like I did above, targeting a WAS 8.5 instance) then running the createWSRuntime task should be sufficient to setup everything you need. However, there is one problem (which is likely the issue you are seeing) :).
    When RAD automatically creates a runtime for you then the runtime id is defined as was.base.v[61 | 7 | 8 | 85]. This is meant to be a reserved id for the IDE to use so that each developer in your organization doesn't need to define their own runtime manually (in which case the id of the runtime is the name of the runtime) and ensures that the id (which is hidden) matches for all users and projects. Otherwise, you'd be getting into situations where one person defined their runtime as "WAS 8" and another "AppServer 8", and if the "WAS 8" person created a JavaEE project then it would not compile in the other persons workspace until that person created a runtime called "WAS 8" (remember the classpath mapping is based on the runtime ID, which is the runtime name when manually created).

    With all that said, I think RBU has a defect where it is not handling the IDE reserve ids properly. If RBU only has access to the stubs then it should create a runtime automatically for you with the reserved id (which will depend on the server version); however, right now I do not think it does. If you want to compile against a real WAS install, then you will need to create a runtime and specify the proper id (which is likely the internal id mentioned before); however, RBU (at least in 8.5) doesn't allow you to use the internal ID (I think the 8.0.x releases do, which is why I recommended it awhile ago). RBU (and indirectly RAD) needs to revisit this situation to handle it properly so, if you need a fix, then I would recommend opening a PMR against the Rational Application Developer product (RBU is supported by the same team). You can find information on how to do that here:

    http://www.ibm.com/software/rational/support/contact.html?rcss=rtlrad

    I hope that helps...

    -Troy
    Hi Troy,

    Thanks for your excellent mapping information. It would make a great addition to the documentation. In any case, I still cannot get RBU to setup the classpath properly so that Java compiler can find the JRE classes provided with a server runtime stub.

    Here are the relevant entries from my project's .classpath which was setup using RSA 8.0.4:
    
    <classpathentry kind=
    "con" path=
    "org.eclipse.jst.server.core.container/com.ibm.ws.ast.st.runtime.runtimeTarget.v70/was.base.v7"> <attributes> <attribute name=
    "owner.project.facets" value=
    "jst.web"/> </attributes> </classpathentry>   <classpathentry kind=
    "con" path=
    "org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere Application Server v7.0 JRE"> <attributes> <attribute name=
    "owner.project.facets" value=
    "java"/> </attributes> </classpathentry>
    


    In my build.xml I create the runtime as follows:
    
    <createWSRuntime targetId=
    "WebSphere Application Server v7.0 JRE" path=
    "/opt/ibm/BuildUtility/runtimes/base_v7_stub" typeId=
    "com.ibm.ws.ast.st.runtime.v70" failOnError=
    "false"/>
    


    The compiler still cannot find any of the JRE classes (e.g. java.lang.Object). RBU 8.0.4 does setup the reserve ids:
    
    [listWSRuntimes] [2] WebSphere Application Server v7.0 stub [listWSRuntimes]        Runtime ID: was.base.v7 [listWSRuntimes]        Is a stub: 
    
    true [listWSRuntimes]        Location: /opt/ibm/BuildUtility/runtimes/base_v7_stub   [listRuntimeTypes] [3] WebSphere Application Server v7.0 [listRuntimeTypes]      Runtime type ID: com.ibm.ws.ast.st.runtime.v70 [listRuntimeTypes]      Vendor: IBM [listRuntimeTypes]      Version: 7.0 [listRuntimeTypes]      Description: WebSphere Application Server v7.0
    


    Given the reserve IDs I don't think I even need to create my own runtime. However, RBU doesn't seem to be matching up the entries in .classpath to the predefined/reserved runtime for WAS v7.
  • SystemAdmin
    SystemAdmin
    14225 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-21T20:42:04Z  
    Sorry but I've been unable to reply to this thread for the past while. Sit back and relax while I attempt to explain this - it may take awhile ;)

    Runtime to classpath mapping is based on the internal ID of the runtime and the runtime type (which you cannot see in the .classpath file). It is applied to the classpath via the org.eclipse.jst.server.core.container classpath container entry; for example:

    <pre class="jive-pre"> <classpathentry kind= "con" path= "org.eclipse.jst.server.core.container/com.ibm.ws.ast.st.runtime.runtimeTarget.v85/WebSphere Application Server v8.5"> ... </classpathentry> </pre>

    The path of this classpathentry has 3 segments, where each segment string is separated by the forward slash. The first segment shows that its a server container, the second segment defines the id of the provider (which is responsible for populating the list of JAR files, i.e. in this case the WAS 8.5 JAR files), and the third segment maps to the id of the runtime being used (WebSphere Application Server v8.5).

    This means that there needs to be a runtime defined of type 'com.ibm.ws.ast.st.runtime.v85' (which you can only find via the listRuntimeTypes task output) and has an id of 'WebSphere Application Server v8.5' in order for this container to properly resolve. There is some internal code that maps the runtime type to the classpathentry provider id (i.e. in this example, the runtime type com.ibm.ws.ast.st.runtime.v85 maps to the provider type of com.ibm.ws.ast.st.runtime.runtimeTarget.v85)

    In order to replicate the runtime definition needed for this project via an Ant task you would need to call:

    <pre class="jive-pre"> <createWSRuntime typeId= "com.ibm.ws.ast.st.runtime.v85" path= "/path/to/WAS8.5" targetId= "WebSphere Application Server v8.5" /> </pre>

    Creating a runtime will automatically create the corresponding JRE (which maps using the JRE name, not its id). In my example above it would be to resolve an entry like this in the .classpath file:

    <pre class="jive-pre"> <classpathentry kind= "con" path= "org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere Application Server v8.5 JRE"> ... </classpathentry> </pre>

    Notice the 3rd segment is the JRE name (not id), which is the same name as the runtime name.

    If your project was created in RAD and you targeted it to a runtime version (i.e. like I did above, targeting a WAS 8.5 instance) then running the createWSRuntime task should be sufficient to setup everything you need. However, there is one problem (which is likely the issue you are seeing) :).
    When RAD automatically creates a runtime for you then the runtime id is defined as was.base.v[61 | 7 | 8 | 85]. This is meant to be a reserved id for the IDE to use so that each developer in your organization doesn't need to define their own runtime manually (in which case the id of the runtime is the name of the runtime) and ensures that the id (which is hidden) matches for all users and projects. Otherwise, you'd be getting into situations where one person defined their runtime as "WAS 8" and another "AppServer 8", and if the "WAS 8" person created a JavaEE project then it would not compile in the other persons workspace until that person created a runtime called "WAS 8" (remember the classpath mapping is based on the runtime ID, which is the runtime name when manually created).

    With all that said, I think RBU has a defect where it is not handling the IDE reserve ids properly. If RBU only has access to the stubs then it should create a runtime automatically for you with the reserved id (which will depend on the server version); however, right now I do not think it does. If you want to compile against a real WAS install, then you will need to create a runtime and specify the proper id (which is likely the internal id mentioned before); however, RBU (at least in 8.5) doesn't allow you to use the internal ID (I think the 8.0.x releases do, which is why I recommended it awhile ago). RBU (and indirectly RAD) needs to revisit this situation to handle it properly so, if you need a fix, then I would recommend opening a PMR against the Rational Application Developer product (RBU is supported by the same team). You can find information on how to do that here:

    http://www.ibm.com/software/rational/support/contact.html?rcss=rtlrad

    I hope that helps...

    -Troy
    I should re-iterate here that running our build.xml files via RBU on my Linux laptop do not require me to use the createWSRuntime task. RBU works perfectly fine with the classpath entries in the .classpath files in that environment. I have RSA for WAS 8.0.4 installed on the laptop while it is not installed on the separate Linux server so I do wonder if having RSA installed helps RBU to work as expected.
  • SystemAdmin
    SystemAdmin
    14225 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-22T16:21:47Z  
    Subsequent issue not resolved
  • mattia
    mattia
    38 Posts

    Re: How does RBU support classpath variables in Java build path of a project?

    ‏2013-01-28T11:14:30Z  
    I should re-iterate here that running our build.xml files via RBU on my Linux laptop do not require me to use the createWSRuntime task. RBU works perfectly fine with the classpath entries in the .classpath files in that environment. I have RSA for WAS 8.0.4 installed on the laptop while it is not installed on the separate Linux server so I do wonder if having RSA installed helps RBU to work as expected.
    Hi Craig

    What you call "reserves" are also known as Stub runtimes. If you create your projects in RSA and use a stub runtime, then you should be able to build those same projects in RBU without calling the createWSRuntime task or by using this same task to create the "stub" runtime.