Skip to main content

Hello,


we use MFED for Eclipse remote COBOL projects. As is suggested by the eclipse community as a good practice, we wish to share the full MFED Eclipse project between developers. This means, files like .project and .cobolProj should be shared as well.

In addition, we wish to be able to use "Remote Linked Folders". For example, the build output should go into a project folder which is linked to a remote folder that is referenced by the MFES region. Each developer has her own MFES region that is configured to look for deployed programs ("JES program path") under a folder "/users/<myuserid>/mfes/loadlib". This way, after a build no (re-)deployment into the MFES is necessary to run tests. The parent folder "/users/<myuserid>" folder is mapped by Samba onto a drive D: on the Windows box that runs the MFED.

However, adding remote linked folders to a project results in a .project file that contains the username. For exampe (irrelevant details snipped):

<projectDescription>
    <name>someproject</name>
    ...
    <linkedResources>
        <link>
            <name>loadlib</name>
            <type>2</type>
            <locationURI>rse://MYHOST.MYURL.COM/users/myuserid/enterpriseserver/loadlib</locationURI>
        </link>
    </linkedResources>
</projectDescription>

This makes the project un-sharable between users. After some experimentation, we have been able to work around this problem by using external XML-Entity References that point to a file on the Samba-Drive D: of the user. On her drive each user has a file "userid.txt" which contains only her userid. This is substituted into the rse:-Path. This seems to work, but requires additional setup, and one has to be careful not to re-generate the project file.

<!DOCTYPE projectDescription [
<!ENTITY user SYSTEM "D:/userid.txt">
]>
<projectDescription>
    <name>someproject</name>
    ...
    <linkedResources>
        <link>
            <name>loadlib</name>
            <type>2</type>
            <locationURI>rse://MYHOST.MYURL.COM/users/&userid;/enterpriseserver/loadlib</locationURI>
        </link>
    </linkedResources>
</projectDescription>

So, my question is, is there a better solution? How can we use user-specific remote linked folders and still be able to share projects between users? Is there a way to somehow use the USERNAME environment variable or some such thing in the rse:URI?


Regards,

aru


#EnterpriseDeveloper

Hello,


we use MFED for Eclipse remote COBOL projects. As is suggested by the eclipse community as a good practice, we wish to share the full MFED Eclipse project between developers. This means, files like .project and .cobolProj should be shared as well.

In addition, we wish to be able to use "Remote Linked Folders". For example, the build output should go into a project folder which is linked to a remote folder that is referenced by the MFES region. Each developer has her own MFES region that is configured to look for deployed programs ("JES program path") under a folder "/users/<myuserid>/mfes/loadlib". This way, after a build no (re-)deployment into the MFES is necessary to run tests. The parent folder "/users/<myuserid>" folder is mapped by Samba onto a drive D: on the Windows box that runs the MFED.

However, adding remote linked folders to a project results in a .project file that contains the username. For exampe (irrelevant details snipped):

<projectDescription>
    <name>someproject</name>
    ...
    <linkedResources>
        <link>
            <name>loadlib</name>
            <type>2</type>
            <locationURI>rse://MYHOST.MYURL.COM/users/myuserid/enterpriseserver/loadlib</locationURI>
        </link>
    </linkedResources>
</projectDescription>

This makes the project un-sharable between users. After some experimentation, we have been able to work around this problem by using external XML-Entity References that point to a file on the Samba-Drive D: of the user. On her drive each user has a file "userid.txt" which contains only her userid. This is substituted into the rse:-Path. This seems to work, but requires additional setup, and one has to be careful not to re-generate the project file.

<!DOCTYPE projectDescription [
<!ENTITY user SYSTEM "D:/userid.txt">
]>
<projectDescription>
    <name>someproject</name>
    ...
    <linkedResources>
        <link>
            <name>loadlib</name>
            <type>2</type>
            <locationURI>rse://MYHOST.MYURL.COM/users/&userid;/enterpriseserver/loadlib</locationURI>
        </link>
    </linkedResources>
</projectDescription>

So, my question is, is there a better solution? How can we use user-specific remote linked folders and still be able to share projects between users? Is there a way to somehow use the USERNAME environment variable or some such thing in the rse:URI?


Regards,

aru


#EnterpriseDeveloper

Correction: Above in the second snippet it should read

<!ENTITY userid SYSTEM "D:/userid.txt">

Hello,


we use MFED for Eclipse remote COBOL projects. As is suggested by the eclipse community as a good practice, we wish to share the full MFED Eclipse project between developers. This means, files like .project and .cobolProj should be shared as well.

In addition, we wish to be able to use "Remote Linked Folders". For example, the build output should go into a project folder which is linked to a remote folder that is referenced by the MFES region. Each developer has her own MFES region that is configured to look for deployed programs ("JES program path") under a folder "/users/<myuserid>/mfes/loadlib". This way, after a build no (re-)deployment into the MFES is necessary to run tests. The parent folder "/users/<myuserid>" folder is mapped by Samba onto a drive D: on the Windows box that runs the MFED.

However, adding remote linked folders to a project results in a .project file that contains the username. For exampe (irrelevant details snipped):

<projectDescription>
    <name>someproject</name>
    ...
    <linkedResources>
        <link>
            <name>loadlib</name>
            <type>2</type>
            <locationURI>rse://MYHOST.MYURL.COM/users/myuserid/enterpriseserver/loadlib</locationURI>
        </link>
    </linkedResources>
</projectDescription>

This makes the project un-sharable between users. After some experimentation, we have been able to work around this problem by using external XML-Entity References that point to a file on the Samba-Drive D: of the user. On her drive each user has a file "userid.txt" which contains only her userid. This is substituted into the rse:-Path. This seems to work, but requires additional setup, and one has to be careful not to re-generate the project file.

<!DOCTYPE projectDescription [
<!ENTITY user SYSTEM "D:/userid.txt">
]>
<projectDescription>
    <name>someproject</name>
    ...
    <linkedResources>
        <link>
            <name>loadlib</name>
            <type>2</type>
            <locationURI>rse://MYHOST.MYURL.COM/users/&userid;/enterpriseserver/loadlib</locationURI>
        </link>
    </linkedResources>
</projectDescription>

So, my question is, is there a better solution? How can we use user-specific remote linked folders and still be able to share projects between users? Is there a way to somehow use the USERNAME environment variable or some such thing in the rse:URI?


Regards,

aru


#EnterpriseDeveloper

Hi,

Tough one!  I don't know there is a better solution to be honest.  I think the the expansion of your users' paths is done by the underlying Eclipse IDE code that we rely upon.  As you've obviously noted, the path is rather frustratingly expanded when you directly select the target directory when adding the linked resource.

I'm sure you've played around with the options offered when you create the linked folder (ie click the Variables... button) that let you select paths based upon such path variables as ${PROJECT_LOC}, ${WORKSPACE_LOC} etc.  

I've struggled with this myself and you can see how I tried to resolve a similar problem with the .project file in the BankDemo sample.  Here's the relevant excerpt:

<linkedResources>

<link>

<name>loadlib</name>

<type>2</type>

<locationURI>loadlib</locationURI>

</link>

</linkedResources>

<variableList>

<variable>

<name>loadlib</name>

<value>${PARENT-3-PROJECT_LOC}/System/loadlib</value>

</variable>

</variableList>

you can see how the locationURI refers to the variable value 'loadlib' which in turn is defined by way of a relative location to where the project is.  It's possible that you might be able to do something similar but it might take a bit of trial and error depending on your exact system setup.

Terms & ConditionsAccessibility statement