Topic
  • 11 replies
  • Latest Post - ‏2012-11-14T13:39:24Z by MartinHansson
sdibm
sdibm
19 Posts

Pinned topic put oxf under source control?

‏2012-11-08T00:25:12Z |
Running Rhapsody 7.6.1.2 under windows 7. Should we and can we put the OXF under source control. We don't want every individual using different OXF binaries.

I started looking into this and it seems the OXF is found through the OMROOT variable in rhapsody.ini. If I change this variable then it seems I have to move a lot if not all of the Rhapsody application files. I am only really interested in putting the OXF libraries under source control. Is there a better way to do what I am trying to do?
Updated on 2012-11-14T13:39:24Z at 2012-11-14T13:39:24Z by MartinHansson
  • Jeff_Cohen
    Jeff_Cohen
    71 Posts

    Re: put oxf under source control?

    ‏2012-11-08T00:52:05Z  
    Yes there is a better way, don't put OXF under source control. I'm not being a jerk here, it just sounds like it.

    The framework is not something you are developing or modifying. It is the base code that comes from IBM, just like the Rhapsody.exe file. For your routine day-to-day development, you don't put it under source control, so don't put the oxf files either. If you are making modifications to the OXF to impliment your own containers or patterns, then store your modifications outside the /Share file. If you don't, your IT department may accidently delete your modifications when they upgrade the version of Rhapsody on your machine.

    You may also have missed one of the development mechanisms built into Rhapsody. The Rhaposdy developers designed the tool for team development. The entire share directory is meant to be shared by the development team. Therefore, you can (should??) put C:\Users\<your user name here>\IBM\Rational\Rhapsody\8.0 on a shared server somewhere. Doing so ensures that the entire team uses the same properties, has access to the same RTOS build variables, and uses the same version of the framework. To access this shared version, change each users value of OMROOT to that server location. This description is important because if you do customize the OXF, you DO need to put everything under source control. You only need to put those files you modified. The OXF is built with interface classes, so your modifications realize (are derived from) the interface classes.

    If you have a contractual contract to be able to recreate any released environment, then put put all of the Rhapsody files under release room control. I did that for versions of s/w released to government agencies. They always want you to be able to recreate any environment, but I was never actually required to do so.

    Hope this helps and I can add more clarification if needed.
  • sdibm
    sdibm
    19 Posts

    Re: put oxf under source control?

    ‏2012-11-08T01:22:04Z  
    Yes there is a better way, don't put OXF under source control. I'm not being a jerk here, it just sounds like it.

    The framework is not something you are developing or modifying. It is the base code that comes from IBM, just like the Rhapsody.exe file. For your routine day-to-day development, you don't put it under source control, so don't put the oxf files either. If you are making modifications to the OXF to impliment your own containers or patterns, then store your modifications outside the /Share file. If you don't, your IT department may accidently delete your modifications when they upgrade the version of Rhapsody on your machine.

    You may also have missed one of the development mechanisms built into Rhapsody. The Rhaposdy developers designed the tool for team development. The entire share directory is meant to be shared by the development team. Therefore, you can (should??) put C:\Users\<your user name here>\IBM\Rational\Rhapsody\8.0 on a shared server somewhere. Doing so ensures that the entire team uses the same properties, has access to the same RTOS build variables, and uses the same version of the framework. To access this shared version, change each users value of OMROOT to that server location. This description is important because if you do customize the OXF, you DO need to put everything under source control. You only need to put those files you modified. The OXF is built with interface classes, so your modifications realize (are derived from) the interface classes.

    If you have a contractual contract to be able to recreate any released environment, then put put all of the Rhapsody files under release room control. I did that for versions of s/w released to government agencies. They always want you to be able to recreate any environment, but I was never actually required to do so.

    Hope this helps and I can add more clarification if needed.
    Not sure I get what you mean.
    Are you saying to install Rhapsody on a network drive which is not under source control?

    my Rhapsody is installed under c:\program files x86\IBM\Rational\Rhapsody\7.6.1
  • shanz9903
    shanz9903
    283 Posts

    Re: put oxf under source control?

    ‏2012-11-08T10:22:25Z  
    • sdibm
    • ‏2012-11-08T01:22:04Z
    Not sure I get what you mean.
    Are you saying to install Rhapsody on a network drive which is not under source control?

    my Rhapsody is installed under c:\program files x86\IBM\Rational\Rhapsody\7.6.1
    We put any modified files from the oxf into svn. All unmodified oxf files/folders are set in svn to 'svn:ignore'.
    We don't use a server.
    Each user will install Rhapsody as normal then checkout from svn into the (non-empty) share folder.
    If a user does a svn update, then only the modified files can ever be updated since all non-modified files are automatically ignored by svn.
  • sdibm
    sdibm
    19 Posts

    Re: put oxf under source control?

    ‏2012-11-08T13:59:52Z  
    • shanz9903
    • ‏2012-11-08T10:22:25Z
    We put any modified files from the oxf into svn. All unmodified oxf files/folders are set in svn to 'svn:ignore'.
    We don't use a server.
    Each user will install Rhapsody as normal then checkout from svn into the (non-empty) share folder.
    If a user does a svn update, then only the modified files can ever be updated since all non-modified files are automatically ignored by svn.
    I'm not familiar with SVN, we use clearcase. How do you checkout into another directory?

    My clearcase view is totally different drive then my C:\ drive. I'd like to tell Rhapsody to look in my clearcase drive for the "share" directory, but I don't see how you can do that. The only thing I see you can do is change OMROOT which is the whole rhapsody installation, not just the share drive. Or am I mistaken?

    If windows had links like unix, I could create a link to a shared "share" drive. But I don't see how you can share the "share" directory in windows with clearcase.
  • sdibm
    sdibm
    19 Posts

    Re: put oxf under source control?

    ‏2012-11-08T14:08:15Z  
    • sdibm
    • ‏2012-11-08T13:59:52Z
    I'm not familiar with SVN, we use clearcase. How do you checkout into another directory?

    My clearcase view is totally different drive then my C:\ drive. I'd like to tell Rhapsody to look in my clearcase drive for the "share" directory, but I don't see how you can do that. The only thing I see you can do is change OMROOT which is the whole rhapsody installation, not just the share drive. Or am I mistaken?

    If windows had links like unix, I could create a link to a shared "share" drive. But I don't see how you can share the "share" directory in windows with clearcase.
    Nevermind, I was mistaken, OMROOT is the share drive. I am trying that now and it looks promising. Still I would have to add the whole "share" drive to source control if I change OMROOT, otherwise each individual would have to copy over the contents of their share drive and have it view private.
  • MartinHansson
    MartinHansson
    59 Posts

    Re: put oxf under source control?

    ‏2012-11-08T14:30:46Z  
    • sdibm
    • ‏2012-11-08T14:08:15Z
    Nevermind, I was mistaken, OMROOT is the share drive. I am trying that now and it looks promising. Still I would have to add the whole "share" drive to source control if I change OMROOT, otherwise each individual would have to copy over the contents of their share drive and have it view private.
    We have the entire Share in source control (ClearCase). There are certanly pros and cons to it.

    We have tried to strip it down and remove a lot of files that we do not use. Otherwise it takes a lot of time to create a snapshot view (we can't run dynamic for performance reasons).

    We have then created a script that starts rhapsody with OMROOT set to the path in the view you are working from. I.e. the OMROOT in rhapsody.ini is commented out.

    This works well for us but upgrading Rhapsody to a new version is a PITA when we have to compare the changes we have done to some of the files with whatever IBM has changed/added.
  • sdibm
    sdibm
    19 Posts

    Re: put oxf under source control?

    ‏2012-11-08T15:43:16Z  
    We have the entire Share in source control (ClearCase). There are certanly pros and cons to it.

    We have tried to strip it down and remove a lot of files that we do not use. Otherwise it takes a lot of time to create a snapshot view (we can't run dynamic for performance reasons).

    We have then created a script that starts rhapsody with OMROOT set to the path in the view you are working from. I.e. the OMROOT in rhapsody.ini is commented out.

    This works well for us but upgrading Rhapsody to a new version is a PITA when we have to compare the changes we have done to some of the files with whatever IBM has changed/added.
    what does your script for starting rhapsody look like? I'd love to pass in OMROOT as an argument to rhapsody. another possibility would be to set OMROOT to an environmental variable. I tried setting OMROOT=$OM_ROOT and OMROOT=%OM_ROOT% but neither worked.
  • shanz9903
    shanz9903
    283 Posts

    Re: put oxf under source control?

    ‏2012-11-08T17:07:48Z  
    • sdibm
    • ‏2012-11-08T15:43:16Z
    what does your script for starting rhapsody look like? I'd love to pass in OMROOT as an argument to rhapsody. another possibility would be to set OMROOT to an environmental variable. I tried setting OMROOT=$OM_ROOT and OMROOT=%OM_ROOT% but neither worked.
    I use junctions a lot which are akin to symbolic links in linux.
    Link: See http://technet.microsoft.com/en-us/sysinternals/bb896768
  • MartinHansson
    MartinHansson
    59 Posts

    Re: put oxf under source control?

    ‏2012-11-09T07:12:33Z  
    • sdibm
    • ‏2012-11-08T15:43:16Z
    what does your script for starting rhapsody look like? I'd love to pass in OMROOT as an argument to rhapsody. another possibility would be to set OMROOT to an environmental variable. I tried setting OMROOT=$OM_ROOT and OMROOT=%OM_ROOT% but neither worked.
    We run in a windows environment so this would be different for Linux but I would assume the options are the same.
    Note that OMROOT as to be removed from the .ini file or it will supersede the command line (which is ass backwards as far as I'm concerned).

    We use a bat file:

    @echo off
    rem This bat file is used to launch an developer version of Rhapsody with
    rem OMROOT set to the view where the script resides
    rem
    cd ..
    rem We need to support two differnt paths (maha 110708)
    ver | find "XP" > nul
    if %ERRORLEVEL% == 0 goto win_xp
    start "" "C:\Program Files (x86)\IBM\Rational\Rhapsody\7.6.1\rhapsody.exe" -dev_ed -lang=cpp -cmd=loadjvm -cmd=setomroot %~dp0\Libs\Rhapsody761\Share
    @goto end
    :win_xp
    start "" "C:\Program Files\IBM\Rational\Rhapsody\7.6.1\rhapsody.exe" -dev_ed -lang=cpp -cmd=loadjvm -cmd=setomroot %~dp0\Libs\Rhapsody761\Share
    :end
  • fordP
    fordP
    6 Posts

    Re: put oxf under source control?

    ‏2012-11-14T13:21:06Z  
    We run in a windows environment so this would be different for Linux but I would assume the options are the same.
    Note that OMROOT as to be removed from the .ini file or it will supersede the command line (which is ass backwards as far as I'm concerned).

    We use a bat file:

    @echo off
    rem This bat file is used to launch an developer version of Rhapsody with
    rem OMROOT set to the view where the script resides
    rem
    cd ..
    rem We need to support two differnt paths (maha 110708)
    ver | find "XP" > nul
    if %ERRORLEVEL% == 0 goto win_xp
    start "" "C:\Program Files (x86)\IBM\Rational\Rhapsody\7.6.1\rhapsody.exe" -dev_ed -lang=cpp -cmd=loadjvm -cmd=setomroot %~dp0\Libs\Rhapsody761\Share
    @goto end
    :win_xp
    start "" "C:\Program Files\IBM\Rational\Rhapsody\7.6.1\rhapsody.exe" -dev_ed -lang=cpp -cmd=loadjvm -cmd=setomroot %~dp0\Libs\Rhapsody761\Share
    :end
    We are using a very similar approach than MartinHansson:
    The share folder is in source control and we start rhapsody via a batch file.
    Instead of using the commandline switch "-cmd=setomroot" we are setting the environment variable directly.

    What I can not confirm is, that you have to remove OMROOT from your rhapsody.ini. You can leave rhapsody.ini as it is. If you pass OMROOT (either as environment or with "-cmd=setomroot") it will override the setting from rhapsody.ini
  • MartinHansson
    MartinHansson
    59 Posts

    Re: put oxf under source control?

    ‏2012-11-14T13:39:24Z  
    • fordP
    • ‏2012-11-14T13:21:06Z
    We are using a very similar approach than MartinHansson:
    The share folder is in source control and we start rhapsody via a batch file.
    Instead of using the commandline switch "-cmd=setomroot" we are setting the environment variable directly.

    What I can not confirm is, that you have to remove OMROOT from your rhapsody.ini. You can leave rhapsody.ini as it is. If you pass OMROOT (either as environment or with "-cmd=setomroot") it will override the setting from rhapsody.ini
    I'm 100% sure that leaving OMROOT in the .ini file does not work for us. Pretty much every time we get a new developer they miss the instruction to remove it and get strange build errors that we can always trace back to them using the "default" OMROOT.

    Having said that it could well be something else in out environment that mandates that removal.