Bugzilla – Full Text Bug Listing
|
Description
Kenn Hussey
Created attachment 102055 [details]
updated source models
Here are the updated source models based on UML 2.2. In addition to using these models to regenerate the source code (preserving APIs where possible), the following needs to be done
- update/check implementation of Component::provided and Component::required
- remove temporary models for issues 10536 and 10537
- remove guards that assume upper bounds are > 0
Created attachment 107831 [details]
A rough draft of the types of changes expected
Kenn, if you get a chance, please review the document listing the types of changes expected and add/modify if there are things missing/incorrect. Thanks. (In reply to comment #3) > Kenn, if you get a chance, please review the document listing the types of > changes expected and add/modify if there are things missing/incorrect. > > Thanks. > James, what did you use as the basis for creating this list? The updated source models attached to this bug? If so, I'm reasonably confident the list should be correct. I'll try to find some time to look at the document either way... I had looked at the UML 2.2 spec with change bars and looked at your metamodel changes. I factored out editorial type changes and just listed the "major" work items. The list could possibly be the basis for a migration article. The list is subject to change as the migration work gets started for real. There is no rush for you to look at the list right away, just if you have some time...I know you are busy with other stuff :). Thanks. Something happened to SendObjectAction::request. It looks like the type was removed along with some other information. Do you remember what happened there Kenn? I don't believe anything should have changed there according to the spec. (In reply to comment #6) > Something happened to SendObjectAction::request. It looks like the type was > removed along with some other information. > > Do you remember what happened there Kenn? I don't believe anything should > have changed there according to the spec. > That wasn't intentional... and I'm not sure how it happened. Nothing changed in UML 2.2 w.r.t SendObjectAction::request as far as I am aware... (In reply to comment #5) > I had looked at the UML 2.2 spec with change bars and looked at your metamodel > changes. I factored out editorial type changes and just listed the "major" > work items. The list could possibly be the basis for a migration article. > > The list is subject to change as the migration work gets started for real. > > There is no rush for you to look at the list right away, just if you have some > time...I know you are busy with other stuff :). > > Thanks. > OK, I took a look. Here are some additional points that should be noted: - upper bound of ClassifierTemplateParameter::constrainingClassifier changed from 1 to * - Property no longer specializes TemplateableElement - Generalization::isSubstitutable should no longer be unsettable now that it has a default value - TimeExpression::expr and Duration::expr are now composite, which might require changes to tools (and requires changes in the item providers) - Type of TimeEvent::when changed from ValueSpecification to TimeExpression - WriteStructuralFeatureAction::result was also added - ClassifierTemplateParameter::defaultClassifier was removed Created attachment 108973 [details]
metamodel changes
Here's a patch the corrects the problem with SendObjectAction::request.
Created attachment 109782 [details]
Generated Code - needs some cleanup
Hi Kenn, I was wondering if you could attach the last metamodel changes as a zip rather than a patch. CVS seems to exclude the change TimeEvent::when (type change) when I apply the patch and I'm concerned about what else might be missing. Thanks. Created attachment 110039 [details]
latest source models
The latest source models are attached.
The Superstructure.uml does not update all occurrences of TimeEvent and result in incorrectly merged result (the type of 'when' is incorrect). Created attachment 110408 [details]
updated models
I've attached updated models. This version corrects the type of TimeEvent::when in the Communications package and fixes a problem with types that somehow became null in Infrastructure.uml. Note that there is an outstanding issue with L1 in that the merged result is inconsistent; I have brought this to the attention of the RTF so we'll see what shakes out.
Created attachment 110493 [details]
Updated models with standard profile removed and merged metamodel
Created attachment 110602 [details]
raw form of updated API
Created attachment 110612 [details]
API update - some work required in ConnectableElementOp and VertexOp
Created attachment 110614 [details]
updated models with genmodel
Created attachment 110686 [details]
updated models - with EOperation stereotype applied
Created attachment 110687 [details]
updated API - Corrected VertexOperations etc.
Created attachment 111318 [details]
summary document of changes from 2.1.2 to 2.2
Created attachment 112701 [details]
Sample test model
Created attachment 112702 [details]
smaller patch with just model migration changes.
- The XMI migration has not been considered in this patch.
- The UML22UMLResourceHandler may need to be augmented since we now go from older version directly to new in one hop. Some of the logic in the new UML212UML30ResourceHandler may need to be back ported.
Created attachment 113401 [details]
Updated models
Updated models:
Changed Supersturcture.uml to add EReference stereotype with isTransient=true.
Changed UML.uml to have one way association to get vertex/transition generating correctly.
Updated .genmodel for Duration.expr etc.
Created attachment 113403 [details]
API only update
Known issues: The version numbers in the .editor and .test plugins needs to be bumped up to 3.0.0 Also the XMI*.java migration path needs to be addressed. Created attachment 113416 [details]
API update combining migration - eaiser to work with.
Created attachment 113623 [details]
One small issue fixed with previous patch.
Created attachment 113916 [details]
API only
I applied the "API only" patch and copied the updated models from the earlier patch, then regenerated my OCL model to pick up the changed classifier and feature IDs. Attempting to run my OCL JUnit tests failed with a ClassCastException in the initialization of the UML2's UMLPackage. It was attempting to cast an EEnumImpl to EClass. The problem is, that the UML package initializes by loading the uml.ecore model from the same uml.internal.impl Java package. I don't see an update to this file in any of the non-obsolete packages, so the new generated package code is out of sync with its serialized model. I tried to create the uml.ecore for myself by reloading the UML.genmodel, but I couldn't do that: the Next and Finish buttons remain disabled in the GenModel re-load wizard, and there are no messages in the log. I don't think that simply copying the UML.ecor from the models folder is the right answer, because it is nearly three times as large as the old uml.ecore, so it must be something quite different. Basically, I can't complete a review. Created attachment 114095 [details]
UML.ecore
Christian,
I had not included the updated UML.ecore to reduce the API only patch but have added it now. Please retry. Thanks.
Comment on attachment 113916 [details]
API only
I think we should commit this in stages. First, the new source models and new API, then the migration handlers (including changes to the migration profile).
org.eclipse.uml2.sdk-feature/feature.xml
- Extra spaces seem to have crept into this file...
org.eclipse.uml2.uml.ConnectableElement
- Shouldn't ConnectableElement::end be changeable? I don't think this property was made read-only in the UML 2.2 specification...
- Should ConnectableElement::end be ordered? It was in UML2 2.2...
org.eclipse.uml2.uml.Generalization
- Generalization::isSubstitutable may no longer need to be unsettable...
org.eclipse.uml2.uml.Vertex
- Shouldn't Vertex::incoming and Vertex::outgoing be changeable? I don't think these properties were made read-only in the UML 2.2 specification...
org.eclipse.uml2.uml.internal.resource.UML212UML30Handler
- I'm thinking we should define/update classes like this every time there is a new schema version, and the name should be based on the older schema version (only)... so I'd suggest a name like UML212UMLHandler here; this handler would get updated the next time there is a schema change so that it would support going from the UML 2.1 schema to the latest...
org.eclipse.uml2.uml.internal.resource.UML212UML30LoadImpl
- UML212UMLLoadImpl?
org.eclipse.uml2.uml.internal.resource.UML212UML30ResourceFactoryImpl
- UML212UMLResourceFactoryImpl?
org.eclipse.uml2.uml.internal.resource.UML212UML30ResourceImpl
- UML212UMLResourceImpl?
org.eclipse.uml2.uml.internal.resource.XMI212UML30Handler
- Same comments as for UML212UML30Handler. Oddly, the superclass of this is XMI2UMLHandler... I assume because the delta between 'XMI' (OMG UML 2.1) and UML is minimal? These things might be better left independent, even if there is a small amount of code duplication... We really need comments on these classes so we can keep track of all the versions!
org.eclipse.uml2.uml.internal.resource.XMI212UML30LoadImpl
- XMI212UMLLoadImpl?
org.eclipse.uml2.uml.internal.resource.XMI212UML30ResourceFactoryImpl
- XMI212UMLResourceFactoryImpl?
org.eclipse.uml2.uml.internal.resource.XMI212UML30ResourceImpl
- XMI212UMLResourceImpl?
org.eclipse.uml2.uml.internal.resource.XMI2UMLHandler
- Need to update the copyright year. Should we consider a separate subclass instead, for parity with the UML handlers?
org.eclipse.uml2.uml.internal.resource.XMI2UMLSaveImpl
- We may not need that part of the code... but that brings up an interesting question. If a model in OMG UML 2.1(.1/.2) format is opened and re-saved, should the serialization be OMG UML 2.1(.1/.2) or 2.2? I'm thinking that if the original model is OMG UML, the version shouldn't change when saved (which means we DO need this code... sometimes), but if a UML model is saved as XMI for the first time, we should use the latest.
org.eclipse.uml2.uml.resource.UML2122UML30ResourceHandler
- UML212UMLResourceHandler? Again, we need comments to keep the versions straight.
org.eclipse.uml2.uml.resource.UML212UML30ExtendedMetaData
- UML212UMLExtendedMetaData? Again, we need comments to keep the versions straight.
org.eclipse.uml2.uml.resource.UML212UML30Resource
- UML212UMLResource? UML2_2_1_0_CONTENT_TYPE_IDENTIFIER should be named UML_2_1_0_CONTENT_TYPE_IDENTIFIER and should probably be defined on the parent interface (UMLResource).
org.eclipse.uml2.uml.resource.UML22UMLResource
- Extra space has appeared at the end of this file.
org.eclipse.uml2.uml.resource.UML22UMLResourceHandler
- What's here so far seems OK... we should add the missing code and check these changes in later. Note that the migration profile needs to be used for OMG UML sources as well, i.e. to cover delta between UML 2.1(.1/.2) and UML 2.2.
org.eclipse.uml2.uml.resource.UMLResource
- Why was the content type constant removed?! It should be changed to 3_0_0 instead of 2_1_0.
org.eclipse.uml2.uml.resource.XMI212UML30Resource
- XMI212UMLResource?
org.eclipse.uml2.uml.resource.XMI2UMLExtendedMetaData
- Should we consider a separate subclass instead, for parity with the UML extended metadata?
org.eclipse.uml2.uml.resource.XMI2UMLResource
- There seem to be a lot of extra spaces. Should we consider a sub-interface for the new constants? Let's look at this once the API changes are committed...
org.eclipse.uml2.uml.util.UMLUtil
- We need to adjust the processing of generics during UML/Ecore conversion to make use of the fact that classifier template parameters now have multiple constraining classifiers.
org.eclipse.uml2.uml.ecore.importer.UMLImporter
- Registration of both UML and UML_2_2 content types seems redundant for XMI case.
org.eclipse.uml2.uml.edit.providers.ConnectorEndItemProvider.java
- The "expert" designation for the 'definingEnd' feature appears to have been removed... was this intentional?
org.eclipse.uml2.uml.tests.ConnectorEndTest
- The copyright year has been updated unnecessarily (I don't believe this class has changed).
org.eclipse.uml2.uml.tests.TransitionTest.java
- The copyright year has been updated unnecessarily (I don't believe this class has changed).
org.eclipse.uml2.uml.resources/profiles/UML2.profile.uml
- I think the 'Property' stereotype should be named to 'TemplateableElement' (and extend only Property). Note that the metamodel and model libraries need to be saved against the new schema too.
Kenn, Thanks for the review. *I'll have to look at all copyrights again. *I'll have a look at the various names of classes. *I agree that the models and API should be delivered first. *Updates to Generics in the converter will be looked at after. *I realize that all the various other metamodels and libraries need to be updated. I'm fairly convinced that the existing metamodels are all correct so I will eat my own dogfood and convert the remaining models. Cheers, - James Thanks, James, for completing the patch. With that, the OCL UML binding re-generates cleanly and all of my tests pass. So, as I had anticipated, OCL is unaffected by these changes (excepting, of course, the inevitable changes in classifier and/or feature IDs). I haven't had enough time to take a closer look at the API changes ... it appears that Kenn has done a superior job of considering these details. I'll let you know (raise bugs, etc.) if I notice any smells. Thanks Christian, I have recently committed the API and metamodel changes. I will deliver the various resource handlers, that allow for migration, soon. Committed 20081005. (Galileo M3) The only piece not committed is the update to support Generics in the converters. A separate defect will be raised on that. However, generics is still supported in the same way as before (with the extended ecore profile ). verified 20081104 . |