IvyDE
  1. IvyDE
  2. IVYDE-202

Another method for adding IvyDE classpath container to the WTP dynamic module tree.

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 2.1.0
    • Component/s: None
    • Labels:
      None
    • Environment:

      IBM RAD 7.5.3, Websphere 6.1.0.25

      Description

      Recently, my colleagues at work upgraded from RAD 7.5.2 to RAD 7.5.3. Before the upgrade, IvyDE classpath containers showed up in the Web Libraries tab of the JEE Module Dependencies preference page. After the upgrade, the classpath container is conspicuously missing. Manually affecting the .classpath to add the container attribute does not help to deploy the contents of the container.

      After some exhaustive debugging with WTP 3.0.4 and WTP 3.0.5, I concluded that the issue had to be somehow RAD specific. IBM's response was:

      "This rings a bell. The ability to map "User Libraries" under Web libraries was a piece of functionality that was removed between RAD 7.5.2 and 7.5.3.
      I did some digging and it seems the reason this was removed has something to do with reliability issues...
      Apparently the old behaviour can be had by enabling the preference "Allow loose classpath module dependencies" [in a RAD specific workspace preference page] although there is a scary warning accompanying it."

      1. rad_jee_page.jpg
        61 kB
        Jon Schneider
      2. ivyde-202.patch
        0.9 kB
        Jon Schneider
      3. ClasspathTestFixesFor75x.zip
        3.26 MB
        Jon Schneider

        Activity

        Hide
        Nicolas Lalevée added a comment -

        I think that for your use case we don't need to have a new configuration at the project level. We would just reuse a standard IvyDE container. What would change is the way the resolve of this container is specified. We would setup the ivy.xml, the confs, optionally resolve in the workspace, and check an new option about retrieving the dependencies which we want to build the classpath with, and make them retrieved in a WEB-INF/lib folder.

        I don't know what is an IVirtualReference thought and I don't use WTP. Would it work for you ?

        You may also want to look into IVYDE-56.

        Show
        Nicolas Lalevée added a comment - I think that for your use case we don't need to have a new configuration at the project level. We would just reuse a standard IvyDE container. What would change is the way the resolve of this container is specified. We would setup the ivy.xml, the confs, optionally resolve in the workspace, and check an new option about retrieving the dependencies which we want to build the classpath with, and make them retrieved in a WEB-INF/lib folder. I don't know what is an IVirtualReference thought and I don't use WTP. Would it work for you ? You may also want to look into IVYDE-56 .
        Hide
        Jon Schneider added a comment - - edited

        There seems to be some sort of collision between the 3.0.4 attribute and the 3.0.5 attribute that RAD is trying to suppress that causes the classpath container to not be visible in the JEE Module Dependencies table view when the product is upgraded to 7.5.3. At any rate, this is more of an IBM problem than an IvyDE problem.

        I have attached a documentation patch to the WTP Integration page that details the extra step that RAD developers will have to go through to make their classpath containers deployable.

        I'll be curious to hear from IBM what the reliability issue was.

        Show
        Jon Schneider added a comment - - edited There seems to be some sort of collision between the 3.0.4 attribute and the 3.0.5 attribute that RAD is trying to suppress that causes the classpath container to not be visible in the JEE Module Dependencies table view when the product is upgraded to 7.5.3. At any rate, this is more of an IBM problem than an IvyDE problem. I have attached a documentation patch to the WTP Integration page that details the extra step that RAD developers will have to go through to make their classpath containers deployable. I'll be curious to hear from IBM what the reliability issue was.
        Hide
        Jon Schneider added a comment -

        Sorry to keep reversing course on you, but I've discovered that this IBM specific property is not persisted when we close the workbench and reopen it. This is not an acceptable workaround. I'll post more when I hear back from IBM.

        Show
        Jon Schneider added a comment - Sorry to keep reversing course on you, but I've discovered that this IBM specific property is not persisted when we close the workbench and reopen it. This is not an acceptable workaround. I'll post more when I hear back from IBM.
        Hide
        Jon Schneider added a comment -

        IBM admits that disabling this feature was a mistake. They intended to disable the feature of WTP allowing the mapping of external jars to the JEE module dependencies, and managed to take out a bit too much. Here is the response from IBM:

        1. Why does the loose classpath module dependencies preference not persist?

        "...the 'Allow loose classpath module dependencies' preference persistence problem is a defect. I will provide you with the APAR (defect) number once it's available. I will also request a testfix for you for both RAD v7.5.3 and RAD v7.5.4."

        2. When can we expect to see classpath containers back in the JEE Module Dependencies?

        "The feature to map user defined classpath container under Web Libraries (i.e. add the user defined classpath to Java Build Path, and reference it from J2EE module dependencies > Web Libraries tab) is disabled when disabling a WTP feature in RAD. A feature request was created to enable this feature in future RAD v7.5.x release. It is currently targeted for RAD v7.5.5 which is tentatively scheduled to be released in Dec 2009."

        3. What about the warning message? Does our use case result in an unsupported application?

        "Enabling 'Allow loose classpath module dependencies' option is a supported workaround to enable the feature to map user defined classpath container under Web Libraries."

        I'll post the fix APAR when I get it. In the meantime, my documentation patch details how to get around this problem for RAD users.

        Show
        Jon Schneider added a comment - IBM admits that disabling this feature was a mistake. They intended to disable the feature of WTP allowing the mapping of external jars to the JEE module dependencies, and managed to take out a bit too much. Here is the response from IBM: 1. Why does the loose classpath module dependencies preference not persist? "...the 'Allow loose classpath module dependencies' preference persistence problem is a defect. I will provide you with the APAR (defect) number once it's available. I will also request a testfix for you for both RAD v7.5.3 and RAD v7.5.4." 2. When can we expect to see classpath containers back in the JEE Module Dependencies? "The feature to map user defined classpath container under Web Libraries (i.e. add the user defined classpath to Java Build Path, and reference it from J2EE module dependencies > Web Libraries tab) is disabled when disabling a WTP feature in RAD. A feature request was created to enable this feature in future RAD v7.5.x release. It is currently targeted for RAD v7.5.5 which is tentatively scheduled to be released in Dec 2009." 3. What about the warning message? Does our use case result in an unsupported application? "Enabling 'Allow loose classpath module dependencies' option is a supported workaround to enable the feature to map user defined classpath container under Web Libraries." I'll post the fix APAR when I get it. In the meantime, my documentation patch details how to get around this problem for RAD users.
        Hide
        Ivica Loncar added a comment - - edited

        There is a workaround that will allow RSA to load preferences:

        • export RSA preferences ( File -> Export: General -> Preferences)
        • open exported .epf file and replace
          /instance/org.eclipse.jst.j2ee/org.eclipse.jst.j2ee.preferences.allowClasspathDep=false
          with
          /instance/org.eclipse.jst.j2ee/org.eclipse.jst.j2ee.preferences.allowClasspathDep=true
        • load modified epf
        Show
        Ivica Loncar added a comment - - edited There is a workaround that will allow RSA to load preferences: export RSA preferences ( File -> Export: General -> Preferences) open exported .epf file and replace /instance/org.eclipse.jst.j2ee/org.eclipse.jst.j2ee.preferences.allowClasspathDep=false with /instance/org.eclipse.jst.j2ee/org.eclipse.jst.j2ee.preferences.allowClasspathDep=true load modified epf
        Hide
        Jon Schneider added a comment -

        Good workaround, Ivica. I added your suggestion to the open PMR with IBM.

        Show
        Jon Schneider added a comment - Good workaround, Ivica. I added your suggestion to the open PMR with IBM.
        Hide
        Nicolas Lalevée added a comment -

        So I changed the doc with Jon's patch and also with Ivica workaround. Let me know if it is OK.
        Then as far as I understand there will nothing to do on the IvyDE side as soon as the bug is fixed, right ? Could we resolve this issue as "Won't fix" or "Invalid" ?

        Show
        Nicolas Lalevée added a comment - So I changed the doc with Jon's patch and also with Ivica workaround. Let me know if it is OK. Then as far as I understand there will nothing to do on the IvyDE side as soon as the bug is fixed, right ? Could we resolve this issue as "Won't fix" or "Invalid" ?
        Hide
        Jon Schneider added a comment -

        Still waiting on IBM to send me the testfix for RAD 7.5.3 and 7.5.4. The issue will be resolved in RAD 7.5.5 such that RAD users no longer need to check "Allow loose classpath...". It is due out sometime in Dec 2009. Since Ivica's workaround is a sufficient workaround in its own right, there is no real need to wait on the IBM testfix. We can close this as Won't Fix.

        Thanks!

        Show
        Jon Schneider added a comment - Still waiting on IBM to send me the testfix for RAD 7.5.3 and 7.5.4. The issue will be resolved in RAD 7.5.5 such that RAD users no longer need to check "Allow loose classpath...". It is due out sometime in Dec 2009. Since Ivica's workaround is a sufficient workaround in its own right, there is no real need to wait on the IBM testfix. We can close this as Won't Fix. Thanks!
        Hide
        Jon Schneider added a comment - - edited

        The PMR is 00686,370,000. Feature request RATLC01407291 was created to have the feature added to future RAD v7.5.x release. I have attached the fix in the meantime. The fix for RAD 7.5.3 helps the property to persist. The fix for RAD 7.5.4 eliminates the need to have to check this property. This issue can be closed.

        Show
        Jon Schneider added a comment - - edited The PMR is 00686,370,000. Feature request RATLC01407291 was created to have the feature added to future RAD v7.5.x release. I have attached the fix in the meantime. The fix for RAD 7.5.3 helps the property to persist. The fix for RAD 7.5.4 eliminates the need to have to check this property. This issue can be closed.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jon Schneider
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development