Yes, hiccough's all the time ... but 
      doubt there's too many processes that milestone deadlines and PMCs could 
      help with (Well, M6 is consider the end of version changes). The best way 
      to address this is that suppliers and consumers communicate often, and if 
      there's something controversial, to have meetings and discussions until 
      its resolved. And in the worst case, do what Ed says. :) 
      But, I do agree with what I 
      think you are saying, that each project should have one primary release 
      for the Yearly release, and if they have clients that need some previous 
      release, that would be handled "on the side" and not to try and have both 
      in Helios. That might not always work, but to do otherwise takes a lot of 
      skillful effort. Ed, it 
      appears this is a Modeling internal issue that needs to be resolved 
      (quick). Let me know if there's anything I can do to help. Likewise, let 
      me know if I should just remove the components so it will no longer block 
      the build from completing. For example, if it can't be resolved by, say 
      Thursday, then I think they should be removed until the issue it resolved. 
      I'm not sure what else that would "drag along", but fear it would be a lot 
      ... such as GMF?! We are getting down to the wire on M4, with the platform 
      finishing this Friday, and after that time, I'm sure we'll have our hands 
      full with details, and this high level problem should be resolved by then 
      ... or, at least, some resolution that allows M4 to complete. Perhaps 
      other things could be done after M4, if there were other things to do. 
      Since Ed Willink didn't take 
      me up on the cross-project posting, I'll CC that list with this note, so 
      everyone knows the issue is being worked, but no clear resolution yet. 
      Let us know what you decide. 
      Thanks, 
      
      
      
      Hi David
My recollection is that every 
      year at about this time there is a major version number hiccough as 
      projects catch up with each other. Is this any different? Perhaps Eclipse 
      needs a policy that any major version increment after M1 needs PMC 
      approval to get versions in place promptly. We should not be trying to 
      guess where the problem is. Helios should 'know' that UML2 is 3.1.0, OCL 
      is 3.0.0 and any build for any release train project that uses other than 
      those should be identified, the offending reference can then be corrected 
      promptly by the 'offender' without impacting everyone else.
Looking 
      at the log file again, we don't need to guess: [exec] Contains: Cannot satisfy dependency:
[exec] Contains: 
      From: all.contributed.content.feature.group 1.0.0
[exec] Contains: To: 
      org.eclipse.ocl.all.sdk.feature.group 
      [1.4.0.v200908201900-787D8aA3QRRgQbeUhZhdeHk89tD-]
The problem is that all.contributed.content.feature.group is using 
      OCL 1.4.0M1b, even though OCL 1.4.0M2 is available. I think OCL 3.0.0M3 
      should fix the problem. Who is responsible for maintaining 
      all.contributed.content.feature.group and what project does it belong 
      to?
Regarding a cross-project posting, I'm afraid that I've done as 
      much as I can at this point.
I'm not the project leader, I do not 
      have releng access so cannot promote Sunday's stable OCL build that works 
      with EMF's fixed I-build (MDT/OCL 3.0.0M3 is ok). I do not want to change 
      project policy unilaterally.
While Ed Merks (https://bugs.eclipse.org/bugs/show_bug.cgi?id=293605#c35) has come very close to instructing us to abandon 1.4.0 so that 
      3.0.0 is the only choice, and while I have never been enthusiastic about a 
      1.4.0 release, the rest of the OCL team was clearly in favour of a 
      concurrent 1.4.0 release. Ed's comment was six days ago. Until at least 
      one other member of the team indicates how they want to follow Ed's 
      direction, I cannot reasonably issue cross-project statements that 1.4.0 
      is dead and 3.0.0 mandated, I can only indicate that as far as I'm 
      concerned 1.4.0 is dead.
   Regards
    
        Ed
David M Williams wrote: 
So, what's next? 
I suggest you post to cross-project list for 
      two reasons. 1. Keep everyone informed. 2. Someone might be able to help 
      solve the problem. 
Thanks, 
      
      
      
Hi James
I'm not sure what 'feature.group' 
      is. I assume it's a p2-ism.
org.eclipse.ocl.uml-feature 
      3.0.0.qualifier has
    <import 
      plugin="org.eclipse.uml2.uml" version="3.0.0" 
      match="compatible"/>
which is [3.0.0,4.0.0). 
I suspect 
      that someone is trying to use OCL 1.3 or 1.4.
  
      Regards
     Ed
James Bruck wrote: 
      
Hi Ed, 
      
The error seems to indicate the 
      following: 
Cannot 
      satisfy dependency: org.eclipse.ocl.uml.feature.group 
      2.0.0.v200901271800-3--7w311A19272741 depends on: org.eclipse.uml2.uml 
      [3.0.0,3.1.0) 
I think the problem is in the feature itself, not 
      a plugin. 
Regards, 
- James. 
      
      
      
Hi 
      James 
I'm not 'at my desk' right now so cannot check which OCL 
      plug-in has a [3.0.0, 3.1.0) rather than 
      [3.0.0, 4.0.0). 
Assuming there is such a plug-in, I will do a CVS change to 
      force a rebuild at 15:10ish EST with the changed range. 
I don't have full releng 
      privileges, so Alex may be able to do one sooner. 
      
Do you actually need a build; 
      surely it's just CVS you need updating? Which build of OCL are you 
      using? 
  Regards 
      
      Ed Willink 
      
      
      From: James Bruck [mailto:jbruck@xxxxxxxxxx] 
Sent: 07 December 2009 15:09
To: David 
      Williams
Cc: ed.willink@xxxxxxxxxxxxxxx; aigdalov@xxxxxxxxxxx; kenn.hussey@xxxxxxxxx
Subject: Re: [Helios] Failed for build 
      2009-12-06_13-54-12
Hi 
      Dave, 
This 
      has to do with UML2 moving up a minor version number for the first time in 
      the release.   I believe that OCL has a version dependency on [3.0.0, 
      3.1.0)   (not inclusive) of UML but we are now at version 
      3.1.0. 
I 
      believe the OCL component would need to respond by changing the version 
      range check. 
I could temporarily back out those changes so 
      Helios is fixed but I think the proper way to address this is for OCL to 
      create another build with updated version range checking. 
Cheers, 
- James. 
      
      
      
The following errors occured when building 
      Helios:
Software being installed: 
      all.contributed.content.feature.group 1.0.0
Only one of the 
      following can be installed at once: [org.eclipse.uml2.uml 
      3.0.0.v20081007-1910, org.eclipse.uml2.uml 2.2.2.v200811051031, 
      org.eclipse.uml2.uml 2.0.4.v200707131442, org.eclipse.uml2.uml 
      2.1.1.v200707311200, org.eclipse.uml2.uml 3.0.0.v200904241430, 
      org.eclipse.uml2.uml 2.2.100.v200808270930, org.eclipse.uml2.uml 
      3.0.100.v200909221515, org.eclipse.uml2.uml 3.0.1.v200908281330, 
      org.eclipse.uml2.uml 2.2.0.v200804231435, org.eclipse.uml2.uml 
      2.2.0.v200805051730, org.eclipse.uml2.uml 2.2.0.v200805141133, 
      org.eclipse.uml2.uml 3.0.0.v200905151700, org.eclipse.uml2.uml 
      2.2.1.v200808251630, org.eclipse.uml2.uml 3.1.0.v200912041155, 
      org.eclipse.uml2.uml 2.2.0.v200804291636, org.eclipse.uml2.uml 
      3.0.0.v20090407-1910, org.eclipse.uml2.uml 2.2.1.v200808191500, 
      org.eclipse.uml2.uml 2.0.5.v200802262248]
Cannot satisfy 
      dependency: all.contributed.content.feature.group 1.0.0 depends on: 
      org.eclipse.ocl.all.sdk.feature.group 
      [1.4.0.v200908201900-787D8aA3QRRgQbeUhZhdeHk89tD-]
Cannot satisfy 
      dependency: all.contributed.content.feature.group 1.0.0 depends on: 
      org.eclipse.uml2.sdk.feature.group [3.1.0.v200912041155]
Cannot 
      satisfy dependency: org.eclipse.ocl.all.feature.group 
      1.4.0.v200908201900-548_7EBJlGqKCLkKdLaMfM9 depends on: 
      org.eclipse.ocl.uml.feature.group 
      [2.0.0.v200901271800-3--7w311A19272741]
Cannot satisfy dependency: 
      org.eclipse.ocl.all.sdk.feature.group 
      1.4.0.v200908201900-787D8aA3QRRgQbeUhZhdeHk89tD- depends on: 
      org.eclipse.ocl.all.feature.group 
      [1.4.0.v200908201900-548_7EBJlGqKCLkKdLaMfM9]
Cannot satisfy 
      dependency: org.eclipse.ocl.uml.feature.group 
      2.0.0.v200901271800-3--7w311A19272741 depends on: org.eclipse.uml2.uml 
      [3.0.0,3.1.0)
Cannot satisfy dependency: 
      org.eclipse.uml2.feature.group 3.1.0.v200912041155 depends on: 
      org.eclipse.uml2.uml [3.1.0.v200912041155]
Cannot satisfy 
      dependency: org.eclipse.uml2.sdk.feature.group 3.1.0.v200912041155 depends 
      on: org.eclipse.uml2.feature.group [3.1.0.v200912041155]
Check the 
      log file for more information: https://build.eclipse.org/hudson/view/Repository%20Aggregation/job/helios.runBuckyBuild/235/console
      **************************************************************************** 
      Please consider the environment before 
      printing this email. 
      **************************************************************************** 
      Thales Research and Technology (UK) 
      Limited DISCLAIMER: The information 
      contained in this e-mail is 
      confidential. It may also be legally 
      privileged. It is intended only for the 
      stated addressee(s) and access to 
      it by any other person is unauthorised. 
      If you are not an addressee, you 
      must not disclose, copy, circulate or 
      in any other way use or rely on the 
      information contained herein. Such 
      unauthorised use may be unlawful. We 
      may monitor all e-mail communications 
      through our networks. If you have 
      received this e-mail in error, please 
      inform us immediately on +44 (0)1293 
      575987 and delete it and all copies 
      from your system. We accept no 
      responsibility for changes to any 
      e-mail which occur after it has been sent. 
      Attachments to this e-mail may contain 
      software viruses which could damage 
      your system. We therefore recommend you 
      virus-check all attachments before 
      opening. The registered office of 
      Thales Research and Technology (UK) 
      Limited is at: 2 Dashwood Lang Road, 
      The Bourne Business Park, Addlestone, 
      Weybridge, Surrey KT15 2NX. Registered 
      in England No. 774298. 
      **************************************************************************** 
        
      
      
      
      
No virus found in this incoming 
      message.
Checked by AVG - www.avg.com 
Version: 
      9.0.709 / Virus Database: 270.14.97/2550 - Release Date: 12/07/09 
      07:33:00
 
      
      
No virus found in this incoming 
      message.
Checked by AVG - www.avg.com 
Version: 
      9.0.709 / Virus Database: 270.14.97/2550 - Release Date: 12/07/09 
      07:33:00