Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Juno M2 aggregation -- will it be the worst milestone ever?


> Is it best to have all this pain now for M2 or defer some more pain till M3?


This mostly depends on your adopters ... but, I'd say the earlier the better? probably?

I'm not sure I understand all the issues ....  but in essence, are you saying the current failure,

Missing requirement: org.eclipse.ocl.edit.feature.group 3.1.0.v20110815-1500 requires 'org.eclipse.uml2.uml.edit [3.0.0,4.0.0)' but it could not be found

should be solved by ocl.edit changeing to [4,5) .... or, is there any chance [3,5) would work to avoid "split streams"?

And, I really am just asking ... I do not know the code well.

But, these sort of large rippling effects does remind me, to remind you ... it is a good time to check the coupling of all your code ... are there any dependencies that can be lessened?

Such as, in features, best not to have "feature level" require statements, unless you have a specific need to. Best to let the bundles work it out.

As the bundle level, would import-package work, instead of require-bundle? import package, if you have a small dependency, is often more immune to version changes.

I know such issues are not easy, snap decisions ... but, seems like a good time to ask.

Thanks,






From:        Ed Willink <ed@xxxxxxxxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        09/22/2011 10:31 AM
Subject:        Re: [cross-project-issues-dev] Juno M2 aggregation -- will it be the worst milestone ever?
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx




Hi Ed

Unfortunately evolution of the UML model changes a constraint and so changes the validate functions visible to client Validators. The UML2 4.0 change so far has one such change; there will probably be many more for Indigo. This makes it very difficult for MDT/OCL to be compatible with both UML2 3.x and 4.0 and equally difficult for UML2 4.0 to offer a clean UML 2.4 model while maintaining API compatibility with 3.x.

http://wiki.eclipse.org/Version_Numbering#How_to_specify_versions_when_plug-ins_re-export_other_plug-ins directs that all plugins exporting a major increment must also have a major increment, and http://wiki.eclipse.org/Version_Numbering#How_to_version_packages directs that all features must also have a major increment. Somewhere there is also a direction to keep major versions coherent, so I see no alternative to a major increment for MDT/OCL for Juno.

To minimize M2 impact, we can probably just change our UML2 dependencies to [4.0.0,5.0.0) although that may leave downstream UML clients in trouble, but no more than they're already in anyway. This requires that we disable the API checking until we make a major increment.

Is it best to have all this pain now for M2 or defer some more pain till M3?

   Regards

       Ed Willink

On 22/09/2011 11:31, Ed Merks wrote:

David,

I'm not sure why so many clients would strictly upper bound their EMF dependencies based on minor version increments.  I know UML2 does this because they extend EMFs GenModel and hence its implementation classes, but I don't expect a significant number of clients to be so intimately dependent on EMF's minor versions.  Of course there could be quite a few things downstream from UML2 that are affected...


Ed,

Clients (bundles) interested in UML2's version range can/should have direct dependencies on UML2 itself and those dependencies can reflect the range restrictions they feel are appropriate.  They don't need that information to trickle through your versions.  Of course if you make API changes in response to those of UML2, then you'll want to make version changes to reflect that level of change in your latest version.

Cheers,
Ed


On 22/09/2011 2:26 AM, Ed Willink wrote:

Hi David

Thanks for the early prompt. MDT/OCL at +1 will try to contribute very soon.

But, just checking our dependencies for a MDT/UML2 M2, I notice that I must have missed an announcement of a UML2 major version change, so as I understand it, MDT/OCL and all downstream projects must have a major version change too.

At present only an I-build exists for MDT/UML2 4.0 so that's what we must use for now. An esartly M2 would help Kenn.

   Regards

       Ed Willink



On 22/09/2011 03:54, David M Williams wrote:

Well, no, probably not ... but, it will take a lot of attention to get it done on time.

First greatest thanks to Kenn Hussey for making (or fixing) an "early" contribution repository [1] for EMF core (or, "base", I think they are now calling the platform-shared parts.


This allows Eclipse 4.2 M2 and EMF M2 to both be installed from repository sites. (For full issues, and longer term improvements, you can follow bug 356644).


Now the problem is that the new version of EMF (and maybe Eclipse M2?), apparently,  breaks numerous other contributions, apparently due to increased minor version numbers (combined with narrow ranges?).


To aggregate, at the moment, I would have to disable about 20 of the b3aggrcon files in org.eclipse.juno.build.


I can (and may) do some disabling, .... but, thought it would be a good time to review the process and timing of making contributions to an aggregation build:


you do not have to wait until your +n day to make a contribution. You can make a "warm-up" contribution at any time ... especially if it is needed to allow the aggregation to succeed. In other words, your +n day is the last possible day to make a contribution ... not the first day you may make one.


Many of the current problems are "ripple effects" from a few low level, commonly used bundles or features (in modeling projects, it appears) so, maybe with only a few fixes we'll be on the right path again, but, I ask that teams try to respond as quickly as possible to fix any "aggregation errors" they get notified about ... please do not think you can wait until your final contribution next week ... and even if you have not been notified yet, if you use EMF, please "peek ahead" with the M2 versions of Eclipse and EMF base and prepare an early version, even if you re-contribute your final version during the (final) window next week. After all, if we had to do a true "iteration" waiting for each of 20 project to fix their builds sequentially before the next one fixes theirs, then we will not finish in time.


Thanks, for your attention, let us know if questions or issues.


[1]
http://download.eclipse.org/modeling/emf/emf/updates/2.8milestones

[2]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=356644



_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


No virus found in this message.
Checked by AVG -
www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3911 - Release Date: 09/21/11



_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


No virus found in this message.
Checked by AVG -
www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3911 - Release Date: 09/21/11
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top