Community
Participate
Working Groups
Make EcoreEvaluationEnvironment.getCollectionKind and coerceValue protected to support use of extended QVTo collections in Tuples. See Bug 352958.
+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.]
No problem with making these two methods protected. +1
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?
I will simply make the two trivial changes, run all tests, commit to master and push. Objections?
Go for it.
(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?
(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.
(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.
Committed the change with 3.2.0 version setting to master. Will now downport to RC1 maintenance branch with API filter.
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.
(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.
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.
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.
> 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.
(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.
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.
(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?
(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.
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.
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.
This is indeed now on master and maintenance/R3_1. While checking the history, I indeed found the [xxxxx] prefixes useful and necessary.
(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.
Revert pushed to maintenance/R3_1. Missing 3.1.1's coming soon.
CLOSED after a year in the RESOLVED state.
