[releng] mdt-ocl-SDK-I201001070745.zip contains example and master features

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 299168 | | Status | CLOSED FIXED | | Importance | P3 normal | | Reported | Jan 08, 2010 16:14 EDT | | Modified | May 27, 2011 02:54 EDT | | Version | 3.0.0 | | Reporter | Anthony Hunter |

Description

The mdt-ocl-SDK-I201001070745.zip should only contain the SDK feature.

In 1.3.0, the SDK had the top level feature org.eclipse.emf.ocl.sdk_1.3.0

In 3.0.0, it looks like the mdt-ocl-SDK-I201001070745.zip has org.eclipse.ocl.master_3.0.0 feature which brings in the org.eclipse.emf.ocl.examples_3.0.0 (and source). org.eclipse.emf.ocl.sdk is not longer present.

We should return to the SDK without examples to match to other modeling projects in Helios.

I.e. we want the SDK to develop Eclipse applications making use of OCL, but we do not want to be forced of the burden of having the examples installed into the target.

[eclipse-ocl-bot]

By Anthony Hunter on Jan 08, 2010 16:21

In addition:

Features with errors and warnings\ Feature ID org.eclipse.ocl.master\ Feature Name n.a\ Version 3.0.0.v200912161120-7A--7Qb22VO-GYQfZhQ57Xxw10n0\ Errors

1. This feature includes the following features which were unavailable in the product
   • org.eclipse.ocl.all.sdk version 3.0.0.v200912161120-7G--9Ia55eDTEfhU6SdZmNkUi5dZ match-rule null
   • org.eclipse.ocl.all version 3.0.0.v200912161120-77--7EB1IDFsFIBTDMFRDNFB match-rule null

[eclipse-ocl-bot]

By Ed Willink on Jan 10, 2010 07:13

The master feature has included the examples ever since nickb set it up in Feb 2008 for MDT/OCL 1.2.0.

Presumably the actual change is that the Athena build for 3.0.0 uses the master feature whereas the old-style build for 1.3.0 did not.

A revamp of the feature/names has been due for some time. (Bug 289763)

Anthony: Can you recommend an Athena-built project of similar complexity to MDT/OCL that you would like us to emulate?

[eclipse-ocl-bot]

By Ed Willink on Jan 10, 2010 14:59

The doc feature had a spurious inclusion of the examples plugin (fixed in CVS).

(The examples will need its own doc feature to document its GUI and avoid reintroducing this inclusion.)

Changing the releng build.properties to have all.sdk as the main feature eliminates the examples from the SDK, but unfortunately eliminates the examples altogether. Maybe buildExtra needs to create the examples zip.

If build.properties uses the master feature, this feature appears in the runtime zip which cannot be useful.

[eclipse-ocl-bot]

By Alexander Igdalov on Jan 10, 2010 16:23

Hi all,

The examples were present in OCL SDK v 1.3.0. Why not to keep the same behaviour in 3.0.0? On the other hand, if we get rid of examples in the SDK why not to get rid of docs as well? If so our SDK will become equal to the OCL runtime.zip.

Moreover, if we eventually agree to exclude the examples, I would filter them out in buildExtra.xml prior to making the SDK.zip, so that the main-feature-to-build is org.eclipse.ocl.master (or some new one which would include the examples). Otherwise, in addition to problems with examples.zip (which could be fixed in buildExtra.xml) we won't have examples on our update site which is much worse.

(In reply to comment #1)

In addition:

Features with errors and warnings Feature ID org.eclipse.ocl.master Feature Name n.a Version 3.0.0.v200912161120-7A--7Qb22VO-GYQfZhQ57Xxw10n0 Errors

1. This feature includes the following features which were unavailable in the product
   • org.eclipse.ocl.all.sdk version 3.0.0.v200912161120-7G--9Ia55eDTEfhU6SdZmNkUi5dZ match-rule null
   • org.eclipse.ocl.all version 3.0.0.v200912161120-77--7EB1IDFsFIBTDMFRDNFB match-rule null

Anthony, how did you get these errors? Could you please provide a link to the console log if available?

[eclipse-ocl-bot]

By Ed Willink on Jan 11, 2010 03:31

Alex: I agree with your sentiments, but not quite all the detail; the SDK has useable source whereas the runtime does not.

I think the GEF Download page (http://www.eclipse.org/gef/downloads/) is relevant.

There is the All-In-One Update Site and the All-In-One SDK including Examples.

Then there are lesser SDKs and runtimes without examples.

---

Developing plugins on Eclipse has given me some insight into the availability of examples.

It was a long time before I discovered that the Platform Examples contained a very useful Undo stack browser. So the failure to package Platform Examples in the Platform SDK does developers a disservice. Conversely some examples provide gratuitous menus and widgets that irritate me once I have installed the Platform Examples.

I favour provision of all examples in the primary All-In-One SDK, subject to ensuring that they have minimum impact when not wanted and we ensure that the UI capabilities provides sufficiently fine-grained control of the examples' visibility.

---

However, if we are using the examples to distribute incubation/bleeding-edge/less-stable-API material are we able to have the examples in the primary SDK which is presumably what goes in the Modeling Package?

---

It would help if we could find some Eclipse-wide policy statement as to what facilities the SDK should provide to what target audience.

[eclipse-ocl-bot]

By Alexander Igdalov on Jan 11, 2010 07:27

(In reply to comment #5)

Alex: I agree with your sentiments, but not quite all the detail; the SDK has useable source whereas the runtime does not.

I think the GEF Download page (http://www.eclipse.org/gef/downloads/) is relevant.

There is the All-In-One Update Site and the All-In-One SDK including Examples.

Then there are lesser SDKs and runtimes without examples.

This might be a good idea to reorganize our artifacts like that. However, I don't think it should be done in this release.

As a side note, the only recommended way to install new plugins into the platform is using the update site. The SDK zip is now used in the releng of downstream projects. If there are other usages - the successful result is not guaranteed.

Since I use the update site only, I actually don't see whether or not it is important to have examples in the SDK. But my preference is to preserve the old behaviour.

Moreover, all MDT projects include examples in their SDKs (the downloads page informs about it only in case of UML2 but in fact UML2/OCL/XSD/Uml2Tools ship SDK with examples).

---

It would help if we could find some Eclipse-wide policy statement as to what facilities the SDK should provide to what target audience.

Yes, that would be great. If we decide to exclude the examples then other MDT components follow this policy too. I CC Kenn to find out his opinion.

[eclipse-ocl-bot]

By Alexander Igdalov on Jan 11, 2010 07:34

If we decide to exclude the examples then other MDT components follow this policy too.

==

I wasn't clear. I think we should follow the same policy for all MDT components. Thus, all MDT components should decide whether to have examples in their SDKs.

[eclipse-ocl-bot]

By Anthony Hunter on Jan 11, 2010 09:24

(In reply to comment #0)

I.e. we want the SDK to develop Eclipse applications making use of OCL, but we do not want to be forced of the burden of having the examples installed into the target.

To be clear, if I want all ocl, I can get the master zip. That is not the issue.

I want to consume the OCL SDK in my software development product, so I want the full OCL authoring capabilities as well as the documentation.

I do not want the examples installed in the product however. Furthermore I do not want my product runtime polluted with hundreds of examples from the modeling project.

All Modeling SDK features should not contain examples, as we delivered in Galileo.

[eclipse-ocl-bot]

By Kenn Hussey on Jan 11, 2010 09:46

(In reply to comment #8)

I do not want the examples installed in the product however. Furthermore I do not want my product runtime polluted with hundreds of examples from the modeling project.

Would it help if we added installers for the examples, so that they come with less up-front burden but are still available in the SDK? Depending on how extensive the documentation is (for most projects, it's just the generated Javadoc), the examples can go a long way to help developers develop things with the projects... and can be an important part of the SDK, IMHO...

All Modeling SDK features should not contain examples, as we delivered in Galileo.

M5 - API freeze - is in three weeks. If we want to make this (or some other) change across the board, we'll have to hurry to get buy-in and effect the change... Perhaps we could put together a proposal and discuss it at next week's Modeling PMC meeting.

[eclipse-ocl-bot]

By Ed Willink on Jan 11, 2010 12:34

In reply to comment #8:

Anthony; you are mistaken. Because of the doc to examples dependency, mdt-ocl-SDK-1.3.0.zip contains examples plugins and sources but does not include the corresponding features.

Both Alex and I like the accidental migration to full inclusion of examples. Other committers have yet to comment.

Anthony; since our experience is more as end users, it would be helpful to understand why your product requires full source thereby suggesting a quality environment supporting extension, but denies the users of your environment the extra facilities available as examples. Please explain your use case. Do you plan to raise this bug against GEF too?

In reply to comment #9.

Surely the API freeze is M6? \ Surely feature packaging is not API anyway?\ If MDT or Modeling comes up with an All-In-One-SDK and/or Minimal-SDK packaging philosophy then projects can surely adopt it all the way to RC2 as a bug fix?

[eclipse-ocl-bot]

By Anthony Hunter on Jan 11, 2010 13:32

This issue is not limited to modeling or GEF, think Eclipse platform.

When I download the Eclipse SDK, I get the bundles as well as the source and documentation. I do not need the examples to develop an Eclipse application.

The Eclipse SDK does however does have a separate set of installable examples. If I do file + new + plug-in, I am given the ability to create an example plug-in in my workspace.

If you want the full platform examplesinstalled into your eclipse runtime, then you need to install the Eclipse examples. Then you are able to do a file + new + SWT Examples view.

(In reply to comment #10)

Anthony; since our experience is more as end users, it would be helpful to understand why your product requires full source thereby suggesting a quality environment supporting extension, but denies the users of your environment the extra facilities available as examples. Please explain your use case. Do you plan to raise this bug against GEF too?

With GEF, this is done exactly the same way. The SDK does not include examples, but includes the org.eclipse.gef.examples.ui.pde that allows you to do a file + new + GEF example plug-in that allows you to get the source for the logic, flow, etc examples into your workspace.

If you additionally install the GEF examples into the SDK, you can do a file + new + logic diagram.

In the case of OCL, when I download the OCL SDK, I get the bundles as well as the source and documentation. I do not get the built examples.

The OCL documentation does however include the same capability to install an example plug-in into your workspace. You can create a new + example + OCL Interpretor plug-in.

So yes, the org.eclipse.ocl.doc feature includes the org.eclipse.emf.ocl.examples plug-in and the OCL SDK has this feature.

However, in 3.0.0 the SDK ZIP now includes the additional org.eclipse.emf.ocl.examples feature with all the examples. This was the examples you had to download separately in 1.3.0. The org.eclipse.emf.ocl.examples feature includes org.eclipse.emf.ocl.examples.interpreter which is now installed in your Eclipse SDK.

Let me know if that does not make sense.

[eclipse-ocl-bot]

By Kenn Hussey on Jan 11, 2010 13:35

(In reply to comment #10)

Surely the API freeze is M6?

Surely feature packaging is not API anyway? If MDT or Modeling comes up with an All-In-One-SDK and/or Minimal-SDK packaging philosophy then projects can surely adopt it all the way to RC2 as a bug fix?

Oops, you are so right. Sorry about that. I knew it was close to EclipseCon (which M6 is), and have been thinking about EclipseCon a lot lately. ;)

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 13, 2010 08:41

Hi All,

Sorry for the late response.

Well, the main point here is understanding that the unique example shipped by MDT-OCL project, provides (creates in the workspace) a set of the plugins which when installed into the platform facilitates an examplary tool which certainly enhances a modeling product/tool which wants to deal with OCL expressions. For this reason I would definitely consider this specific example (o.e.emf.ocl.examples and o.e.emf.ocl.examples.interpreter plugins) as part of any MDT-OCL SDK. So we should focus in how these plugins must be included by the features. In principle, it seems that the examples-feature should be the main candidate to include those plugins, therefore, the examples-feature should be included in the SDK.

On the other hand, I understand that MDT-OCL could provide other kind of examples (for instance, a set of OCL expressions for a specific metamodel) which wouldn't probably be of interest to be part of the SDK.

This example (the interpreter AKA OCL Console), should not probably have been considered as an example, but as part of the UI of the project due to the value it provides. This is a different discussion, though.

From my point of view, I think that we should firstly have a concense at MDT or Modeling project level about the decision of including or not including the examples feature in our SDK, so Kenn, I think that it could be a good idea unifying any criteria, so if you are able to introduce the discussion into the next PMC meeting, it would be great.

As a result of the decision, If we all must ensure that the examples-feature must not be included into the SDK, we will have to do it, and then take one of the following decision:\ a) Lose the example plugins which provides the OCL console for the SDK. They would be obtained installing the examples feature (via update-site for instance). I would avoid this.\ b) Promote the example plugins as part of the project UI. I would avoid this, since new approaches are in progress (Bug 297475, Bug 259922) and we should probably wait until the next release to have the better and more stable OCL evaluator before promoting it.\ c) Make the example plugins be included in the DOC feature. As far as I have understood from the thread, this is what was previously done in MDT-OCL, and what is currently done for GEF, am I wrong?. The easiest one.

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Alexander Igdalov on Jan 13, 2010 08:59

(In reply to comment #13)

Hi Adolfo,

c) Make the example plugins be included in the DOC feature. As far as I have understood from the thread, this is what was previously done in MDT-OCL, and what is currently done for GEF, am I wrong?. The easiest one.

... but in this case we WILL have the example plugins is our SDK since the latter includes the docs))

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 13, 2010 09:17

... but in this case we WILL have the example plugins is our SDK since the latter includes the docs))

Yes, that's the idea. The general problem of not including the examples-feature which usually provides some domain-specific examples (for instance some exemplary OCL documents with OCL expressions) into the SDK, could not prohibit us including an specific useful example which provides a tool (OCLConsole) which is useful for an OCL developer. As I've said I wouldn't be happy removing the OCLConsole from the SDK.

Maybe I'm wrong, but we haven't never received any complain about having our OCL Console example plugins into the SDK. The problem have appeared when we decided to make the examples-feature part of it. I don't know if you see the difference...

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Alexander Igdalov on Jan 13, 2010 09:26

(In reply to comment #15)

... but in this case we WILL have the example plugins is our SDK since the latter includes the docs))

Yes, that's the idea. The general problem of not including the examples-feature which usually provides some domain-specific examples (for instance some exemplary OCL documents with OCL expressions) into the SDK, could not prohibit us including an specific useful example which provides a tool (OCLConsole) which is useful for an OCL developer. As I've said I wouldn't be happy removing the OCLConsole from the SDK.

Maybe I'm wrong, but we haven't never received any complain about having our OCL Console example plugins into the SDK. The problem have appeared when we decided to make the examples-feature part of it. I don't know if you see the difference...

Now I understand your idea. Well, I think plugins should be put into proper features. IMO the right place for example plugins is the examples-feature but not the doc-feature.

[eclipse-ocl-bot]

By Ed Willink on Jan 13, 2010 09:55

(In reply to comment #11)

Let me know if that does not make sense.

I'm afraid this does not make adequate sense.

I asked for an explanation as to why you should provide full OCL source in your product but not provide good examples.

You provided a detailed implementation without motivating your use case.

I want to see a philosopical requirement to which we (all modeling projects) can attempt to adhere.

In #13 Adolfo tries to distinguish good examples and gratuitous examples.

Even that is not easy.

Suppose/when we migrate the QVTd RoyalAndLoyal.ocl example. This is arguably gratuitous but also a source of valuable example syntax and project configuration.

Kenn: we need an SDK packaging requirement on behalf of at least all MDT projects.

In MDT/OCL examples cover two domains;

a) incubation code (very useful)\ b) example projects (moderately useful)

Which SDKs offer what functionality to whom?

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 13, 2010 11:51

Now I understand your idea. Well, I think plugins should be put into proper features. IMO the right place for example plugins is the examples-feature but not the doc-feature.

Alex, I agree, and I would do what we are actually doing (including the examples-feature in the SDK one, which includes our example plugins) if we were allowed to do it. If we aren't, I'm afraid that will have to decide on a), b) or c) (any other alternative ?) each of them with its + and -.

I'm inclined to choose c), whose -, as you have remarked, is that the example plugins would also be included in the doc-feature. BTW, I'm not used to dealing with features but if I'm not wrong the example plugins may be included in both, examples-features and doc-features (only the doc-features would be included in the SDK one).

I think that we will have to wait until next PMC meeting to make some progress on this.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 13, 2010 11:55

Alex, I agree, and I would do what we are actually doing (including the examples-feature in the SDK one, which includes our example plugins) if we were allowed to do it. If we aren't, I'm afraid that will have to decide on a), b) or c) (any other alternative ?) each of them with its + and -.

Wait.... the examples-feature is not included by the SDK one in any way >.< .... This is strange.... It seems that the current state of the CVS is option a).

Let me do some investigations...

[eclipse-ocl-bot]

By Kenn Hussey on Jan 13, 2010 12:25

(In reply to comment #17)

Kenn: we need an SDK packaging requirement on behalf of at least all MDT projects.

I've added an agenda item for next week's Modeling PMC call - see http://wiki.eclipse.org/Modeling_PMC_Meeting%2C_2010-01-19. Feel free to dial in and join in the discussion.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 13, 2010 12:36

Kenn,

mid-air collision.

(In reply to comment #19)

Alex, I agree, and I would do what we are actually doing (including the examples-feature in the SDK one, which includes our example plugins) if we were allowed to do it. If we aren't, I'm afraid that will have to decide on a), b) or c) (any other alternative ?) each of them with its + and -.

Wait.... the examples-feature is not included by the SDK one in any way >.< .... This is strange.... It seems that the current state of the CVS is option a).

Let me do some investigations...

Well, understood:

The examples have always been included into the SDK from time ago, because the\ org.eclipse.emf.ocl.examples plugin was included in the\ org.eclipse.ocl.doc.feature, so:

• The problem which Anthony is remarking has always been there.
• We have always been in the previously described c) situation.
• We are currently in the previosly described a) situation since Ed removed\ that "spurious" plugin entrance in the feature.xml file.

So thinking a little bit more about the problem. what about doing a similar\ approach which Anthony described for the GEF project?, so that

a) incubation code (very useful), is kept into the\ org.eclipse.ocl.ui.examples. projects.\ b) example projects (moderately useful), are treated as the expected\ org.eclipse.ocl.examples. projects.

When we consider that a org.eclipse.ocl.ui.examples. projects are mature\ enough, we could move them to official UI projects: org.eclipse.ocl.ui..

In this way, incubation code (in this case the OCL Console) would transparently\ be available in our SDK, and the discussion about the examples must or mustn't\ be in the SDK is not relevant from MDT-OCL perspective anymore.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Anthony Hunter on Jan 13, 2010 12:57

(In reply to comment #21)

The examples have always been included into the SDK from time ago, because the org.eclipse.emf.ocl.examples plugin was included in the org.eclipse.ocl.doc.feature, so:

• The problem which Anthony is remarking has always been there.

Agreed, this was always there and is not the problem. The problem I really raised this bugzilla for was:

(In reply to comment #0)

In 3.0.0, it looks like the mdt-ocl-SDK-I201001070745.zip has org.eclipse.ocl.master_3.0.0 feature which brings in the org.eclipse.emf.ocl.examples_3.0.0 (and source). org.eclipse.emf.ocl.sdk is not longer present.

mdt-ocl-SDK- should include the org.eclipse.emf.ocl.sdk feature. What we put in the SDK feature is a really a separate bugzilla I suppse.

(In reply to comment #20)

I've added an agenda item for next week's Modeling PMC call - see http://wiki.eclipse.org/Modeling_PMC_Meeting%2C_2010-01-19. Feel free to dial in and join in the discussion.

We seem to beat to death this same issue year after year. The SDK does not include installed examples. I blogged about this in 2008 : http://ahuntereclipse.blogspot.com/2008/10/whats-example-doing-in-my-sdk.html

[eclipse-ocl-bot]

By Alexander Igdalov on Jan 14, 2010 13:17

(In reply to comment #22)

Agreed, this was always there and is not the problem. The problem I really raised this bugzilla for was:

mdt-ocl-SDK- should include the org.eclipse.emf.ocl.sdk feature. What we put in the SDK feature is a really a separate bugzilla I suppse.

Anthony, why do you want the org.eclipse.emf.ocl.sdk feature? It is no longer supported. Do you have a dependency on org.eclipse.emf.ocl* plugins???

[eclipse-ocl-bot]

By Anthony Hunter on Jan 14, 2010 14:02

(In reply to comment #23)

Anthony, why do you want the org.eclipse.emf.ocl.sdk feature? It is no longer supported. Do you have a dependency on org.eclipse.emf.ocl* plugins???

Every other modeling project ships a SDK feature and in Galileo, OCL shipped an SDK feature. In turn, our IBM development products ship the SDK features.

So yes, it is a dependency for us.

Is there a technical reason for changing the organization of the features in OCL? I think I am missing something here, why can't we put the features back the way they were?

[eclipse-ocl-bot]

By Alexander Igdalov on Jan 14, 2010 15:02

(In reply to comment #24)

(In reply to comment #23)

Anthony, why do you want the org.eclipse.emf.ocl.sdk feature? It is no longer supported. Do you have a dependency on org.eclipse.emf.ocl* plugins???

Every other modeling project ships a SDK feature and in Galileo, OCL shipped an SDK feature. In turn, our IBM development products ship the SDK features.

So yes, it is a dependency for us.

Is there a technical reason for changing the organization of the features in OCL? I think I am missing something here, why can't we put the features back the way they were?

I think I understand you now. Actually you don't depend on old OCL plugins which are not supported now but you do depend on the SDK feature.\ The SDK feature in MDT OCL 3.0.0 is org.eclipse.ocl.all.sdk (the former org.eclipse.emf.ocl.sdk is not supported now since it contained legacy o.e.emf.ocl* plugins which became deprecated three years ago).

org.eclipse.ocl.all.sdk is present on our update site. However, for some reason it is not present in our SDK. I will investigate why.

Thanks for catching this,

• Alex.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 20, 2010 05:24

Alex,

Any conclusion about this ?. I must remind that NOW we are not providing the OCL Interpreter example in our SDK since the example plugin has been removed from the doc-feature.

PMC Meeting notes about this:

SDKs and Examples

* Should SDKs include examples? Can we establish (and adhere to) a convention for all Modeling projects?
      - We didn't discuss this. For the EMF SDK we provide examples that can be materialized in the workspace. 

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Alexander Igdalov on Jan 20, 2010 10:28

(In reply to comment #26)

Alex,

Any conclusion about this ?. I must remind that NOW we are not providing the OCL Interpreter example in our SDK since the example plugin has been removed from the doc-feature.

That's why I replaced the main feature to be org.eclipse.ocl.master and thus, the example plugins were included.

PMC Meeting notes about this:

SDKs and Examples

* Should SDKs include examples? Can we establish (and adhere to) a

convention for all Modeling projects?

• We didn't discuss this. For the EMF SDK we provide examples that can be materialized in the workspace.

In the context of this, I would provide the installing plugin with our examples (it includes the interpreter example) in the SDK. I think we need an all-project wide resolution for the examples in SDK which OCL will follow. Since there isn't one, I will make a compromising decision - remove the interpreter plugin from the SDK but provide an installer for it.

But the main problem would be to:

a) provide an sdk feature in the SDK zip\ b) have the examples on our update site

I am planning to fix it today.

[eclipse-ocl-bot]

By Ed Willink on Jan 20, 2010 11:37

Some indication of the wider requirement is provided by

Re: [modeling-pmc] Eclipse Modeling Package Mega Diet

A minimal 'SDK' is required to support usage of OCL with minimum bloat.\ This probably just o.e.ocl, o.e.ocl.ecore, o.e.ocl.uml. No edit or LPG or UI. (LPG will be pulled in from Orbit by consumers.)

NB this is smaller than either our current runtime ZIP or standalone ZIP.

I think "Stand-alone" should be o.e.ocl, o.e.ocl.ecore, o.e.ocl.uml + LPG (as it is). Revised title "Stand-alone (Runtime + LPG-runtime)"

I think "Runtime" should be o.e.ocl, o.e.ocl.ecore, o.e.ocl.uml (a significant trim)

We could provide "Runtime SDK" as o.e.ocl, o.e.ocl.ecore, o.e.ocl.uml + source, which is I think what Anthony wants. However this should align with an Amalgam add-the-source UI facility.

We should re-title the current "SDK (Runtime, Source)" as "All-In-One SDK (Runtime, UI, Source, Examples)".

[eclipse-ocl-bot]

By Alexander Igdalov on Jan 25, 2010 10:18

Hi Anthony,

The sdk feature (org.eclipse.ocl.all.sdk) is now present in OCL SDK starting from today's I-build at http://www.eclipse.org/modeling/mdt/downloads/index.php?project=ocl&showAll=0&showMax=5.

Regards,

• Alex.

[eclipse-ocl-bot]

By Alexander Igdalov on Jan 27, 2010 08:38

(In reply to comment #28)

Some indication of the wider requirement is provided by

Re: [modeling-pmc] Eclipse Modeling Package Mega Diet

A minimal 'SDK' is required to support usage of OCL with minimum bloat. This probably just o.e.ocl, o.e.ocl.ecore, o.e.ocl.uml. No edit or LPG or UI. (LPG will be pulled in from Orbit by consumers.)

NB this is smaller than either our current runtime ZIP or standalone ZIP.

I think "Stand-alone" should be o.e.ocl, o.e.ocl.ecore, o.e.ocl.uml + LPG (as it is). Revised title "Stand-alone (Runtime + LPG-runtime)"

I think "Runtime" should be o.e.ocl, o.e.ocl.ecore, o.e.ocl.uml (a significant trim)

We could provide "Runtime SDK" as o.e.ocl, o.e.ocl.ecore, o.e.ocl.uml + source, which is I think what Anthony wants. However this should align with an Amalgam add-the-source UI facility.

We should re-title the current "SDK (Runtime, Source)" as "All-In-One SDK (Runtime, UI, Source, Examples)".

+1. I would just prefer "Minimal SDK" or "Core SDK" to "Runtime SDK".

However this should align with an Amalgam add-the-source UI facility.

Ed, I don't know what this facility is. Could you please explain?

[eclipse-ocl-bot]

By Alexander Igdalov on Jan 27, 2010 09:52

(In reply to comment #30)

We need a new feature for the minimal SDK which would include o.e.ocl, o.e.ocl.ecore, o.e.ocl.uml and their sources only.

I'd call it o.e.ocl.core.sdk. Does everyone agree?

[eclipse-ocl-bot]

By Ed Willink on Jan 27, 2010 09:57

(In reply to comment #30)

+1. I would just prefer "Minimal SDK" or "Core SDK" to "Runtime SDK".

Ok: Core. (Minimal can always be superseded by a smaller Minimum).\

However this should align with an Amalgam add-the-source UI facility.

Ed, I don't know what this facility is. Could you please explain?

See the "[modeling-pmc] Eclipse Modeling Package Mega Diet" thread , where\ Cedric proposes a streamlined Modeling Package with a friendly GUI to\ selectively load the bloat.

(In reply to comment #31)

I'd call it o.e.ocl.core.sdk. Does everyone agree?

+1

[eclipse-ocl-bot]

By Alexander Igdalov on Feb 09, 2010 08:37

Core SDK containing the correct feature set (o.e.ocl.core.sdk only) will be available starting from the next I-build.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:54

Closing