[IVYDE-332] launch file IVYDE_CONTAINER becomes invalid/stale when settings change

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 2.2.0.final
• Component/s: launch configuration
• Assignee: Unassigned
• Reporter: Stephen Haberman
• Created: 18/Dec/12 21:45
• Updated: 18/Dec/12 21:45

Description

Our apps (when ran from .launch files) started getting a bunch of ClassNotFoundExceptions today.

Stepping into IvyDE, I figured out what went wrong...

1. Our .classpath has a IVYDE_CONTAINER/?project=...&foo

2. Our .launch files have cp entries of IVYDE_CONTAINER/?project=...&foo (so far, so good, everything works great)

3. When we changed some IvyDE settings in our .classpath file, the entry in the .classpath file changed to IVYDE_CONTAINER/?project=...&bar (still the same project, but the setting suffixes were different).

4. When we Hit resolve, IvyClasspathContainer:166 updates the CP entry (JavaCore.setClasspathContainer(path, ...)) with the new path (?project=...&bar).

5. When we ran our .launch files, IvyDERuntimeClasspathEntryResolver used the old path still in the .launch file to look up the container, which unfortunately actually worked, because Eclipse had the serialized state of he old path/container saved, so the stale container got used to run our program.

6. The stale IvyClasspathContainer had some jars in it that, in the new IvyClasspathContainer were imported via the workspace resolve (so the underlying jars were deleted from the local retrieve directory) so led to the CNFEs in our code.

So...the problem seems like path should not be used for the identifying key of the IVYDE_CONTAINER, since it is likely to easily change, leading to .launch files getting their containers references becoming invalid and so the contents stale.

Perhaps a subset of the path could be used (like only project name + confs?) when putting IVYDE_CONTAINER references in the .launch file.

Or maybe some unique index (or ID) could be added to the path (only when in the .launch file, like /?project=...&index=0), and the runtime look up could ignore the JavaCore method that may return an old/stale container, and manually search for the possibly-updated container with the right index?

For now I'll update our launch files with the new path, but any ideas for a more future proof solution would be appreciated.

Thanks!