Community
Participate
Working Groups
Eclipse 3.2 Whenever I run "Update Classpath..." on my Plugin, all defined access-rules get removed. Ben
can we see a 'before' and 'after' snapshots of the .classpath file please?
Sure! Before: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry sourcepath="src.zip" kind="lib" path="h2.jar"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/> <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"> <accessrules> <accessrule kind="accessible" pattern="**"/> </accessrules> </classpathentry> <classpathentry kind="output" path="bin"/> </classpath> After: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry sourcepath="src.zip" kind="lib" path="h2.jar"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/> <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> <classpathentry kind="output" path="bin"/> </classpath>
yes, we should respect the attributes added by the user.
Chris, can you take a look at this one when you look at 155315.
The same problem just happened to us with Eclipse 3.3M5 -- it's a nasty one and broke our N-build. I'd love to see that fixed in 3.3.
Darin, this might be interesting for someone to do, not so complicated and gives good exposure to PDE/JDT related things.
Created attachment 79412 [details] Work in progress Changes the classpath computer to check the project for an existing JRE classpath entry. If one is found, the access rules, extra attributes and exported boolean from the existing entry are applied to the new one.
The current patch solves the original problem. But before this patch should be put in, we must decide when user defined rules should be copied into the new entry. Possible solutions are: 1) Never copy user rules (current behaviour). This is annoying and the reason why this bug was filed in the first place. 2) Only copy rules if the new classpath entry has the same path as the old classpath entry. This would work for the specific case in comment 2, but would throw out the rules if the entry changes in any way (ex. rules defined on a JRE would be tossed as the new entry will use an EE). 3) Always copy the rules (behaviour in the patch). Helpful because it always saves your rules. However, does it really make sense to apply the rules set on a Sun 1.4.2 JRE to a 1.5 EE entry? 4) ...? Come up with some way of knowing if the rules should be added to the new entry. Option (2) is the safest way to solve the original problem. (3) Seems like a better solution, but only if it is not going to cause problems. Would anyone like to comment?
Not going to make it for M3, but even if the perfect solution can't be found, something that solves the given case should be put in for M4.
Brian, M4 or should we bump to M5?
I should have pushed to get this looked at earlier in M4. However, this bug is not a major issue and so we'll have to put it off for M5.
Ok, I have to admit this is one that fell through the cracks. Of the current options, I am leaning most towards #2. The problem with #3 is that if you change the EE and update the classpath, you will having multiple EE's contributing rules which will cause problems. The best way to do it would be as follows: 1. Get all the current rules 2. Get the old EE 3. See if we can find all the rules for the old EE 4. Take the current rules and remove any of the rules found in step 3. This algorithm would give us the set of user-defined rules (though I admit it is far from fool proof). I am not sure if this is possible, but if it is this would provide the best user experience. What do you think Curtis, is that possible?
Created attachment 87709 [details] Patch This patch uses method #2, only updating the classpath if the JRE container path has not changed. The patch is also updated so it does not conflict with the source template changes.
(In reply to comment #12) > Of the current options, I am leaning most towards #2. The problem with #3 is > that if you change the EE and update the classpath, you will having multiple > EE's contributing rules which will cause problems. > > The best way to do it would be as follows: > 1. Get all the current rules > 2. Get the old EE > 3. See if we can find all the rules for the old EE > 4. Take the current rules and remove any of the rules found in step 3. I posted an updated patch using method #2, which is a safe way to solve the original problem. While I do not fully understand what you are proposing, I don't think it will work in a way that is any better than method #3. I am not sure what you mean by find all the rules for the old EE. If you recreate the classpath entry from the EE string or the old classpath entry there will be no access rules (JavaRuntime does not add rules unless you explcitly add them). I recommend we put in my patch as it solves the original problem. If someone changes their JRE/EE setting, adds rules, and then runs update classpath, their rules will be gone, but their EE will have changed as well. If this case turns out to be a problem for users, we can deal with it then.
Thanks Curtis for picking this back up after it falling through the cracks. After doing some work, we decided to go with Curti's initial patch "Work in progress" because it has the optimal behavior. The patch will copy over only user-defined access rules when the user updates the EE. Nice job Curtis!
FYI, I just fell into this bug again with Eclipse SDK I20080129-1400 Is it expected that the fix is not yet integrated with that build? The relevant PDE plugins have all been tagged on 29-Jan-2008 so I'm tentatively reopening. The issue was with the plugin from SVN Repository: http://dev.eclipse.org/svnroot/dsdp/ SVN Module: org.eclipse.tm.tcf/trunk/plugins/com.windriver.debug.tcf.ui/ My old .classpath: ------------------ <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"> <accessrules> <accessrule kind="accessible" pattern="org/eclipse/debug/**/provisional/**"/> </accessrules> </classpathentry> <classpathentry kind="output" path="bin"/> </classpath> My MANIFEST.MF: ------------------- Bundle-RequiredExecutionEnvironment: J2SE-1.5 The mismatch in JRE setting (1.5 vs. Worksapace deault 1.6) is highlighted as a warning in MANIFEST.MF. On Plugin Manifest Editor, Overview Tab, I chose "update classpath settings". My new .classpath had the accessrules deleted, and the original LF-Only .classpath file had been converted into CRLF (on a Windows machine): My new .classpath: ------------------ <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/> <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> <classpathentry kind="output" path="bin"/> </classpath>
investigating... looks like we only copy access rules over for JRE entries
ok, refactored the code a bit and now we're all good. Thanks for catching this Martin.
Created attachment 88893 [details] org.eclipse.pde.patch
Created attachment 88894 [details] mylyn/context/zip
done!
