Bugzilla – Full Text Bug Listing
| Summary: | [tests] UML Plugin tests disabled by Bug 358759 | ||
|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.1.0 | ||
| Target Milestone: | M7 | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
| Bug Depends on: | 375640 | ||
| Bug Blocks: | 360569, 363208 | ||
|
Description
Ed Willink
The klunky umlPluginURI = URI.createURI(UMLResource.METAMODELS_PATHMAP + "../../org.eclipse.uml2.uml/"); navigation in UMLTestReflection wants cleaning up too. Ed, Making the org.eclipse.uml2.uml plugin available in the build's workspace does effectively make the UML-Plugin tests work again. Changes pushed to master. However, this has produced an undesired side effect. See Bug 363208. Ok. It seems struggling to avoid the proper classpath-based initialization is causing needless trouble. In the short term the solution may be to add org.eclipse.ocl.common (plugin) comprising ProjectMap/StandaloneProjectMap (that might migrate to EMF) UMLUtils (that will probably migrate to UML2) This plugin will be used by the Ecore tests, UML2 tests to eliminate the filepath -D launch arguments, and by the the pivot UML support. The plugin is therefore not needed in the Core build; just the testing thereof; is that manageable? In the long term a common Ecore/UML/Pivot independent plugin may be useful for other purposes; e.g extension points and preferences. I'm not sure I understand... As I understood the problem, I thought that the main problem was that the o.e.uml2.uml the plugin didn't not include/expose an UML metamodel, so the plugins-based tests failed. However I don't understand why the stand-alone tests are working with the URI.createURI(UMLResource.METAMODELS_PATHMAP + "../../org.eclipse.uml2.uml/"): 1. I don't know how those UML PATHMAP works 2. "../../org.eclipse.uml2.uml/" ?¿?¿?¿?¿?. If the org.eclipse.uml2.uml is not in the workspace, where is it such a plugin and how the standalone tests work ? I'm completely lost with these UML2 tests. > > The plugin is therefore not needed in the Core build; just the testing thereof; > is that manageable? Try to avoid thinking about if a plugin makes sense in a build. Firstly (and probably only), we need to know in which feature a plugin suits better. We even have tests features for those plugins which only have testing purpose. > > In the long term a common Ecore/UML/Pivot independent plugin may be useful for > other purposes; e.g extension points and preferences. It sounds good to me. (In reply to comment #4) > I'm not sure I understand... > > As I understood the problem, I thought that the main problem was that the > o.e.uml2.uml the plugin didn't not include/expose an UML metamodel, so the > plugins-based tests failed. You're right: I was confusing two issues. a) o.e.uml2.uml/model/UML.merged.uml is difficult to access because it isn't in the plugin. Until Kenn packages UML.merged.uml, we must use the workspace project. Or rewrite the tests to use a different/cloned model. b) o.e.uml2.uml.resources/metamodel/... is difficult to access because there is no classpath. This is fixable by using a library path entry. > > However I don't understand why the stand-alone tests are working with the > URI.createURI(UMLResource.METAMODELS_PATHMAP + "../../org.eclipse.uml2.uml/"): > 1. I don't know how those UML PATHMAP works > 2. "../../org.eclipse.uml2.uml/" ?¿?¿?¿?¿?. If the org.eclipse.uml2.uml is not > in the workspace, where is it such a plugin and how the standalone tests work ? pathmap: is a completely arbitrary scheme. It works when there is a URI-mapping from pathmap: to the real locations; one of the many difficulties initilaizing UML. a) won't be a problem any more when the depending Bug 375640 is solved. Local copy of UML.merged.uml made and other resources resolved on classpath. CLOSED after a year in the RESOLVED state. |