Bug 101425 - Classpath persistence should be resilient with unknown attributes
Summary: Classpath persistence should be resilient with unknown attributes
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1.1   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-23 07:24 EDT by Philipe Mulet CLA
Modified: 2005-09-26 11:59 EDT (History)
0 users

See Also:


Attachments
Patch against R3_1_maintenance branch (16.90 KB, patch)
2005-08-30 06:45 EDT, Jerome Lanneluc CLA
no flags Details | Diff
Regression test (5.29 KB, patch)
2005-08-30 06:45 EDT, Jerome Lanneluc CLA
no flags Details | Diff
Patch against R3_1_maintenance branch (23.62 KB, patch)
2005-08-31 09:39 EDT, Jerome Lanneluc CLA
no flags Details | Diff
Patch against R3_1_maintenance branch (27.94 KB, patch)
2005-09-05 06:42 EDT, Jerome Lanneluc CLA
no flags Details | Diff
Regression tests (7.14 KB, patch)
2005-09-05 06:43 EDT, Jerome Lanneluc CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philipe Mulet CLA 2005-06-23 07:24:36 EDT
3.1rc3

From release to release, the .classpath file is made richer, and
interoperability with previous client (i.e. 3.1 vs 3.0) is restrained due to
possible use of advanced features.

In 3.1, the problem worsen due to the conversion of javadoc locations from
metadata to classpath attributes. And we had to instruct 3.0 clients to refrain
from committing .classpath file changes to avoid disturbing 3.1 users.

This could be improved by having the .classpath file generation be resilient
with existing attributes, and rather merge its changes into the .classpath file
rather than rewriting it from scratch and thus erase potential useful information.

May need to backport this into maintenance updates of previous releases to ease
interoperability (3.1.1 and 3.0.?).
Comment 1 Jerome Lanneluc CLA 2005-08-30 06:45:08 EDT
Created attachment 26628 [details]
Patch against R3_1_maintenance branch
Comment 2 Jerome Lanneluc CLA 2005-08-30 06:45:33 EDT
Created attachment 26629 [details]
Regression test
Comment 3 Jerome Lanneluc CLA 2005-08-30 06:51:21 EDT
For this fix to work, bug 108346 must also be fixed.
Comment 4 Jerome Lanneluc CLA 2005-08-31 09:39:38 EDT
Created attachment 26698 [details]
Patch against R3_1_maintenance branch

Better patch that reads the unknown attributes and elements just before writing
the .classpath file. With this patch, there is no need for the UI to reuse the
IClasspathEntries comming from getRawClasspath() any longer.
Comment 5 Jerome Lanneluc CLA 2005-08-31 09:44:07 EDT
Removing dependency on bug 108346 as the new patch reads the unknown attributes
of  the .classpath file just, and preserve them before writing the new entries.
Comment 6 Jerome Lanneluc CLA 2005-09-05 06:42:27 EDT
Created attachment 26828 [details]
Patch against R3_1_maintenance branch

Improved fix that encode the unknown elements using a XmlWriter (instead of
using the toString() of the node).
Comment 7 Jerome Lanneluc CLA 2005-09-05 06:43:24 EDT
Created attachment 26829 [details]
Regression tests

Added 2 regression tests
Comment 8 Philipe Mulet CLA 2005-09-05 06:50:54 EDT
+1 for 3.1.1 (so it can be forward compatible with 3.2 installs).
Comment 9 Jerome Lanneluc CLA 2005-09-05 07:40:22 EDT
Released fix and regression tests in both HEAD and R3_1_maintenance branch.
Comment 10 David Audel CLA 2005-09-21 08:04:45 EDT
Verified in I20050920-0010 for 3.2M2
Comment 11 Olivier Thomann CLA 2005-09-26 10:23:32 EDT
Why do we get this in the .log?

org.eclipse.jdt.internal.core.Assert$AssertionFailedException: Unknown kind: ''
at
org.eclipse.jdt.internal.core.ClasspathEntry.elementDecode(ClasspathEntry.java:746)
at org.eclipse.jdt.internal.core.JavaProject.decodeClasspath(JavaProject.java:835)
at
org.eclipse.jdt.internal.core.JavaProject.readClasspathFile(JavaProject.java:2562)
at
org.eclipse.jdt.internal.core.JavaProject.readClasspathFile(JavaProject.java:2547)
at org.eclipse.jdt.internal.core.JavaProject.getRawClasspath(JavaProject.java:1852)
at
org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1955)
at
org.eclipse.jdt.internal.core.DeltaProcessor.createExternalArchiveDelta(DeltaProcessor.java:711)
at
org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged(DeltaProcessor.java:1791)
at
org.eclipse.jdt.internal.core.DeltaProcessingState.resourceChanged(DeltaProcessingState.java:432)
at
org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:276)
at
org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044)
at org.eclipse.core.runtime.Platform.run(Platform.java:783)
at
org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:270)
at
org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:144)
at
org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:180)
at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:914)
at
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:45)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76)

An error in the problem view is good enough. I don't see a need to log the error.
Comment 12 Jerome Lanneluc CLA 2005-09-26 10:27:19 EDT
kind is a known attribute: it has known values and ' ' is not one of them
Comment 13 Olivier Thomann CLA 2005-09-26 11:59:13 EDT
Verified for 3.1.1 using M20050923-1430.