Bugzilla – Full Text Bug Listing
| Summary: | MalformedURLException committing | ||
|---|---|---|---|
| Product: | [Modeling] EMFCompare | Reporter: | Ed Willink <ed> |
| Component: | Team | Assignee: | EMF Compare <emf.compare-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | b.muskalla, Ed.Merks, laurent.goubet, remy.suen |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
|
Description
Ed Willink
Pushing this over to EMF for further diagnosis. Ed, in case you have a CVS sandbox somewhere, you could check if CVS encounters similar problems. I've not encountered this type of problem using either GIT or CVS; but I don't have EMF Compare installed. I'm not sure what this code is up to: org.eclipse.emf.compare.logical.model.EMFModelProvider.getMappings(EMFModelProvider.java:92 but it should probably guard against failures... Ed, Benjamin, EMF Compare's "getMappings" is quite young, we may indeed be missing a guard or two. The purpose of that class is to detect the links between a set of models in order to determine, from one physical file, the whole set of physical files composing the underlying logical model : you cannot commit one file without commiting the others (lest you end up with a corrupt model). Here, we have found an Xtext file, tried to load it to determine the links between it and the other models ... and failed somehow (Xtext requires more setup than "Resource.load()" even when run from within Eclipse (and thus, with all initialization done)?). We need to guard against loading failures even for EMF Resources, and ignore these resources from the logical model it seems. That may lead to corrupt models if one file is commited without the others ... but it is better than a thrown exception. Laurent You might want to take another shot at Bug 340408 which I raised to get Xtext resources working correctly in Acceleo. Getting EMF Compare working is a much stronger use case. Ed, I must admit that I don't really know : the current issue is that EMF Compare tries to load a resource because it has the "EMF" content type ... but we don't know anything other than that. We thus cannot initialize the package : we expect it to be already registered in the running instance of Eclipse (since the content type is there, registered through a plugin.xml, we assume that the package has been registered through the same plugin.xml). If it isn't ... well I don't know if we should just ignore the resource (there could be parsing errors anyway) or try our best to register it. For now, I've added a catch clause to avoid brutal "errors" when resolving the logical model. We'll have to add kind of an extension mechanism and integration plugins in order to handle those EPackages with a non-standard initialization. (In reply to comment #0) > .. or an EMF compare bug, but why are they even active? Why is EMF Compare active during a commit? Is there a way to ensure that EMF Compare is only used when I want it? This bug has been fixed on the 1.* stream, and is not reproducible on 2.*. |