Community
Participate
Working Groups
Pending a fix for Bug 358759 to make the UML model of the UML model metamodel available the JUnit UML plugin tests are disabled on Hudson. They work fine interactively.
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.
