Community
Participate
Working Groups
Build Identifier: Currently the EMF model is out of sync with the code. As far as I can see, the following differences exist: 1. The Documentation-Element does not extend anything in the EMF model, but extends WSDLElement in interface code and ExtensibleElementImpl in implementation code. 2. OnEvent contains the feature "xsdElement", but in code "XSDElement" is used. 3. CorrelationPattern defines "requestresponse" in the model, but "request-response" is used in the code. 4. An own (*.bpel.*)ExtensibilityElementImpl is used in the code, but no own ExtensibilityElement is defined in the model - those during code creation the *.wsdl.*.ExtensibilityElementImpl is used. 5. The creation of model code with an uptodate EMF-plugin seems to fix some issues that should be applied to the current BPEL model code as well. Additionally it would be nice to have a formatter definition at least for the model project, up to now its difficult to compare changes after model creation. Reproducible: Always
Created attachment 191677 [details] Proposal for synchronisation of model with code I attached a proposal of the new model that tries to create the code as it is now. I don't add the result of the model creation, as this should be the task of the comitter (who uses the correct formatter settings). 1.) Documentation extends ExtensibleElement. 2.) The feature for OnEvent is named "XSDElement". 3.) CorrelationPattern#requestresponse is using "request-response" as literal now. The code should use the literal, not the name, when accessing CorrelationPattern instances (not included in the patch). 4.) The ExtensibilityElementImpl is now renamed to BPELExtensibilityElementImpl (to prevent name clashes) and classes from messageproperties and partnerlinktype extend the type BPELExtensibilityElement in EMF.
Created attachment 191681 [details] Patch for working with literals in CorrelationPattern Added adjustments for: "The code should use the literal, not the name, when accessing CorrelationPattern instances".
Created attachment 191689 [details] Synchronisation of EMF model with code Thinking about point 4 again, maybe it's better to introduce no own interface BPELExtensibilityElement. Thus I changed the implementation to ignore the different super classes in ...messageproperties.impl and ...partnerlinktype.impl during model creation. Additionally I integrated the previous patch for "CorrelationPattern" into this one. Applying the new patch and recreating the model did not lead to any obvious errors, thus this is my proposal for a fixed model
I just noticed, that the new SampleStructuredActivityImpl contains a "@generated" in the adapted basicSetVariable method, should be "@customized" or similar. The EMF support in eclipse should really show a warning if someone changes generated code without changing the JavaDoc tag - but thats not our task here...
@Tobias: I have elected to keep the BPELExtensibleElement just in case - it gives us a level of isolation from the WSDL model and a bit more flexibility. I hope this doesn't affect anything that you are working on. I regenerated ALL of the models in org.eclipse.bpel.model from the *.genmodel files and everything looks good to me.
It seems that you created the model with Indigo (Eclipse 3.7), as my EMF package in Eclipse 3.6.2 has no class "org.eclipse.emf.ecore.util.Switch". I'm fine with switching to 3.7, but you should really update the documentation (http://www.eclipse.org/bpel/install.php) then.
(In reply to comment #6) > It seems that you created the model with Indigo (Eclipse 3.7), as my EMF > package in Eclipse 3.6.2 has no class "org.eclipse.emf.ecore.util.Switch". > > I'm fine with switching to 3.7, but you should really update the documentation > (http://www.eclipse.org/bpel/install.php) then. My apologies - I wasn't aware that the EMF version and API had changed between 3.6.2 and 3.7! Of course we want to keep the BPEL designer backwardly compatible as much as possible. I'll regenerate the model code on helios with EMF 2.6 which should build on indigo/EMF 2.7 also.
Rebuilt all models with EMF 2.6 on eclipse 3.6.2 and tested with eclipse 3.6.1 and 3.7 M5.
Verified, it's now working with 3.6.2. As SMILA had a Milestone today, I linked to the last working SNAPSHOT (H60) in our installation description (http://wiki.eclipse.org/SMILA/BPEL_Designer). I will adapt it later to the new version.
Created attachment 192524 [details] Readded "reconcile()" During evaluation of #341729 I noticed that the "reconciliation" is broken - the new BPELExtensibleElementImpl does not use the ReconcilationHelper anymore. The result is that changes to elements in the XML view are not affecting the nodes in the design view. My patch fixes that.
Reopened because of reconciliation problem (see above).
OK, I hope this is the last of them ;)
Comment on attachment 191689 [details] Synchronisation of EMF model with code Updated iplog flag for v1.0 release review.
Comment on attachment 192524 [details] Readded "reconcile()" Updated iplog flag for v1.0 release review.
