Community
Participate
Working Groups
Created attachment 147453 [details] Proposed features and plugins Attached drawing provides a proposal for a (re)organisation of plugins and features to accommodate some potential project additions. org.eclipse... is implied throughout. ocl.registry is the M2M/QVT Declarative Model Registry whose migration can be discussed in Bug 289759. ocl.edit, ocl.ecore.edit, ocl.uml.edit is the missing edit support (mainly icons) submitted as Bug 196973. ocl.query, ocl.validation are the EMF/Query and EMF/Validation OCL plugins whose migration can be discussed in Bug 192506. It is not clear why there is no UML counterpart for these; probably a failure to track the evolution from emf.ocl. ocl.ui, ocl.ecore.ui, ocl.uml.ui are the M2M/QVT Declarative OCL Editor, with ocl.imp.runtime being the clone of one IMP plugin. This may be discussed in Bug 289761. I propose to migrate the revamped emf.ocl.examples.interpreter to the UI plugins. This may be discussed in Bug 259922. ocl.tests is a new plugin that will support shared JUnit tests for Ecore and UML bindings. This may be discussed in Bug 254919. ocl(lpg) is a possible split off from ocl to allow the two phase CST/AST framework to be re-used by non-OCL parsers (currently used by UMLX's KM3 parser). I think this would be useful. ocl(parser) is a possible split off from ocl to allow a reduced model+evaluation only usage of OCL. I think this may be unnecessary and require the OCL helper class to be partitioned. The diagram shows features closely corresponding to the current features, except that features include all their dependent sub-features. I have not added extra features. We could have a much smaller no-parsing set of features a model+evaluation+parse+edit but no editor set of features Do we want so much flexibility?
(In reply to comment #0) > ocl(parser) is a possible split off from ocl to allow a reduced > model+evaluation only usage of OCL. I think this may be unnecessary and require > the OCL helper class to be partitioned. This would be a cool feature, IMO. Not sure why it has been diagnosed as 'unnecessary' as opposed to a different parser support ;). In QVTO, I'm finalizing pure XMI execution so once the users are done with development (the whole SDK dependency), they might do a great job with just a lightweight runtime at deployment time. Actually, this is what our users often asked for and I believe it would be a sufficiently generic scenario useful for other consumers.
Most of the propositions of comment #0 seem to me like an interesting partitionning of OCL; yet as mentionned in comment #1, I also believe that having a separate "parser" plugin would be an awesome feature. For Acceleo, we separated from the beginning the parser from the evaluation from the ui ... and we can propose standalone users to simply include the XMI serialized by the parser, the "evaluation" part of Acceleo and... nothing more.
+1 to the proposed partitioning including ocl(parser). > a much smaller no-parsing set of features > a model+evaluation+parse+edit but no editor set of features As regards the extra features, they can be added later on user requests.
Hi all, As RC1 is today, we can't tackle any hard feature organization right now. I've done an analysis of the current OCL features organization: “Basic” features: org.eclipse.ocl-feature: lpg.runtime.java (plugin) org.eclipse.ocl (plugin) org.eclipse.ocl.ecore (plugin) org.eclipse.ocl.source-feature: lpg.runtime.java.source (plugin) org.eclipse.ocl.source (plugin) org.eclipse.ocl.ecore.source (plugin) org.eclipse.ocl.uml-feature: org.eclipse.ocl.uml (plugin) org.eclipse.ocl.uml.source-feature: org.eclipse.ocl.uml.source (plugin) org.eclipse.ocl.edit-feature: org.eclipse.ocl.edit (plugin) org.eclipse.ocl.ecore.edit (plugin) org.eclipse.ocl.uml.edit (plugin) org.eclipse.ocl.edit.source-feature: org.eclipse.ocl.edit.source (plugin) org.eclipse.ocl.ecore.edit.source (plugin) org.eclipse.ocl.uml.edit.source (plugin) org.eclipse.ocl.doc-feature: org.eclipse.ocl.doc (plugin) org.eclipse.ocl.examples-feature: org.eclipse.ocl.example.* (all the example plugins). “Coordinated” features: org.eclipse.ocl.all-feature: org.eclipse.ocl (feature) org.eclipse.ocl.uml (feature) org.eclipse.ocl.all.sdk-feature: org.eclipse.ocl.all (feature) org.eclipse.ocl.doc (feature) org.eclipse.ocl.edit (feature) org.eclipse.ocl.edit.source (feature) org.eclipse.ocl.source (feature) org.eclipse.ocl.uml.source (feature) org.eclipse.ocl.core.sdk-feature: org.eclipse.ocl (plugin) org.eclipse.ocl.source (plugin) org.eclipse.ocl.ecore (plugin) org.eclipse.ocl.ecore.source (plugin) org.eclipse.ocl.uml (plugin) org.eclipse.ocl.uml.source (plugin) org.eclipse.ocl.master-feature: org.eclipse.ocl.all (feature) org.eclipse.ocl.all.sdk (feature) org.eclipse.ocl.core.sdk (feature) org.eclipse.ocl.examples (feature) I see some problems with the current organization, which should be fixed now in RC1: - Core.sdk feature doesn't include LPG plugins. - I think that Core.sdk could rather be organized by features instead of plugins. - As suggested in the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=312725 , I propose to include the doc featuer into the Core SDK. On the one hand, and taking into account that conceptually all.sdk is core.sdk + edit plugins (and probably examples which are included in the master.features, which really confuses me), I propose the following organization in the coordinated features (whose practical change is that doc-feature is included into the core.sdk) org.eclipse.ocl.all-feature: org.eclipse.ocl (feature) org.eclipse.ocl.uml (feature) org.eclipse.ocl.core.sdk-feature: org.eclipse.ocl.all (feature) org.eclipse.ocl.source (feature) org.eclipse.ocl.uml.source (feature) org.eclipse.ocl.doc (feature) org.eclipse.ocl.all.sdk-feature: org.eclipse.ocl.core.sdk (feature) org.eclipse.ocl.edit (feature) org.eclipse.ocl.edit.source (feature) org.eclipse.ocl.master-feature: org.eclipse.ocl.all (feature) org.eclipse.ocl.all.sdk (feature) org.eclipse.ocl.core.sdk (feature) org.eclipse.ocl.examples (feature) On the other hand, I have a couple of questions which may be related: 1. Why the examples feature has not been included in the ocl.all-sdk one ? 2.Could somebody explain me that is that master-feature for ?. It includes the other 3 coordinated features (+ examples). I guess that it should be used in some releng facet, shoouldn't it? And a couple of suggestions, which could be considered for the next release: In our downloads webpage we have: Runtime link – which would match with org,eclipse.ocl.all feature contents Core SDK (Runtime, Source) link – which would match with org.eclipse.ocl.core.sdk feature contents SDK (Runtime, Source, Documentation, Examples) link – which would match with org.eclipse.ocl.core.all (or master >.<) featuer contents. We could, 1. Name (the projects, and probably feature names and/or description) following this sensible and more appropiate names (at least more meaningful): - org.eclipse.ocl.all → org.eclipse.ocl.runtime - org.eclipse.ocl.all.sdk → org.eclipse.ocl.sdk - org.eclipse.ocl.core.sdk → as is 2.Update the links names: - Runtime - Core SDK (Runtime, Sources, Documentation) - SDK (Runtime, Sources, Edit, Documentation, Examples) I'm working on a patch about the related features organization explained above. Let me know if you agree with it. Cheers, Adolfo.
We shouldn't make any significant feature changes in the Helios RC phase, unless there is a clear problem. I'm ambivalent about adding the core to the Core SDK, since the All-in-One SDK is specifically for everything including Doc; but if other committers want it, I'm a +0. It is possible that another community may object to adding the DOC, so perhaps I'm a -0.5. For 'Indigo' we should get round to what was planned here. Since the IMP editors didn't work out as planned clearly the Xtext bits are different. We probably want to partition clearly so that some parts are producxed by the +1 Core build, while others are from the +3 UI build.
Ed, and others I think that we have different problems, which I have tried to manage at once, bad decision ;P. Please, let me know which you do you agree/disagree. 1. Do we want to include LPG plugins in the core.sdk ? 2. Do we want to change core.sdk to be defined by features instead of plugins ? 3. Do we want to make all.sdk include core.sdk one ? 4. Do we want to make core.sdk include the doc feature ? I +1 all of them. I agree that 4 is debatable, however giving the fact that this feature is new in OCL 3.0, documentation makes sense in a SDK, and an OCL extender has required it, I'm inclined to include such documentation feature. > We shouldn't make any significant feature changes in the Helios RC phase, > unless there is a clear problem. Well, we haven't produced any RC yet, so I guess we are time to this last time changes, aren't we ? Cheers, Adolfo.
I've created to patches (coming now): a) Solves 1, 2 and 3 (doc in all.sdk feature) b) Solves 1, 2, 3 and 4 (doc in core.sdk feature). - If I receive at least one +1 from OCL team to 1, 2 and 3 problems, I'll commit patch a) and I'll make an I-build this midday to see that all works fine. - Due to 4 is more debatable, if I receive at least 2 +1 to 4 problem, I'll commit patch b) instead. Cheers, Adolfo.
Created attachment 168706 [details] Feature re-organization without including DOC into Core SDK
Created attachment 168707 [details] Feature re-organization including DOC into Core SDK
(In reply to comment #6) Hi all, > 1. Do we want to include LPG plugins in the core.sdk ? +1. I think it's a bug - we have a dependency on LPG. > 2. Do we want to change core.sdk to be defined by features instead of plugins ? And make core.sdk depend on o.e.ocl and o.e.ocl.uml features. Agree. This should also fix the first issue. Moreover, I think it should be fixed in RC1. Ed, do you agree? > 3. Do we want to make all.sdk include core.sdk one ? Yes, but not now. Let's do it in Indigo. > 4. Do we want to make core.sdk include the doc feature ? > I would raise a cross-project bug to have general guidelines on SDK features and deliverables. As of now, I am not inclined to do it in Helios. > > We shouldn't make any significant feature changes in the Helios RC phase, > > unless there is a clear problem. > > Well, we haven't produced any RC yet, so I guess we are time to this last time > changes, aren't we ? > Well, we can fix bugs but starting from M7 our features should remain stable. Formally, inclusion of docs affects the feature content, thus, it should have been done before M7.
> > 4. Do we want to make core.sdk include the doc feature ? > > > > I would raise a cross-project bug to have general guidelines on SDK features > and deliverables. As of now, I am not inclined to do it in Helios. Therefore, patch b) discarded. Let's focus on patch a) BTW, now this discussion about doc, examples, etc sounds to me... > > > 3. Do we want to make all.sdk include core.sdk one ? > > Yes, but not now. Let's do it in Indigo. > Could I have a reason about why not doing it now. Concerning contents, every feature (all, all.sdk and core.sdk) reamains as is. The change is how every feature obtains its contents: - core.sdk feature included 6 plugins, now it includes 3 features which indirectly include all the previous plugins (plus the 2 missed LPG plugins). - all.sdk included 6 features, now it includes 4 features which indirectly include the previous features. > > Well, we can fix bugs but starting from M7 our features should remain stable. > Formally, inclusion of docs affects the feature content, thus, it should have > been done before M7. Understood. Cheers, Adolfo.
Well, for now I'd change core.sdk only. Adolfo's a) patch looks good but now I wouldn't risk. o.e.ocl.all.sdk works, so let's leave it as is for now... My -1 for Helios and +1 for Indigo.
Ok, I'll make a new patch to correct point 1 and 2. Morever, since as you mentioned it's a bug, I'll create a new bugzilla to track the changes in a separate bugzilla. This bug will remain open for the next release. Cheers, Adolfo.
Simplifying the feature inclusions as in point 3, is not actually a change, since the intention is to still have eactly the same contents. I think we can do this after Alex has promoted the RC1 build, and also apply a similar include simplification to master. Check the ZIP sizes differ only by a feature.xml change on a before and after N-build; S-builds are subtly larger through signature files.
(In reply to comment #14) > Simplifying the feature inclusions as in point 3, is not actually a change, > since the intention is to still have eactly the same contents. > > I think we can do this after Alex has promoted the RC1 build, and also apply a > similar include simplification to master. Last minute changes often cause complications. Yes, the changes look plausible but there is no problem keeping features in their current state for Helios. There are no improvements from the end-user's point and since it already works, why to change it?
Ed, Alex, I want to take up this issue. I'd be particularly interested in having core.sdk feature included by the all.sdk one to make our hudson core job work when trying to create the Core-SDK zip. A new patch coming soon. I've also added a dependency between this bugzilla and the already resolved Bug 313124 to track the resolution og point 1 and 2 as it was said in comment #13 Regards, Adolfo.
Created attachment 180427 [details] Feature re-organization_a_try2 Patch: - Sorts out core.sdk feature inclusion by all.sdk one - Reorganize master feature since it only needs to include all.sdk feature (plus the examples one ;) )
+1 When editing copyrights, I try to simplify them to <Original Copyright holder> and others eliminating spurious intermediates. For transitive completeness, I think ocl.uml should include ocl ocl.edit should include ocl.all ocl.examples should include ocl.all.sdk with those in place you might then decide ocl.all.sdk does not need the ocl.core.sdk inclusion ocl.master does not need the ocl.examples dependency Up to you how much further to rationalize.
(In reply to comment #18) > +1 > > When editing copyrights, I try to simplify them to > > <Original Copyright holder> and others > > eliminating spurious intermediates. I'm not an enthusiastic of changing others copyrights. I simply don't include by company as a new copyright. Of course, feel free to do it but I don't think this is crucial. > > For transitive completeness, I think > > ocl.uml should include ocl > ocl.edit should include ocl.all > ocl.examples should include ocl.all.sdk > > with those in place you might then decide > > ocl.all.sdk does not need the ocl.core.sdk inclusion > ocl.master does not need the ocl.examples dependency I don't like make our "basic" features depend on the "coordinating" one. So, in principle, it stays as is. Special consideration requires the org.eclipse.ocl.uml feature. It look likes that is not consistent that the uml feature doesnt include the org.eclipse.ocl and lpg.runtime plugins, but it doesn't make sense to make the org.eclipse.ocl.uml feature also include org.eclipse.ocl feature since the latter contains the org.eclipse.ocl.ecore plugin. Two alternatives here: a) - Create an org.eclipse.ocl.ecore feature which contains the org.eclipse.ocl.ecore plugin and includes the org.eclipse.ocl feature - Remove the org.eclipse.ocl.ecore plug from the org.eclipse.ocl feature. - Make the org.eclipse.ocl.uml feature include the org.eclipse.ocl one b) - Make the org.clipse.ocl.feature also contain org.eclipse.ocl and lpg.runtime plugins. a) Looks more sensible. However, I think that removing plugins from a feature requires major version increment, so I'd face on b) until 4.0.0 arrives. Regards, Adolfo.
ok +1 for b)
> b) - Make the org.clipse.ocl.feature also contain org.eclipse.ocl and > lpg.runtime plugins. I obviously meant "Make the org.eclipse.ocl.uml" feature. Changes have been committed to the trunk.... Let's see what happens with the jobs. Cheers, Adolfo.
Ed, After reading this thread again, I'm just wondering what to do with the feature reorganization. On the one hand, as said in comment19, removing the coupling between Ecore/UML doesn't seem plausible without doing a major release change. I must also add that our UI will still remain under the examples umbrella. On the other hand trying to separate parsing from evaluation in different plugins seems interesting, even requested by our clients. However, In spite of not having done any investigation, it seems to be naive thinking that this could be efficiently done without breaking anything. Do we want to face on this in Indigo ? Regards, Adolfo.
Leave things pretty much as they are for 3.1. We will rethink substantially for 4.0.
4.0 is arriving :)... Reorganizing features as described in comment 19 sounds easy and sensible, however I'm wondering if working on a, somehow, "deprecated" infrastructure does make sense. At least, my suggestion is that any try to create separated parsing/evaluation functionality should be done with the pivot-based stuff, if desired. So I let you decide if we want to do comment 19 changes. I remember you have mentioned one time that some new features would be required in order to better organize the new (examples) stuff. Could you expand the idea here? On the other hand, I also had some suggestions. Do we want to split the current examples into "core" examples and "ui"/"tools" examples ? Do we want to split the current documentation into "core" documentation and "ui"/"tools" documentation ? Cheers, Adolfo.
I need to do a ping. I only have today/perhaps tomorrow to fix runtime features by M5, if it's finally endorsed. Regards, Adolfo.
(In reply to comment #25) > I need to do a ping. Well pinged. I must have missed comment #24 while at OMG. My feeling is that Core is small and simple. It is only there to provide something at +1 to allow Acceleo, EMF Compare, QVTo etc to build at +2. So Core has no Examples, No Documentation, no JavaDoc and quite possibly no Tests. Any added value comes with Tools. Since the Pivot isn't going to be promoted till post Juno, a major restructuring could wait till then. I certainly don't want to plan it and implement it in one day. So I suggest doing only what is essential for M5, and just possibly to aid in Update Site categorisation. (And update the Wiki so that I can promote M5 if I have to).
(In reply to comment #26) > (In reply to comment #25) > > I need to do a ping. > Well pinged. I must have missed comment #24 while at OMG. > > My feeling is that Core is small and simple. It is only there to provide > something at +1 to allow Acceleo, EMF Compare, QVTo etc to build at +2. So Core > has no Examples, No Documentation, no JavaDoc and quite possibly no Tests. > > Any added value comes with Tools. Now, we have mixed two concerns/issues here: 1. Doing what was explained in comment 19, that is, definitely decoupling EMF binding from the UML one: - Create an org.eclipse.ocl.ecore feature which contains the org.eclipse.ocl.ecore plugin and includes the org.eclipse.ocl feature - Remove the org.eclipse.ocl.ecore plug from the org.eclipse.ocl feature. - Make the org.eclipse.ocl.uml feature include the org.eclipse.ocl one. 2. What you have mentioned (which I proposed in Bug 318090 comment 15), that is, aligning the Core build with the Core SDK feature, which does really make sense to me. I'll be working on this this afternoon and tomorrow (fortunately, this only requires the core build, which is properly working :) ). > > Since the Pivot isn't going to be promoted till post Juno, a major restructuring > could wait till then. I certainly don't want to plan it and implement it in one > day. > > So I suggest doing only what is essential for M5, and just possibly to aid in > Update Site categorisation. (And update the Wiki so that I can promote M5 if I > have to). All right. I'll be back just in time for M5. If I have time I'll revise the wiki, though.
(In reply to comment #27) > 1. Doing what was explained in comment 19, that is, definitely decoupling EMF > binding from the UML one: > - Create an org.eclipse.ocl.ecore feature which contains the > org.eclipse.ocl.ecore plugin and includes the org.eclipse.ocl feature > - Remove the org.eclipse.ocl.ecore plug from the org.eclipse.ocl feature. > - Make the org.eclipse.ocl.uml feature include the org.eclipse.ocl one. I missed this. In principle what you suggest is definitely tidier, so if you really want to create an org.eclipse.ocl.ecore feature and rationalise the org.eclipse.ocl.uml feature ok, but removing the org.eclipse.ocl.ecore plugin from the org.eclipse.ocl feature could break something: a) I think the design principle was that anyone using OCL needs Ecore support so UML is an add on. b) It is amazing how sensitive legacy users are to trivial 'safe' changes [Remember that once upon a time there was only the Ecore binding and this was consequently the OCL feature.] c) This improvement is not essential Is it worth the compatibility risk? org.eclipse.ocl is not useable by the pivot so this change does not facilitate any future packaging,
(In reply to comment #28) > (In reply to comment #27) > > 1. Doing what was explained in comment 19, that is, definitely decoupling EMF > > binding from the UML one: > > - Create an org.eclipse.ocl.ecore feature which contains the > > org.eclipse.ocl.ecore plugin and includes the org.eclipse.ocl feature > > - Remove the org.eclipse.ocl.ecore plug from the org.eclipse.ocl feature. > > - Make the org.eclipse.ocl.uml feature include the org.eclipse.ocl one. > > I missed this. In principle what you suggest is definitely tidier, so if you > really want to create an org.eclipse.ocl.ecore feature and rationalise the > org.eclipse.ocl.uml feature ok, but removing the org.eclipse.ocl.ecore plugin > from the org.eclipse.ocl feature could break something: True, and that's the reason for waiting for a major version increase to do this features refactoring. > > a) I think the design principle was that anyone using OCL needs Ecore support > so UML is an add on. org.eclipse.ocl.uml feature (and corresponding plugin) provides implementatation for OCL assuming you want UML as your metamodel. org.eclipse.ocl.ecore feature (and corresponding plugin) would provide implementation for OCL assuming you want Ecore as your metamodel. org.foo.bar.MySophisticatedMetamodel feature would want to provide implementation for OCL assuming its SophsticatedMetamodel as its metamodel. Every metamodel binding implementation would probably want to know of the org.eclipse.ocl feature, but none of org.eclipse.ocl.ecore plugin and/or feature. > > b) It is amazing how sensitive legacy users are to trivial 'safe' changes > > [Remember that once upon a time there was only the Ecore binding and this was > consequently the OCL feature.] Certainly, no safety for somebody who would be exclusively depending/including the org.eclipse.ocl.feature. One breaking (for a sensible refactoring) consequence of this major version increase. However, as I mentioned in a comment, not sure if it's worthy when these plugins/features are going to be deprecated. > > c) This improvement is not essential > > Is it worth the compatibility risk? org.eclipse.ocl is not useable by the pivot > so this change does not facilitate any future packaging, neither essential, nor necessary taking into account it's going to be deprecated stuff. I already have bug/289763 ready to be pushed. Everything gets much more sensible, but I'm dropping it out... unnecessary change, certainly. I'll directly push a small change to make the core build only produce the CoreSDK feature. Cheers, Adolfo.
