ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Sirianni (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (IVYDE-237) Multiple eclipse projects with similar ivy library definitions results in launch config source path collisions
Date Tue, 16 Nov 2010 13:52:14 GMT

    [ https://issues.apache.org/jira/browse/IVYDE-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932463#action_12932463
] 

Eric Sirianni edited comment on IVYDE-237 at 11/16/10 8:51 AM:
---------------------------------------------------------------

Nicolas - thanks for digging a little deeper on this.

To answer your second question regarding the use case...  
You are correct in that normally this would not be an issue -- since Ivy transitively resolves
the dependencies of project A any source JAR dependencies from project B (and the source of
project B itself) should automatically be available to the eclipse debugger.

Our use case is more nuanced.  We are developing a web application using an embedded Jetty
server.  Project A is the "container" and includes the jetty JARs and some other dependencies
(apache-commons, slf4j, etc., etc.).  Project B is a "webapp" and includes dependencies like
hibernate, spring, etc.

To debug this application I want a launch configuration that has the following source path:
 - Project A deps (jetty, apache-commons, slf4j, etc.)
 - Project B deps (hibernate, spring, etc.)

This is a case where the *source* path is different from the classpath.  Specifically, the
classpath for Project A should *not* have hibernate on it, etc. as this needs to live "inside"
the webapp (WEB-INF/libs) for Project B.  So Project A does *not* depend on Project B from
an ivy perspective.  However, I'd like the "source" configurations of both Project A's ivy.xml
and Project B's ivy.xml on the eclipse launch config.  This is where we're hitting this bug.

Make sense?

      was (Author: sirianni):
    Nicolas - thanks for digging a little deeper on this.

To answer your second question regarding the use case...  
You are correct in that normally this would not be an issue -- since Ivy transitively resolves
the dependencies of project A any source JAR dependencies from project B (and the source of
project B itself) should automatically be available to the eclipse debugger.

Our use case is more nuanced.  We are developing a web application using an embedded Jetty
server.  Project A is the "container" and includes the jetty JARs and some other dependencies
(apache-commons, slf4j, etc., etc.).  Project B is a "webapp" and includes dependencies like
hibernate, spring, etc.

To debug this application I want a launch configuration that has the following source path:
 - Project A deps (jetty, apache-commons, slf4j, etc.)
 - Project B deps (hibernate, spring, etc.)
This is a case where the *source* path is different from the classpath.  Specifically, the
classpath for Project A should *not* have hibernate on it, etc. as this needs to live "inside"
the webapp (WEB-INF/libs) for Project B.  So Project A does *not* depend on Project B from
an ivy perspective.  However, I'd like the "source" configurations of both Project A's ivy.xml
and Project B's ivy.xml on the eclipse launch config.  This is where we're hitting this bug.

Make sense?
  
> Multiple eclipse projects with similar ivy library definitions results in launch config
source path collisions
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: IVYDE-237
>                 URL: https://issues.apache.org/jira/browse/IVYDE-237
>             Project: IvyDE
>          Issue Type: Bug
>          Components: launch configuration
>    Affects Versions: 2.0.0.final
>         Environment: Ubuntu 8.10, Eclipse 3.5.2, IvyDE 2.0.0.final
>            Reporter: Phil Clay
>         Attachments: ivyde_source_lookup_1.png, ivyde_source_lookup_2.png, ivyde_source_lookup_3.png,
ivyde_source_lookup_4.png, ivyde_source_lookup_5.png
>
>
> I have multiple eclipse projects with very similar project structures.
> Each eclipse project has an one ivy library pointing to an ivy.xml file at the root of
each the project.  (i.e. one ivy.xml file per project)
> The projects have various dependencies on each other, going three or four deep.  (e.g.
A depends on B, B depends on C, C depends on D, etc).  The ivy library is exported from each
project.
> I have "resolve dependencies in workspace" turned on.  It works great, the build time
project dependencies are resolved properly.  Love this!  But, I think the same thing applies
if I have this turned off.
> The problem happens when creating a launch configuration.  I noticed this when debugging.
 I created a launch configuration pointing at project A.  When stepping through a debug session,
eclipse could not find the sources for project D.  After some further investigation, this
is what I found...
> Using the default source lookup path does not include the project D.  More on that later.
 
> So, I decided to manually configure the source path.  Here's the process I followed:
> 1. I started by adding project A.  
> 2. Upon adding A, I noticed that two entries appeared in the source lookup path
>     - the project A itself
>     - the ivy library of the project
> 3. Now I add project B
> 4. Upon adding B, I noticed that only one additional entry appeared in the source lookup
path
>    - the project B itself
> The ivy library of project B did not appear (even though it is exported)
> Similarly, if I add all the projects in one step, only one ivy library appears.
> So, I believe that since each of the ivy libraries are configured the same way (Essentially
pointing to an identically named file in each project), that eclipse or IvyDE is getting confused
and only adding one of them to the source lookup path.
> I believe the same is true if I use the default source lookup path (rather than adding
projects manually).  When looking at the default source lookup path, I can only see a subset
of the depend-on projects. Usually, they only include the dependencies of one project, and
nothing transitive.
> I tried to test this theory by renaming the ivy.xml files to ivy-${projectname}.xml.
 This makes all of the ivy libraries unique, since the ivy xml file name is included as part
of the library definition.  However, now if I add multiple projects to the source lookup path,
multiple ivy libraries get added, BUT if you try to expand them, you get an error message
saying that the ivy-${projectname}.xml file doesn't exist (because it is looking for that
xml file in the root of the launch config project, rather than the project from which the
library is coming from.
> I can easily reproduce this behavior, so let me know if you need further information

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message