Community
Participate
Working Groups
Build Identifier: Version: Helios Release Build id: 20100617-1415 If an external library (jar) changes on disk, refreshing the project that refers to it does not refresh the library (it still uses the old version) This functionality was working in previous versions (eg Galileo). Work around: Close the project and reopen it. Note that this work around closes all files you have open for the project, so this can be quite disruptive. Reproducible: Always Steps to Reproduce: 1. You have two eclipse projects. Project B uses jar created from project A. 2. Maven used to build and control dependancies with "mvn eclipse:eclipse" (so project has ends up with M2_REPO/.../projectA.jar in its classpath) 3. Build project A using maven --> maven installs jar into local repo. 4. Right click on project in project explorer --> changes to classes in project A NOT visible, but they SHOULD be visible Note: In previous eclipse versions, changes to classes in project A became immediately visible after refresh
Just to be clear about reproducing - step 4: 4. Right click on project B in project explorer --> changes to classes in project A NOT visible, but they SHOULD be visible
Moving to JDT core.
(In reply to comment #1) > Just to be clear about reproducing - step 4: > 4. Right click on project B in project explorer --> changes to classes in > project > A NOT visible, but they SHOULD be visible Would it be possible to attach the concerned projects here? I am mainly interested in the project configuration files such as .project, pom.xml etc - just the ones required to reproduce the problem. Thanks.
Actually, this could be same as bug 320618, which has been fixed and available in the latest I build. Glen, would it be possible for you to verify with the latest build once?
> Glen, would it be possible for you to verify with the latest build once? I am already using the latest version of Eclipse J2EE for Mac OS 64 bit (Snow Leopard), as downloaded from http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/helios/R/eclipse-jee-helios-macosx-cocoa-x86_64.tar.gz I just downloaded it again to make sure and it is still Build id: 20100617-1415 I checked a couple of mirrors and they all have this version too. I would be happy to test a more recent version if someone can advise me of the URL.
(In reply to comment #5) > > Glen, would it be possible for you to verify with the latest build once? > > I am already using the latest version of Eclipse J2EE for Mac OS 64 bit (Snow > Leopard), as downloaded from > http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/helios/R/eclipse-jee-helios-macosx-cocoa-x86_64.tar.gz > > I just downloaded it again to make sure and it is still Build id: 20100617-1415 > I checked a couple of mirrors and they all have this version too. > > I would be happy to test a more recent version if someone can advise me of the > URL. You can try this one: http://download.eclipse.org/eclipse/downloads/drops/I20100915-2024/index.php This is only the SDK and not a J2EE version. But you should be able to verify whether or not the bug has been addressed. If it doesn't work, you can simply replace the JDT plug-in with the latest or I can provide you a plug-in patch.
> You can try this one: > http://download.eclipse.org/eclipse/downloads/drops/I20100915-2024/index.php That version has the same problem. To confirm, your URL installed as Indigo Version: 3.7.0 Build id: I20100915-2024.
(In reply to comment #7) > > You can try this one: > > http://download.eclipse.org/eclipse/downloads/drops/I20100915-2024/index.php > > That version has the same problem. > > To confirm, your URL installed as Indigo Version: 3.7.0 Build id: > I20100915-2024. That confirms that this is a different bug. Would you be able to share the affected projects by any chance?
Created attachment 179089 [details] Zip of Project A
Created attachment 179090 [details] Zip of Project B
> That confirms that this is a different bug. Would you be able to share the > affected projects by any chance? I have created a minimal (truly tiny) case to reproduce the problem. Attached are zips of two project directories. ProjectB uses a class defined in ProjectA To reproduce using these zips: 0. If you do not have maven installed, install it and create a directory in your home dir called ".m2" and in that a directory called "repository" - ie $HOME_DIR/.m2/repository 1. Unzip the two files 2. On the command line in each project dir run: mvn eclipse:clean eclipse:eclipse mvn clean install 3. Open Eclipse 4. If not already defined, define a classpath variable M2_REPO for your maven respository (see step 0) 5. Import > Existing Projects into Workspace > Select both projects - uncheck "Copy into workspace" 6. Open ReferencingClass.java and run the main. Note the value of ReferencedClass.TEST = "a" 7. Open ReferencedClass.java and change the value of TEST to "b" 8. On the command line in ProjectA directory, run "mvn clean install" 9. In Eclipse, right click project-b and select Refresh 10. Run ReferencingClass main - the value of TEST is still "a". Expected result is that TEST = "b" Workaround: 1. Close project-b 2. Open project-b 3. Run ReferencingClass main - the value of TEST is now "b"
(In reply to comment #10) > Created an attachment (id=179090) [details] > Zip of Project B Something is wrong. The zip files are empty!
Created attachment 179238 [details] Zip of Project A - V2 Replaces previous erroneous version
Created attachment 179239 [details] Zip of Project B - V2 Replaces previous erroneous version
> Something is wrong. The zip files are empty! Oops. Mu bad. Try now.
(In reply to comment #15) > > Something is wrong. The zip files are empty! > > Oops. Mu bad. Try now. Thanks for the detailed steps. I have tried with build I20100608-0911 and HEAD and unable to reproduce the bug. I mean, the change is picked up correctly. Satyam, could you please give it a shot?
Thanks Satyam, for helping out. Glen, we see the behavior you described if we do the "refresh" from the navigator or Project Explorer view. To confirm this, could you just try refreshing the project from Package Explorer and see if it works as expected. Thanks.
> Glen, we see the behavior you described if we do the "refresh" from the > navigator or Project Explorer view. To confirm this, could you just try > refreshing the project from Package Explorer and see if it works as expected. If I refresh from Package Explorer, there is no bug. It works as expected. If I refresh from Project Explorer, the bug is there. Please note my steps to reproduce need a slight change to show the problem more clearly, as follows: Step 7 should be: Edit ReferencedClass in project-a and add a new constant public static String FOO = "foo"; Step 10 should be: In ReferencingClass, ReferencedClass.FOO is not visible, eg when using Context Assist (Ctrl + Space) Other steps remain the same.
This appears to be same as bug #305172. Will continue the discussion about the fix on bug #305172.
Marking as duplicate of bug 305172. *** This bug has been marked as a duplicate of bug 305172 ***
Verified.
