[ast] Make EcoreEvaluationEnvironment extensible for QVTo collections

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 352964 | | Status | CLOSED FIXED | | Importance | P3 normal | | Reported | Jul 25, 2011 00:54 EDT | | Modified | May 20, 2013 11:36 EDT | | Version | 3.1.0 | | Blocks | 352958 | | Reporter | Ed Willink |

Description

Make EcoreEvaluationEnvironment.getCollectionKind and coerceValue protected to support use of extended QVTo collections in Tuples. See Bug 352958.

[eclipse-ocl-bot]

By Ed Willink on Jul 25, 2011 01:09

+1. EcoreEvaluationEnvironment is part of the mature code so changes to APIs are increasingly difficult. Exposing a couple of private's as protected shouldn't create a maintenance nightmare.

[The whole coerceValue protocol is a workaround for using Java Object rather than OCL Value polymorphism. The revised pivot-based implementation should not have these problems since collections are explicitly CollectionValue's.

Bug 297390 suggested eliminating one usage of 'kind' whose 4/5 enumerated values are an embarassment for extension. The discussion and proposal got nowhere. The work on OCL to Java code generation has forced elimination of CollectionKind since that is part of the pivot model that is not necessarily available at run-time. QVTo should be able to provide an extended ValueFactory with additional createCollection methods.]

[eclipse-ocl-bot]

By Axel Uhl on Jul 25, 2011 04:17

No problem with making these two methods protected. +1

[eclipse-ocl-bot]

By Ed Willink on Jul 25, 2011 04:30

Axel: Since you're working in this area, I'll 'assign' this to you so that you can do it with less disruption to your other activities.

Note that this is for both 3.1.1 and 3.2.0.

Adolfo: Are we in good shape for a 3.1.1 build from GIT?

[eclipse-ocl-bot]

By Axel Uhl on Jul 25, 2011 05:09

I will simply make the two trivial changes, run all tests, commit to master and push. Objections?

[eclipse-ocl-bot]

By Ed Willink on Jul 25, 2011 05:16

Go for it.

[eclipse-ocl-bot]

By Axel Uhl on Jul 25, 2011 05:20

(In reply to comment #5)

Go for it.

One more caveat: making the two methods protected is considered a change that requires incrementing the minor version from 3.1.0 to 3.2.0. Ok?

[eclipse-ocl-bot]

By Ed Willink on Jul 25, 2011 05:25

(In reply to comment #6)

One more caveat: making the two methods protected is considered a change that requires incrementing the minor version from 3.1.0 to 3.2.0. Ok?

Yes for 3.2.0, No for 3.1.1.

(In reply to comment #4)

I will simply make the two trivial changes, run all tests, commit to master and push. Objections?

Surely this needs to be merged to maintenance/R3_1 too?

This reminds me: we don't seem to have an R3_1 tag as specified by the Indigo\ project plan.

---

Do the 3.1.1 merge first with 3.1.1 versions in all downstream features and an API filter to allow it in 3.1.1

Then 3.2.0 can and should have 3.2.0 versions.

[eclipse-ocl-bot]

By Axel Uhl on Jul 25, 2011 05:33

(In reply to comment #7)

(In reply to comment #6)

One more caveat: making the two methods protected is considered a change that requires incrementing the minor version from 3.1.0 to 3.2.0. Ok?

Yes for 3.2.0, No for 3.1.1.

(In reply to comment #4)

I will simply make the two trivial changes, run all tests, commit to master and push. Objections?

Ok, will push the changes to master then. This is where 3.2.0 should live. I'll then cherry-pick the private-->protected change onto R3_1 and add API filters there. What do you mean by "all downstream features?"

Surely this needs to be merged to maintenance/R3_1 too?

You mean that on the maintenance/R3_1 branch you'd also like to upgrade the version to 3.2.0 and merge the above changes?

This reminds me: we don't seem to have an R3_1 tag as specified by the Indigo project plan.

---

Do the 3.1.1 merge first with 3.1.1 versions in all downstream features and an API filter to allow it in 3.1.1

Then 3.2.0 can and should have 3.2.0 versions.

[eclipse-ocl-bot]

By Axel Uhl on Jul 25, 2011 07:28

Committed the change with 3.2.0 version setting to master. Will now downport to RC1 maintenance branch with API filter.

[eclipse-ocl-bot]

By Axel Uhl on Jul 25, 2011 07:36

Cherry-picked private-->protected and added API filter on maintenance/R3_1 to which I pushed the change. So there, the bundle version is still on 3.1.0, and an API filter is required to avoid errors.

[eclipse-ocl-bot]

By Ed Willink on Jul 25, 2011 11:59

(In reply to comment #8)

Ok, will push the changes to master then. This is where 3.2.0 should live. I'll then cherry-pick the private-->protected change onto R3_1 and add API filters there. What do you mean by "all downstream features?"

Anything that references a 3.1.1 must be >= 3.1.1. So all features that transitively include the 3.1.1 ocl.ecore must also be 3.1.1.

EMF has tried to be fairly 'optimal' recently since EMF changes are small. This seems to be causing trouble. I suspect that if we have any 3.1.1 we may want 3.1.1 all round.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jul 25, 2011 13:45

Hi Team,

I'm back again from my last week break...

I guess that you all know that this kind of changes are not appropriate for a Service Release... "Support use of extended QVTo collections in Tuples" sounds like an enhancement rather than a bug fix. Anyway, taking into account that this won't hurt anybody, and it will help real users instead (as claimed in the related bug), I'm OK with it.

Main development and maintenance stream builds should be working... I'll launch a couple of runs to see what happens. As Ed commented, features must be transitively increased.

P.S: Info about version numbering: http://wiki.eclipse.org/Version_Numbering

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jul 25, 2011 14:05

Maintenance one had been automatically run... Promotion was fine:

P2 repo: http://download.eclipse.org/modeling/mdt/ocl/updates/maintenance\ downloadable zips: http://www.eclipse.org/modeling/mdt/downloads/?project=ocl

Waiting for the end of the running of the main development stream one.

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jul 25, 2011 14:35

Waiting for the end of the running of the main development stream one.

All fine, as well...

P2 repo: http://download.eclipse.org/modeling/mdt/ocl/updates/interim\ downloadable zips: http://www.eclipse.org/modeling/mdt/downloads/?project=ocl

I've also configured the master job to periodically consult our GIT repository, to automatically start the builds.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Axel Uhl on Jul 25, 2011 15:29

(In reply to comment #14)

Waiting for the end of the running of the main development stream one.

All fine, as well...

Just pushed the transitive upgrade to 3.2.0 versions in the MANIFEST.MF files on master.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jul 26, 2011 12:08

Axel,

Please, ensure that features from maintenance stream are also properly updated.

I'll finally enable the promotion scripts in my crontab configuration file. I'll also create a crontab folder to have some tracking about how I'm using our promotion stuff to automatically promote our builds.

P.S: Axel, your last commits missed the ["bugnumber"] tag :)

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Axel Uhl on Jul 26, 2011 14:59

(In reply to comment #16)\ Adolfo,

Please, ensure that features from maintenance stream are also properly updated.

do you mean the *-feature projects on maintenance/R3_1? Why would they need an update? I didn't change the bundle version in R3_1.

P.S: Axel, your last commits missed the ["bugnumber"] tag :)

Sorry. Shall I commit --augment those commits, adjusting the comment or can we live with it?

[eclipse-ocl-bot]

By Ed Willink on Jul 26, 2011 15:13

(In reply to comment #17)

P.S: Axel, your last commits missed the ["bugnumber"] tag :)

Sorry. Shall I commit --augment those commits, adjusting the comment or can we live with it?

If it's easy perhaps. But it's a pretty easy regular mistake that we can live with.

I don't understand how commit comments work at all for GIT. For CVS the major comment with bug number was associated with the commit to HEAD. For GIT the merge to master seems to be commentless. Putting a [xxxxx] prefix on every commit to bug/xxxxx seems fatuous.

[eclipse-ocl-bot]

By Axel Uhl on Jul 27, 2011 03:34

The merging commit has an automatically-created comment such as

Merge branch 'bug/349300'

I agree that from the topology the bug ID should be evident then. I suggest putting the commit ID in brackets in the comment only if it's a minor thing that gets committed to master without affording a bug/xxxxxx branch for it.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jul 27, 2011 07:01

I'm afraid I don't agree...

I think you are forgetting cherry picking task. The commits are copied including author, comments, etc. I would like to see in the maintenance branch some bug-related information in the list of commits history of said branch.

Besides, when you are looking to the history of the repository, you may have a lot of mixed commits in it which come from different branches. Having the bug ID in the beginning of the comment definitely helps.

As commented, the commit comment inclusion (bug id and comment) could be automated as explained in Bug 349114 (coment 53). I don't see any reason which prohibits us to use this practice. Obviously, we are not amending or trying to fix any commit because we missed the Bug id information. However, let's do some effort to adopt this useful practice.

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Aug 12, 2011 12:11

This is indeed now on master and maintenance/R3_1.

While checking the history, I indeed found the [xxxxx] prefixes useful and necessary.

[eclipse-ocl-bot]

By Ed Willink on Aug 18, 2011 15:25

(In reply to comment #21)

This is indeed now on master and maintenance/R3_1.

I don't know why it is in R3,1 because it does not seem to be possible to placate the API filters. When the missing 3.1.1 version number upgrade is applied, the API filters fail. The filter in use was a wildcard something changed, which totally undermines API tooling.

Doing this change in SR1 is a courtesy, not a necessity. If QVTo solves Bug 352958 as an SR, we can revisit the API disabling consequences; but the QVTo changes almost certainly cannot be an SR update so our change for Juno will suffice.

[eclipse-ocl-bot]

By Ed Willink on Aug 18, 2011 15:36

Revert pushed to maintenance/R3_1.

Missing 3.1.1's coming soon.

[eclipse-ocl-bot]

By Ed Willink on May 20, 2013 11:36

CLOSED after a year in the RESOLVED state.