IvyDE
  1. IvyDE
  2. IVYDE-299

IvyDE is making .classpath file writable and rewriting it

    Details

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

      Description

      The latest beta (2.2.0b1) is continually rewriting the project's .classpath file. This is problematic for two reasons: 1) Our project is submitted to source control, so the rewriting causes a pending change for the .classpath file and 2) We are manually editing the .classpath file to add useful comments, which are being lost when the file is written again. Reverting to 2.1.0 and the issue goes away.

      1. classpath.txt
        2 kB
        Eric Milles

        Activity

        Hide
        Nicolas Lalevée added a comment -

        Can you share your .classpath ?

        Show
        Nicolas Lalevée added a comment - Can you share your .classpath ?
        Hide
        Eric Milles added a comment -

        As requested. Sanitized a bit. Obviously, this is named ".classpath" normally and is at the root of the Eclipse project.

        Show
        Eric Milles added a comment - As requested. Sanitized a bit. Obviously, this is named ".classpath" normally and is at the root of the Eclipse project.
        Hide
        Nicolas Lalevée added a comment -

        I dont think we'll fix it. The .classpath is first meant to be manipulated by Eclipse and its plugins, not people.

        Your current .classpath has an entry about IvyDE. IvyDE 2.2 detects that it has missing information, because it was generated by an IvyDE 2.1. So it updates it.

        Maybe something that would work for you is to let first IvyDE change the .classpath. Then replace it with your own version but keeping the one line about IvyDE container. So IvyDE won't try to update it.

        Show
        Nicolas Lalevée added a comment - I dont think we'll fix it. The .classpath is first meant to be manipulated by Eclipse and its plugins, not people. Your current .classpath has an entry about IvyDE. IvyDE 2.2 detects that it has missing information, because it was generated by an IvyDE 2.1. So it updates it. Maybe something that would work for you is to let first IvyDE change the .classpath. Then replace it with your own version but keeping the one line about IvyDE container. So IvyDE won't try to update it.
        Hide
        Peter Vestman added a comment -

        We are also suffering from this issue. The problem we are having is that we do not want the name of the project directory in the .classpath because we have multiple versions of the same project checkedout under different names.
        IvyDE adds the directory name in .classpath as project=MyProjectRelease4.0 and also for the ivysetting path. for the ivysettings path we used to be able to write project:///ivysettings.xml but this is now rewritten to workspace_loc:/projectname. IvyDE used to be able to know in with project it was operating without the project parameter. No other eclipse plugins insist on modifying the .classpath to be dependent on the directory name.
        This is related to IVYDE-254

        Show
        Peter Vestman added a comment - We are also suffering from this issue. The problem we are having is that we do not want the name of the project directory in the .classpath because we have multiple versions of the same project checkedout under different names. IvyDE adds the directory name in .classpath as project=MyProjectRelease4.0 and also for the ivysetting path. for the ivysettings path we used to be able to write project:///ivysettings.xml but this is now rewritten to workspace_loc:/projectname. IvyDE used to be able to know in with project it was operating without the project parameter. No other eclipse plugins insist on modifying the .classpath to be dependent on the directory name. This is related to IVYDE-254
        Hide
        Eric Milles added a comment -

        If I find that Ivy is making a change to the IvyDE line, make that change and find that IvyDE is still rewriting the file continuously, would you consider a fix? I do understand that the .classpath file is an Eclipse-managed entity. But, up to this point, we were able to make our own annotations to the .classpath file that would stick as long as we weren't making any changes to the build path of the project.

        Regardless of that, it is still important that we not have a pending change on .classpath for every developer. This is very dangerous and often leads to unintended changes to the Java build path ending up committed to source control.

        Show
        Eric Milles added a comment - If I find that Ivy is making a change to the IvyDE line, make that change and find that IvyDE is still rewriting the file continuously, would you consider a fix? I do understand that the .classpath file is an Eclipse-managed entity. But, up to this point, we were able to make our own annotations to the .classpath file that would stick as long as we weren't making any changes to the build path of the project. Regardless of that, it is still important that we not have a pending change on .classpath for every developer. This is very dangerous and often leads to unintended changes to the Java build path ending up committed to source control.
        Hide
        Eric Milles added a comment -

        It appears that Ivy rewrote the URL parameters of the IvyDE classpath container from:

        ivyXmlPath=ivy.xml&confs=local,master&ivySettingsPath=%24%7Bworkspace_loc%3AProjectName%2Fivysettings.xml%7D&loadSettingsOnDemand=false&propertyFiles=

        to:

        project=ProjectName&ivyXmlPath=ivy.xml&confs=local%2Cmaster&ivySettingsPath=%24%7Bworkspace_loc%3AProjectName%2Fivysettings.xml%7D&loadSettingsOnDemand=false&propertyFiles=

        After this, it does not seem to be making any changes. I am even able to alter the workspace_loc path to the settings file to a project_loc style "ivySettingsPath=%24%7Bproject_loc%7D%2Fivysettings.xml" (which was not working in IvyDE 2.1).

        My question now is this: Are these new URL parameters compatible with IvyDE 2.1? That is, could I safely make these changes and commit the to source control and have some developers with IvyDE 2.1 and some testing IvyDE 2.2b1 with the same .classpath?

        Show
        Eric Milles added a comment - It appears that Ivy rewrote the URL parameters of the IvyDE classpath container from: ivyXmlPath=ivy.xml&confs=local,master&ivySettingsPath=%24%7Bworkspace_loc%3AProjectName%2Fivysettings.xml%7D&loadSettingsOnDemand=false&propertyFiles= to: project=ProjectName&ivyXmlPath=ivy.xml&confs=local%2Cmaster&ivySettingsPath=%24%7Bworkspace_loc%3AProjectName%2Fivysettings.xml%7D&loadSettingsOnDemand=false&propertyFiles= After this, it does not seem to be making any changes. I am even able to alter the workspace_loc path to the settings file to a project_loc style "ivySettingsPath=%24%7Bproject_loc%7D%2Fivysettings.xml" (which was not working in IvyDE 2.1). My question now is this: Are these new URL parameters compatible with IvyDE 2.1? That is, could I safely make these changes and commit the to source control and have some developers with IvyDE 2.1 and some testing IvyDE 2.2b1 with the same .classpath?
        Hide
        Eric Milles added a comment -

        Regarding Peter's comment, if IvyDE is requiring the project name coming in as a URL param – which seems like it would be accessible through alternate means – would it be possible to use an Eclipse variable for its value in the URL? That is, would "project=%7Bproject_name%7D" be viable? These Eclipse variables can/should work for the ivy.xml and ivysettings.xml locations.

        Show
        Eric Milles added a comment - Regarding Peter's comment, if IvyDE is requiring the project name coming in as a URL param – which seems like it would be accessible through alternate means – would it be possible to use an Eclipse variable for its value in the URL? That is, would "project=%7Bproject_name%7D" be viable? These Eclipse variables can/should work for the ivy.xml and ivysettings.xml locations.
        Hide
        Nicolas Lalevée added a comment -

        @Peter: actually there is an undocumented variable, ivyproject_loc which should do the job properly. Try setting $

        {ivyproject_loc}/ivysettings.xml

        @Eric: the upward compatibility is not garanteed, and I think actually changing form 2.2 to 2.1 won't work properly.

        Then I think you're looking for the variable ivyproject_loc I just wrote about. Eclipse doesn't have such variable, IvyDE has a sort of hack for that, it does live in replace of the string "${ivyproject_loc}

        ". This is because the variable manager of Eclipse doesn't work relatively to a project, it is global, unlike a classpath container like IvyDE's one.

        And about the project name in the url, IIRC it was introduced to make IvyDE work properly in launch configurations. It is possible to setup standalone IvyDE classpath container in a launch configuration, and a launch configuration is is not particularly related to a project (at least that's what the Eclipse API infer). Maybe this can be improved, but I had quite some pain to make IvyDE work correctly in a launch configuration, so I won't rush into modifying it. (and needless to say, patches are always welcomed ).

        Show
        Nicolas Lalevée added a comment - @Peter: actually there is an undocumented variable, ivyproject_loc which should do the job properly. Try setting $ {ivyproject_loc}/ivysettings.xml @Eric: the upward compatibility is not garanteed, and I think actually changing form 2.2 to 2.1 won't work properly. Then I think you're looking for the variable ivyproject_loc I just wrote about. Eclipse doesn't have such variable, IvyDE has a sort of hack for that, it does live in replace of the string "${ivyproject_loc} ". This is because the variable manager of Eclipse doesn't work relatively to a project, it is global, unlike a classpath container like IvyDE's one. And about the project name in the url, IIRC it was introduced to make IvyDE work properly in launch configurations. It is possible to setup standalone IvyDE classpath container in a launch configuration, and a launch configuration is is not particularly related to a project (at least that's what the Eclipse API infer). Maybe this can be improved, but I had quite some pain to make IvyDE work correctly in a launch configuration, so I won't rush into modifying it. (and needless to say, patches are always welcomed ).
        Hide
        Eric Milles added a comment -

        That makes sense. My assumption was that everything was being done relative to a project. But for launch configurations that is not the case. So to have the classpath container work generically for projects and launches, IvyDE needs a way to be directed to the necessary files without assuming any particular project. So currently, the project is stated explicitly using the "project" URL parameter.

        Additionally, you are saying there is a variable $

        {ivyproject_loc}

        that could be leveraged. But I'm not sure I understand exactly what directory to which it is referring. In the case of launch configurations, would this variable be useful?

        Show
        Eric Milles added a comment - That makes sense. My assumption was that everything was being done relative to a project. But for launch configurations that is not the case. So to have the classpath container work generically for projects and launches, IvyDE needs a way to be directed to the necessary files without assuming any particular project. So currently, the project is stated explicitly using the "project" URL parameter. Additionally, you are saying there is a variable $ {ivyproject_loc} that could be leveraged. But I'm not sure I understand exactly what directory to which it is referring. In the case of launch configurations, would this variable be useful?
        Hide
        Sebastian Krause added a comment -

        @Nicolas: Unfortunately even with the $

        {ivyproject_loc}

        variable it seems impossible to leave the .classpath file in a VCS if you have the project checked out under different names. Let's say you have "myproject" checked out under the project name "myproject-dev" and a second project "myproject-stable" at a different revision. The classpath entry will look something like this:

        <classpathentry kind="con" path="org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/?project=myproject-stable&ivyXmlPath=ivy.xml&confs=*&ivySettingsPath=%24%7Bivyproject_loc%7D%2Fivysettings.xml&loadSettingsOnDemand=false&propertyFiles="/>

        Now in the other project IvyDE will always change the "project" parameter into "myproject-dev" and my VCS system will try to check it in. The only current solution so far it to simply let the VCS completely ignore the classpath file.

        Show
        Sebastian Krause added a comment - @Nicolas: Unfortunately even with the $ {ivyproject_loc} variable it seems impossible to leave the .classpath file in a VCS if you have the project checked out under different names. Let's say you have "myproject" checked out under the project name "myproject-dev" and a second project "myproject-stable" at a different revision. The classpath entry will look something like this: <classpathentry kind="con" path="org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/?project=myproject-stable&ivyXmlPath=ivy.xml&confs=*&ivySettingsPath=%24%7Bivyproject_loc%7D%2Fivysettings.xml&loadSettingsOnDemand=false&propertyFiles="/> Now in the other project IvyDE will always change the "project" parameter into "myproject-dev" and my VCS system will try to check it in. The only current solution so far it to simply let the VCS completely ignore the classpath file.
        Hide
        Martin Schaffoener added a comment -

        So this issue won't be fixed... However, this is a major blocker for my company upgrading from IvyDE2.1.0. We have had the .classpath files under VCS control for years to share the correct settings with all developers in the company. Even if only Eclipse is supposed to modify this file, I do not think this mandates the .classpath file not being version controlled.

        Even if we could make changes now to make the .classpath file work with IvyDE2.1.0 in a way that an upgrade to 2.2.x would not rewrite it (which, it appears, is not supported), we would still see the .classpath files altered automatically when switching back to a historic changeset id. And this would leave uncommitted changes in the workspace even though we're looking at an old version - something which looks weird and is very hard to explain to a user.

        Apparently IvyDE 2.2.x can read .classpath files with entries created by IvyDE 2.1.0. Why can't we just read the old settings, convert them into new internal representations, but skip rewriting the .classpath file until one actually makes a change to the IvyDE classpath containers?

        Finally: What can or must I do to have this bug reopened and fixed?

        Show
        Martin Schaffoener added a comment - So this issue won't be fixed... However, this is a major blocker for my company upgrading from IvyDE2.1.0. We have had the .classpath files under VCS control for years to share the correct settings with all developers in the company. Even if only Eclipse is supposed to modify this file, I do not think this mandates the .classpath file not being version controlled. Even if we could make changes now to make the .classpath file work with IvyDE2.1.0 in a way that an upgrade to 2.2.x would not rewrite it (which, it appears, is not supported), we would still see the .classpath files altered automatically when switching back to a historic changeset id. And this would leave uncommitted changes in the workspace even though we're looking at an old version - something which looks weird and is very hard to explain to a user. Apparently IvyDE 2.2.x can read .classpath files with entries created by IvyDE 2.1.0. Why can't we just read the old settings, convert them into new internal representations, but skip rewriting the .classpath file until one actually makes a change to the IvyDE classpath containers? Finally: What can or must I do to have this bug reopened and fixed?
        Hide
        Nicolas Lalevée added a comment -

        I am sorry this is making some mess in your project Martin, but I feel quite uncomfortable not forcing the .classpath to be upgraded.
        Now I remember why the project name was added to the IvyDE classpath entry. For some reason, in the launch configuration, if a project is added manually to the source lookup and it contains an IvyDE classpath container, the project reference is lost by the JDT. So I had to add it to the IvyDE container. So now if the .classpath is not upgraded, we may introduce a bug I had a hard time to fix.
        We could think of an option saying "do not upgrade .classpath, I know what I am doing". But to be able to check this option, you will have to upgrade first...
        I cannot find a good solution to your issue.

        Show
        Nicolas Lalevée added a comment - I am sorry this is making some mess in your project Martin, but I feel quite uncomfortable not forcing the .classpath to be upgraded. Now I remember why the project name was added to the IvyDE classpath entry. For some reason, in the launch configuration, if a project is added manually to the source lookup and it contains an IvyDE classpath container, the project reference is lost by the JDT. So I had to add it to the IvyDE container. So now if the .classpath is not upgraded, we may introduce a bug I had a hard time to fix. We could think of an option saying "do not upgrade .classpath, I know what I am doing". But to be able to check this option, you will have to upgrade first... I cannot find a good solution to your issue.
        Hide
        Martin Schaffoener added a comment -

        Couldn't we make this a global configuration option to not update the .classpath files, so that we can start Eclipse, set the option, revert .classpath files? Or have it configurable via a JVM system property? Or put it into the .project file before upgrading? (BTW: I think I noticed the .project also getting touched by the upgrade?)

        Show
        Martin Schaffoener added a comment - Couldn't we make this a global configuration option to not update the .classpath files, so that we can start Eclipse, set the option, revert .classpath files? Or have it configurable via a JVM system property? Or put it into the .project file before upgrading? (BTW: I think I noticed the .project also getting touched by the upgrade?)
        Hide
        Nicolas Lalevée added a comment -

        upgrade, check option, revert & restart should work, yes. I have no time to work on it so a patch is welcomed.

        The .project get upgraded too, an Ivy "nature" is added.

        Show
        Nicolas Lalevée added a comment - upgrade, check option, revert & restart should work, yes. I have no time to work on it so a patch is welcomed. The .project get upgraded too, an Ivy "nature" is added.
        Hide
        Martin Schaffoener added a comment -

        So, if we decide to try to fix this ourselves (or make it configurable so we can have it "our way") - where would we need to start? Can you give us some pointers/code locations where we would need to change things or attach a debugger to find out what's going on?

        Show
        Martin Schaffoener added a comment - So, if we decide to try to fix this ourselves (or make it configurable so we can have it "our way") - where would we need to start? Can you give us some pointers/code locations where we would need to change things or attach a debugger to find out what's going on?
        Hide
        Nicolas Lalevée added a comment -

        The code which is upgrading the .classpath is in:
        org.apache.ivyde.eclipse.cpcontainer.IvyClasspathInitializer.updateIvyDEContainerPath()

        Then to add an option, just do like the "resolve on startup" option (See everywhere is used the constant
        org.apache.ivyde.eclipse.ui.preferences.PreferenceConstants.RESOLVE_ON_STARTUP)

        Also, recently I have added a page about how to develop IvyDE. See: http://ant.apache.org/ivy/ivyde/history/trunk/dev/dev-env-setup.html

        Show
        Nicolas Lalevée added a comment - The code which is upgrading the .classpath is in: org.apache.ivyde.eclipse.cpcontainer.IvyClasspathInitializer.updateIvyDEContainerPath() Then to add an option, just do like the "resolve on startup" option (See everywhere is used the constant org.apache.ivyde.eclipse.ui.preferences.PreferenceConstants.RESOLVE_ON_STARTUP) Also, recently I have added a page about how to develop IvyDE. See: http://ant.apache.org/ivy/ivyde/history/trunk/dev/dev-env-setup.html
        Hide
        Nicolas Lalevée added a comment -

        Ironically, this .classpath upgrade was producing some mess in the classpath container initialization. In some use case the classpath container didn't even get initialized and we could see the container path in place of the name of the container (ivy.xml[*]). I didn't saw it until recently, maybe related to my recent move to Eclipse 4.
        So I removed that .classpath upgrade.

        Show
        Nicolas Lalevée added a comment - Ironically, this .classpath upgrade was producing some mess in the classpath container initialization. In some use case the classpath container didn't even get initialized and we could see the container path in place of the name of the container (ivy.xml [*] ). I didn't saw it until recently, maybe related to my recent move to Eclipse 4. So I removed that .classpath upgrade.

          People

          • Assignee:
            Nicolas Lalevée
            Reporter:
            Eric Milles
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development