| Summary: | Restore the dummy classpath for org.eclipse.uml2.uml.resources | ||
|---|---|---|---|
| Product: | [Modeling] MDT.UML2 | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | UML2 Inbox <mdt-uml2-inbox> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | Flags: | Kenn.Hussey:
juno+
|
| Version: | 4.0.0 | ||
| Target Milestone: | 4.0.0 | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
|
Description
Ed Willink
Hmm, I don't know where/how the classpath would have been provided, as there isn't a .classpath file in the project (and wasn't in 3.x either) and the build.properties file hasn't changed... I'm puzzled too. I guess it's a side effect of Import Plugin with Source Folders. Changing to enhancement. I'm just trying to get my MWE scripts working with UML2 4.0.0 and OCL2Java. I've solved missing L2/L3 profiles. Now struggling with a SAXParseException on HTML.Version! Will comment further once working. In Bug 361063, I've contributed a solution to the problem of URImap initializations that exploits MWE's classpath scanning approach. It would therefore be helpful if UML resources are findable on the classapth. (In reply to comment #3) > It would therefore be helpful if UML resources are findable on the classapth. This is not 100% necessary; a .classpath line such as <classpathentry kind="lib" path="/org.eclipse.uml2.uml.resources"/> enables run-time access via the classpath, but it appears that this line cannot be defined using the plugin/manifest editor, so it gets lost every time a manifest regenerates its classpath. So users can gain access, but setting a Build Path property for a plugin is unusual and fragile. The introduction of UMLResourceUtil.init() means that org.eclipse.uml2.uml.resources has classes and can be on a classpath. So ... FIXED Fixed indirectly by bug 364419. |