[
https://issues.apache.org/jira/browse/IVYDE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Schneider updated IVYDE-202:
--------------------------------
Comment: was deleted
(was: Retrieve works for 90% of the dependencies, but in the case where we are
using Resolve in Workspace, some of the classpath entries are project
references. In the case where there are project references inside the IvyDE
container in a Dynamic Web Project, retrieve is not sufficient.
I think in IVYDE-56 the issue is that the path in the container does not match
that of the retrieve.
I'm considering a JEE tab on the container properties page that is shown only
for Dynamic Web projects that gives you the option to force deployability of
the container.)
> Another method for adding IvyDE classpath container to the WTP dynamic module
> tree.
> -----------------------------------------------------------------------------------
>
> Key: IVYDE-202
> URL: https://issues.apache.org/jira/browse/IVYDE-202
> Project: IvyDE
> Issue Type: Improvement
> Environment: IBM RAD 7.5.3, Websphere 6.1.0.25
> Reporter: Jon Schneider
> Attachments: ivyde-202.patch, rad_jee_page.jpg
>
>
> 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."
> Unfortunately, the "old behavior" is not restored by enabling the preference.
> Really there is no workaround currently for it unless IBM reverses course on
> their decision to disable this functionality of WTP. So here is what I
> propose (straight from the days before classpath containers were deployable
> resources):
> Add some project level option that does 2 things:
> 1. For jar classpath entries in the container, retrieve them to the
> WEB-INF/lib directory of the Dynamic Web Project (then they will get picked
> up by the Web App Libraries container?).
> 2. For project reference entries in the container, construct an
> IVirtualReference on the fly.
> I'm almost certain this is how Maven's plugin used to get around this issue
> before classpath container deployability was an option, and I know I wrote
> code to do that with a similar container a few years back.
> Suggestions?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
