IvyDE
  1. IvyDE
  2. IVYDE-56

References to dependent *.jar files reference the cache and not the local retrive directory

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2.0.beta1
    • Component/s: classpath container
    • Labels:
      None
    • Environment:

      Windows, Eclispe 3.2.0, IvyDE 1.2.0, Ivy 1.4.0, JDK 1.5.x

      Description

      On the IvyDE settings screen I have checked the option: "do retrive after resolve".
      I gave a "lib folder" in my Eclispe project as target for the retrive.
      IvyDE still shows in mouse overs on the ivy container classpath entries like: C:{my stuff}\.ivy\cache[org][artifact]-[revision].[ext], the local "lib folder" is ignored.
      In other words, the Eclispe build fails if I manually deleted the cache for some reason, until I do a manual resolve again.

      Background:
      For my daily work I use Eclipse. For full builds I use Ant. Ant build and Eclipse build should work as similar as possible. While classpath dependencies during compilation from Ant are resloved via the local lib files, Eclipse resolves them via the ivy cash. This happends besides that IvyDE as well copies the files into the project. As a result of this I can't move the project to my note book where I don't have access to my ivy cache directory. (As a workaround I remove the ivy container from .classpath and add the jar files from the "lib folder" manually, however this is error prone.

      Feature Request:
      As like with ant, which retrives all needed *.jar files, I like IvyDE to be able to retrieve into the exact same folder like my ant build.xml. I like the classpath container of Ivy to use this folder to provide the *.jar files on the classpath for eclispe.

      (Sorry for the long description, I liked to make it as clear as possible, as I realy wonder why IvyDE actualy behaves different ;D )

      1. screenshot-1.jpg
        165 kB
        Claudio Miranda
      2. IVYDE-56-r732294.patch
        23 kB
        Nicolas Lalevée

        Issue Links

          Activity

          Hide
          Xavier Hanin added a comment -

          IvyDE behaves differently only because it was easier to do like that. But I agree this would improve IvyDE usability. You have my vote

          Show
          Xavier Hanin added a comment - IvyDE behaves differently only because it was easier to do like that. But I agree this would improve IvyDE usability. You have my vote
          Hide
          Nicolas Lalevée added a comment -

          I have started to implement a solution to this, see the attached patch.
          But I came to the point where there is an issue between the retrieved configurations and the resolved ones. They may not be the same. Actually I think the UI must change quite a bit.

          Actually I see two kind of retrieve job:

          • the one which is used to setup the classpath of the Java project.
          • and another one which is just about retrieving jars (or whatever else like licenses) into a particular folder (like a WEB-INF/lib).

          So the second kind of retrieve job is quite independant of the classpath management, so its configuration should be independant of the IvyDE classpath container. So this would be configured in the classical project properties configuration panel. And they would be launched by some new entries in the context menu of the project.

          Then in the configuration of the IvyDE classpath container, there won't any more any retrieve tab, but just a check box saying that the classpath container should be based on retrieved artifacts rather than directly on path to the cache.

          Show
          Nicolas Lalevée added a comment - I have started to implement a solution to this, see the attached patch. But I came to the point where there is an issue between the retrieved configurations and the resolved ones. They may not be the same. Actually I think the UI must change quite a bit. Actually I see two kind of retrieve job: the one which is used to setup the classpath of the Java project. and another one which is just about retrieving jars (or whatever else like licenses) into a particular folder (like a WEB-INF/lib). So the second kind of retrieve job is quite independant of the classpath management, so its configuration should be independant of the IvyDE classpath container. So this would be configured in the classical project properties configuration panel. And they would be launched by some new entries in the context menu of the project. Then in the configuration of the IvyDE classpath container, there won't any more any retrieve tab, but just a check box saying that the classpath container should be based on retrieved artifacts rather than directly on path to the cache.
          Hide
          Phi Vu Nguyen added a comment -

          How do I get the patch fix? Is there any plan to put this into the release?

          Thanks.

          Phi

          Show
          Phi Vu Nguyen added a comment - How do I get the patch fix? Is there any plan to put this into the release? Thanks. Phi
          Hide
          Nicolas Lalevée added a comment -

          There is no plan to put that patch in a release because as I explained, there is a mistmatch between the retrieved configurations and the resolved ones. A proper solution for me is to change the way the UI is organized about retrieving dependencies.

          Show
          Nicolas Lalevée added a comment - There is no plan to put that patch in a release because as I explained, there is a mistmatch between the retrieved configurations and the resolved ones. A proper solution for me is to change the way the UI is organized about retrieving dependencies.
          Hide
          Claudio Miranda added a comment -

          Is there any workaround for this issue ?

          See the screenshot, I have 2 different projects, each one has a ivy.xml, but eclipse uses all files in the ivy cache.

          Show
          Claudio Miranda added a comment - Is there any workaround for this issue ? See the screenshot, I have 2 different projects, each one has a ivy.xml, but eclipse uses all files in the ivy cache.
          Hide
          Marcel Wagner added a comment -

          I think the problem is major. If you have a project producing e.g. project-snapshot.jar. This jar is referenced in other projects, so the other eclipse projects references cache/project-snapshot.jar and now ivyde seems unable to resolve and replace an updated project-snapshot.jar. Sure, the jar is locked through the other eclipse projects ;-(. It is essential that the eclipse classpath is set to the retrieved location and NOT to the cache dir. This can't functioning with a "snapshot working model"!

          Show
          Marcel Wagner added a comment - I think the problem is major. If you have a project producing e.g. project-snapshot.jar. This jar is referenced in other projects, so the other eclipse projects references cache/project-snapshot.jar and now ivyde seems unable to resolve and replace an updated project-snapshot.jar. Sure, the jar is locked through the other eclipse projects ;-(. It is essential that the eclipse classpath is set to the retrieved location and NOT to the cache dir. This can't functioning with a "snapshot working model"!
          Hide
          Nicolas Lalevée added a comment -

          I did changed IvyDE quite a lot so the retrieve is better supported.
          Existing retrieve configurations are now considered as "standalone retrieves". Those retrieves can be configure on any project which has the Ivy nature. It will just do a retrieve, nothing more.
          Then I have added a new config in the advanced configuration of the IvyDE classpath container. Now we can choose if it will be build with Ivy's cache, or ask IvyDE to retrieve the artifacts expected to be added to the classpath.

          Show
          Nicolas Lalevée added a comment - I did changed IvyDE quite a lot so the retrieve is better supported. Existing retrieve configurations are now considered as "standalone retrieves". Those retrieves can be configure on any project which has the Ivy nature. It will just do a retrieve, nothing more. Then I have added a new config in the advanced configuration of the IvyDE classpath container. Now we can choose if it will be build with Ivy's cache, or ask IvyDE to retrieve the artifacts expected to be added to the classpath.

            People

            • Assignee:
              Nicolas Lalevée
              Reporter:
              angelo.schneider@oomentor.de
            • Votes:
              5 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development