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

Phil Clay commented on IVYDE-237:
---------------------------------

Tried using build 181, and everything appears to be working well.

Thanks Nicolas!!  This is awesome.


> 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
>            Assignee: Nicolas Lalevée
>             Fix For: trunk
>
>         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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to