Community
Participate
Working Groups
The coordinated feature org.eclipse.ocl.core.sdk is incorrect: - It should rather be feature-based instead of plugin-based. - It doesn't include LPG plugins. Patch coming soon. Cheers, Adolfo.
Created attachment 168723 [details] Fixing patch
+1.
Committed to HEAD and after some adjustments in the build.properties (thanks Alex for helpeing here) the CoreSDK is ready for our RC1 :) Cheers, Adolfo.
+1. Is removal of 'individualSourceBundles' correct? Need to check the produced ZIPs.
(In reply to comment #4) > +1. Is removal of 'individualSourceBundles' correct? Need to check the produced > ZIPs. Zips seem to be correct. I removed individualSourceBundles to be in synch with build.properties in o.e.ocl.all.sdk-feature.
I've recalled why I initially made core.sdk contain only o.e.ocl, o.e.ocl.ecore, o.e.ocl.uml and their sources. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=299168#c28 and subsequent comments.
(In reply to comment #6) > I've recalled why I initially made core.sdk contain only o.e.ocl, > o.e.ocl.ecore, o.e.ocl.uml and their sources. > > See https://bugs.eclipse.org/bugs/show_bug.cgi?id=299168#c28 and subsequent > comments. Great, I'll update the wiki entrance to mention that "Mega Diet" packaging. Cheers, Adolfo.
The generated CoreSDK zip doesn't include the LPG plugins and the new included features. Patch coming soon. Cheers, Adolfo.
Well, I'm afraid that we have several problems. Apart from having a confusing situation about features and generated plugins, I want to do an analysis of the the problems I perceive when looking at the generated artifacts in the last S-build and N-build. mdt-ocl-runtime-3.0.0RC1: - We have a missplaced plugins folder with a lpg.runtime.java plugins as a root folder. - We don't have the ocl.all feature. - We have an extra ocl.edit feature. - We have the extra ocl.edit, ocl.uml.edit and ocl.ecore.edit plugins. mdt-ocl-CoreSDK-3.0.0RC1: - We don't have the ocl.all, ocl.source and ocl.uml.source features. - We don't have the lpg.runtime.java and lpg.runtime.java.source plugins. mdt-ocl-SDK-3.0.0RC1: - We have a missplaced plugins folder with a lpg.runtime.java and lpg.runtime.java.source plugins as a root folder. - We don't have the ocl.all feature. - We have an extra (unnecesary while all.sdk doesn't include core.sdk) ocl.core.sdk featuer. - We don't have the lpg.runtime.java.source plugin. After understanding (more or less) the buildExtra.xml file, I think that I can fix all this at once. However I can't be completely sure after committing and running an N-build. Alex told me that we are going to create a RC1a after Xtext RC1, so we are not going have any problem corcening Rampdown polocies May I try to fix all this generated artifacts during today ? Cheers, Adolfo.
(In reply to comment #9) > Well, I'm afraid that we have several problems. Apart from having a confusing > situation about features and generated plugins, I want to do an analysis of the > the problems I perceive when looking at the generated artifacts in the last > S-build and N-build. > > mdt-ocl-runtime-3.0.0RC1: > - We have a missplaced plugins folder with a lpg.runtime.java plugins as a > root folder. > - We don't have the ocl.all feature. > - We have an extra ocl.edit feature. > - We have the extra ocl.edit, ocl.uml.edit and ocl.ecore.edit plugins. > > mdt-ocl-CoreSDK-3.0.0RC1: > - We don't have the ocl.all, ocl.source and ocl.uml.source features. > - We don't have the lpg.runtime.java and lpg.runtime.java.source plugins. > > mdt-ocl-SDK-3.0.0RC1: > - We have a missplaced plugins folder with a lpg.runtime.java and > lpg.runtime.java.source plugins as a root folder. > - We don't have the ocl.all feature. > - We have an extra (unnecesary while all.sdk doesn't include core.sdk) > ocl.core.sdk featuer. > - We don't have the lpg.runtime.java.source plugin. > > After understanding (more or less) the buildExtra.xml file, I think that I can > fix all this at once. However I can't be completely sure after committing and > running an N-build. Alex told me that we are going to create a RC1a after Xtext > RC1, so we are not going have any problem corcening Rampdown polocies > > May I try to fix all this generated artifacts during today ? > > Cheers, > Adolfo. My +1. BTW, apart from core.sdk, other problems have appeared in RC1, e.g the mispalaced LPG plugins...
(In reply to comment #10) > My +1. BTW, apart from core.sdk, other problems have appeared in RC1, e.g the > mispalaced LPG plugins... I mean they first appeared in RC1, M7a was ok...
(In reply to comment #11) > (In reply to comment #10) > > My +1. BTW, apart from core.sdk, other problems have appeared in RC1, e.g the > > mispalaced LPG plugins... > > I mean they first appeared in RC1, M7a was ok... Oh Dear, M7a was 10 days ago and I don't appreciate any change (buildExtra.xml, build.properties, etc) which could have changed this strange behaviour related to that plugin folder as root of the zips. It could be arisen as a side-effect of a non-ocl-related problem ?... Adding nick to see if he has any clue. Meanwhile, I'll try to do some experiments and launch a N-build to see if the remaining artifacts are correctly generated. Adolfo.
After doing some changes and run a N-build, the problems are the following now: mdt-ocl-runtime-3.0.0RC1: 1. We have a missplaced plugins folder with the lpg.runtime.java plugin as a root folder. 2. We don't have the ocl.all feature. mdt-ocl-CoreSDK-3.0.0RC1: 3. We have a missplaced plugins folder with a lpg.runtime.java and lpg.runtime.java.source plugins as a root folder. 4. We don't have the ocl.all feature. 5. We don't have the lpg.runtime.java.source plugin. mdt-ocl-SDK-3.0.0RC1: 6. We have a missplaced plugins folder with a lpg.runtime.java and lpg.runtime.java.source plugins as a root folder. 7. We don't have the ocl.all feature. 8. We have an extra (unnecesary when all.sdk doesn't include core.sdk) ocl.core.sdk feature. 9. We don't have the lpg.runtime.java.source plugin. Some reflexions: a) I believe that when solving the problem 7, the 2 and 4 problems will also be solved. b) Problems 1, 3, 5, 6 and 9, are related. Let's see if nick can help us to discover why those root plugins folders are appearing as a root folder in our zips. c) I still have to discover why 8 is being included in our SDK zip. I'll do more investigations after lunch. Cheers, Adolfo.
Is there a reason why you're concerned w/ multiple zips? Surely a single update site (with several features) is all your users need? I mean, it's not like p2 is new anymore. :)
(In reply to comment #14) > Is there a reason why you're concerned w/ multiple zips? Surely a single update > site (with several features) is all your users need? I mean, it's not like p2 > is new anymore. :) Not sure about that. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=312725#c5 or https://bugs.eclipse.org/bugs/show_bug.cgi?id=310349 or https://bugs.eclipse.org/bugs/show_bug.cgi?id=299168 It seems that clients are still looking for zips. Actually, MDT-OCL downloads web page still provides diferrent links to download the zips (http://www.eclipse.org/modeling/mdt/downloads/?project=ocl). The problem now is that the zips are inconsistent, specially in RC1 in which a plugins folder unexpectedly appears as a root in the zip file. Any help about this issue would be appreciated. Adolfo.
I had a nightmare time getting M7a to build, and resorted tyo unrolling the 6 CVS changes to no effect. The problem was that M7 was built against an Xtext composite repository that was providing some 'useful' M6 material. This should no longer be a problem because all repos are now explicit. However David Williams has announced some pruning of repositories, so maybe something different is being pulled in. Once you get really desperate, roll back all the releng changes to M7a and try a rebuild. Then trim examples to eliminate any possibility that Xtext is causing trouble. Hudson has also been being trimmed to try to solve the 500 error. Adolfo: Welcome to releng world. +1 to as many N-builds as you like. I doubt you can practice releng changes any other way. When you have a solution we can review it.
Hi Adolfo, Ed, During my exercise this night I've found that the observed LPG problem (at least in part) is caused by the structural change in orbit zip. The archive used to contain a root "eclipse" folder, now it doesn't... I've updated buildExtra accordingly, now LPG misplacement issues seem to be resolved. Secondly, I have included ocl.all.sdk to coreSDK and runtime zips. I will check the whether I succeeded tomorrow - going to sleep now)) Regarding issue 8, core.sdk feature is there because it is included into the master feature which is also present in the zip. However, I don't think it is a problem, since it doesn't affect anything.
Seems promising. Nicks' comments on Bug 313244 suggest we can make this a lot simpler for ?Indigo?. If you're now expert on Orbit and buildExtra are you able to change the LPG fetch to use the repo rather than the ZIP thereby avoiding referencing both Orbits in build.properties?
(In reply to comment #17) > Hi Adolfo, Ed, > > During my exercise this night I've found that the observed LPG problem (at > least in part) is caused by the structural change in orbit zip. The archive > used to contain a root "eclipse" folder, now it doesn't... > > I've updated buildExtra accordingly, now LPG misplacement issues seem to be > resolved. Great. Yes, the last artifacts seem to be solved. > > Secondly, I have included ocl.all.sdk to coreSDK and runtime zips. I will check > the whether I succeeded tomorrow - going to sleep now)) Alex this is not correct. I recall on the http://wiki.eclipse.org/MDT/OCL/Dev/Releng/Features_Organization wiki page. AFAIU, the relation between generated ZIPS and our featueres is the following org.eclipse.ocl.all -> Runtime's ZIP (doesnt include ocl.all.sdk) org.eclipse.ocl.core.sdk -> Core SDK's ZIP. (doesnt include ocl.all.sdk) org.eclipse.ocl.master -> SDK's ZIP. (does include ocl.all.sdk) Therefore: - org.eclipse.ocl.all should be used in Runtimes and Core SDKs zip instead of org.eclipse.ocl.all.sdk - the problem is that org.eclipse.ocl.all is not being included into the SDKs zip. I'll try to fix this. > > Regarding issue 8, core.sdk feature is there because it is included into the > master feature which is also present in the zip. However, I don't think it is a > problem, since it doesn't affect anything. Agree, let's forget issue 8. You are right. Updating the list of problems after looking the last generated artifacts: mdt-ocl-runtime-3.0.0RC1: 1. We don't have the org.eclipse.ocl.all feature. 2. We have an extra org.eclipse.ocl.all.sdk feature. mdt-ocl-CoreSDK-3.0.0RC1: 3. We don't have the org.eclipse.ocl.all feature. 4. We have an extra org.eclipse.ocl.all.sdk feature. mdt-ocl-SDK-3.0.0RC1: 5. We don't have the org.eclipse.ocl.all feature. BTW, the blocked https://bugs.eclipse.org/bugs/show_bug.cgi?id=310349 is what has been warning: the org.eclipse.ocl.all feature is missed. It seems that we are close to finish this :) I'm doing some experiments in the buildExtra.xml and running a new build. > > If you're now expert on Orbit and buildExtra are you able to change the LPG > fetch to use the repo rather than the ZIP thereby avoiding referencing both > Orbits in build.properties? Ed, could you give extra information about your experiments ?. I'll look into this, when the zips are finally correct.
(In reply to comment #19) > (In reply to comment #17) > > Secondly, I have included ocl.all.sdk to coreSDK and runtime zips. I will check > > the whether I succeeded tomorrow - going to sleep now)) > > Alex this is not correct. I recall on the > http://wiki.eclipse.org/MDT/OCL/Dev/Releng/Features_Organization wiki page. > AFAIU, the relation between generated ZIPS and our featueres is the following > > org.eclipse.ocl.all -> Runtime's ZIP (doesnt include ocl.all.sdk) > org.eclipse.ocl.core.sdk -> Core SDK's ZIP. (doesnt include ocl.all.sdk) > org.eclipse.ocl.master -> SDK's ZIP. (does include ocl.all.sdk) > > Therefore: > - org.eclipse.ocl.all should be used in Runtimes and Core SDKs zip instead of > org.eclipse.ocl.all.sdk > - the problem is that org.eclipse.ocl.all is not being included into the SDKs > zip. I'll try to fix this. > Oh dear! It was late night - I just confused ocl.all with ocl.all.sdk... Blushes...(In reply to comment #19) > > If you're now expert on Orbit and buildExtra are you able to change the LPG > > fetch to use the repo rather than the ZIP thereby avoiding referencing both > > Orbits in build.properties? > > Ed, could you give extra information about your experiments ?. I'll look into > this, when the zips are finally correct. +1 to Adolfo's experiments with that. However, there's no hurry - we can always suspend this until Indigo. I will look at it too if I have time.
Hi All, Good news. The last introduced changes in buildExtra.xml now introduce the org.eclipse.ocl.all feature in all the ZIPs. If any of you want to check them ;). I'd close this bug as FIXED. Cheers, Adolfo.
I find the changes between buildExtra.xml 1.44 (current) and 1.39 (M7a) surprising given that Anthony likes M7a. From the earlier comments, I would really only expect to see: - change of LPG paths to accommodate Orbit changes - addition of some features and if we are convinced that omission of LPG from some SDKs is a bug: - addition of LPG [I would prefer to leave LPG inclusions as-is, so that the Runtime-ZIP provides it, but the bigger SDKs don't, since the bigger SDKs are part of a larger install that can sort Orbit out for itself.] What I find surprising from a compare of buildExtra.xml 1.44 and 1.39 is: change of ocl.all to ocl.edit feature change of ocl.all.sdk to ocl.all addition of edit plugins This suggests that a detailed compare of the N-build ZIPs will show more differences that we want from the M7a ZIPs. I'm very reluctant to see any changes in the list of plugins and features since M7a fixed the only problem known in M7. ---- My 'experiments' regarding the build were to respond to Nick's help and use testLocal rather than test with overall XVNC and to use repositories rather than 'evil' dropin ZIPs. This was combined with enumerating every indirect Xtext dependency avoiding the confusion from wildcard provision of content from the itemis composite site. These changes were very successful; I haven't seen a build failure for a random inexplicable unrepeatable reason since; such failures used to about 20% of builds. A cross-project-dev posting identified that Orbit also has repository, so this is used by the main build and succeeds nicely, but only detailed examination of the logs showed that there were errors in buildExtra resulting in deficient ZIP contents. The build verdict was SUCCESS for a buildExtra failure. Therefore in buildExtra 1.39 I re-instated the Orbit ZIP, with a comment inviting someone to find out how to change buildExtra.xml to copy LPG across from the repository rather than the ZIP. If we do this it will no longer be necessary to expand the whole of Orbit at the start of each build and each test.
(In reply to comment #22) > What I find surprising from a compare of buildExtra.xml 1.44 and 1.39 is: > change of ocl.all to ocl.edit feature > change of ocl.all.sdk to ocl.all > addition of edit plugins > > This suggests that a detailed compare of the N-build ZIPs will show more > differences that we want from the M7a ZIPs. I'm very reluctant to see any > changes in the list of plugins and features since M7a fixed the only problem > known in M7. Bug 313857: QVTo is broken; clearly RC1 != M7a. Raising to critical. [Xtext RC1 is binary compatible; unfortunately 50% of the xtext tests fail!; I'm glad I didn't incorporate these into the official build tests.]
> > Bug 313857: QVTo is broken; clearly RC1 != M7a. Raising to critical. > > [Xtext RC1 is binary compatible; unfortunately 50% of the xtext tests fail!; > I'm glad I didn't incorporate these into the official build tests Alex, When RC1a is supposed to be published ? We urgently need a consistent RC1. Sergey metioned problems (a root plugins folder in the zip) in RC1 which are solved now. Also remember that RC2 is next week (on monday, isn't it?) (In reply to comment #22) > I find the changes between buildExtra.xml 1.44 (current) and 1.39 (M7a) > surprising given that Anthony likes M7a. When has Anthony liked M7a or any previous one. We have had inconsistent zips from time ago, with several bugzillas reaisen since ... ¿M6?. > > From the earlier comments, I would really only expect to see: > - change of LPG paths to accommodate Orbit changes > - addition of some features > > and if we are convinced that omission of LPG from some SDKs is a bug: > - addition of LPG > > [I would prefer to leave LPG inclusions as-is, so that the Runtime-ZIP provides > it, but the bigger SDKs don't, since the bigger SDKs are part of a larger > install that can sort Orbit out for itself.] > > What I find surprising from a compare of buildExtra.xml 1.44 and 1.39 is: > change of ocl.all to ocl.edit feature > change of ocl.all.sdk to ocl.all > addition of edit plugins > > This suggests that a detailed compare of the N-build ZIPs will show more > differences that we want from the M7a ZIPs. I'm very reluctant to see any > changes in the list of plugins and features since M7a fixed the only problem > known in M7. Comparing ZIPS (M7a and the N one I produced yesterday): SDK Zip: M7a: 12 features and 59 plugins. N: 13 featueres and 59 plugins. Differences: a) N-build has a new org.eclipse.ocl.all feature (solves Bug 310349). SDK-Core Zip: M7a: 1 feature and 6 plugins. N: 6 (consistent) features and 8 plugins Differences: b) N-build has all the features required/included by org.eclipse.ocl.core.sdk and includes the missed LPG plugins (solves this Bug). Runtime ZIP: M7a: 3 features and 7 plugins. N: 3 features and 4 plugins. Differences: c) N-build includes ocl.eclipse.ocl.all (which includes org.eclipse.ocl and org.eclipse.ocl.uml). d) N-buid has removed org.eclipse.ocl.edit feature and removed the 3 edit plugins. My reflexions about this: - a) and b) solves opened bugs. - c) doesn't really solve any raised bug. However it's consistent to include the coordinating feature (http://wiki.eclipse.org/MDT/OCL/Dev/Releng/Features_Organization) and doesn't suppose any impact to anybody. - d) Removing featuere/plugins may cause impact. However, on the one hand Edit is new feature in helios and I believe that nobody could have used our runtime artifact during Helios development (Elipse projects usually use the SDK one). On the other hand, we are being consistent with http://wiki.eclipse.org/MDT/OCL/Dev/Releng/Features_Organization. So, I'd leave the build.xml as is, although I'd accept that you may consider now that the edit support must be part of the runtime (we must to reconsider our feature organization and reverting the changes which produce d). I'm not inclined to do it because I consider that the runtime must only be conformed by the plugins of the oc.eclipse.ocl.all coordinating featuere. Comments ? Adolfo.
> So, I'd leave the build.xml as is, although I'd accept that you may consider > now that the edit support must be part of the runtime (we must to reconsider > our feature organization and reverting the changes which produce d). I'm not > inclined to do it because I consider that the runtime must only be conformed by > the plugins of the oc.eclipse.ocl.all coordinating featuere. BTW, Nobody should disagree when saying that the buildExtra.xml file is very improvable right now. We could also try to fix those Orbit's repos dependencies and such. However, I'm inclined to focus on producing good artifacts for RCs, and wait until Indigo to do it. These days I've checked that this process is not kind: - It's usually based on try an error methods. - Have to wait 40 minutes to check that all went fine (including the generated artifacts) - RCs are weekly, and we shouldn't be making unnecesary changes (which need Kenn's revision as well). Besides, Kenn has recalled that we will have to move to a different building system (use Buckminster ¿?¿), so i think it's not worthy investing more time in this. Let's simply focus on fixing our current problems. Cheers, Adolfo.
(In reply to comment #23) > [Xtext RC1 is binary compatible; unfortunately 50% of the xtext tests fail!; > I'm glad I didn't incorporate these into the official build tests.] Please ignore. The problem was solely in my work-in-progress.
(In reply to comment #24) > > I find the changes between buildExtra.xml 1.44 (current) and 1.39 (M7a) > > surprising given that Anthony likes M7a. > > When has Anthony liked M7a or any previous one. We have had inconsistent zips > from time ago, with several bugzillas reaisen since ... ¿M6?. Anthony's Bugzilla 310349 comment#11 confused me when I first read it. I thought he was reporting a new problem, but actually with the intervening time and changes I interpret: "There is no master feature in mdt-ocl-CoreSDK-3.0.0M7a.zip . This is the backwards compatible zip we are using." to mean. Confirmed: There is no master feature in mdt-ocl-CoreSDK-3.0.0M7a.zip. This is the backwards compatible zip we are using successfully. so my changes to remove spurious content fixed the problem. ----- Why are these simple things so hard? What you have looks pretty good, so I hope that QVTo's problems are caused by the rogue RC1 content fixed in the N-build. > > My reflexions about this: > - a) and b) solves opened bugs. a) I think we can live with the addition of a feature that fixes transitive include dependency. Hardly a major change. Probably an obscure bug fix for someone. (+1) b) Addition of 5 features and 2 LPGs to Core-SDK. This one did not exist in 1.3.0, and the Download page links are broken. I'm not happy about changing, but I think that without the extra bits it's broken, so probably nobody cares. (+1). > - c) doesn't really solve any raised bug. However it's consistent to include > the coordinating feature > (http://wiki.eclipse.org/MDT/OCL/Dev/Releng/Features_Organization) and doesn't > suppose any impact to anybody. True. But the bug was the spurious presence of master (rather than all), so while removing master was necessary, the addition of all is justifiable. (+1) > - d) Removing feature/plugins may cause impact. However, on the one hand > Edit is new feature in helios and I believe that nobody could have used our > runtime artifact during Helios development (Elipse projects usually use the SDK > one). On the other hand, we are being consistent with > http://wiki.eclipse.org/MDT/OCL/Dev/Releng/Features_Organization. This one is a mess. 1.3.0 did not have edit in runtime 3.0.0M6 did Rational organisation does not I think that Ramp Down policies mean we must put edit in runtime to minimise upset. Nobody has complained about this bloat. Someone might complain about the unbloat. Probably nobody cares. (-1).
> Why are these simple things so hard? What you have looks pretty good, so I hope > that QVTo's problems are caused by the rogue RC1 content fixed in the N-build. I also hope so. > > This one is a mess. > > 1.3.0 did not have edit in runtime > 3.0.0M6 did > Rational organisation does not > > I think that Ramp Down policies mean we must put edit in runtime to minimise > upset. Nobody has complained about this bloat. Someone might complain about the > unbloat. Probably nobody cares. (-1). If somebody complains, I guess that Kenn won't have any problem in accepting the inclusiong of the edit feature/plugins into the Runtime again. Something is creaking between our features organization and the different generated zips, but who cares... We'll have a new major release next year, who knows how the build process will turn into,etc ... time to reconsider all this stuff ;P Cheers, Adolfo.
(In reply to comment #28) Ok. +1. I guess that 1.3.0 compatibility is more important since 1.3.0 users won't test till 3.0.0 is out. M6 users will be able to react at RC2. > > > > This one is a mess. > > > > 1.3.0 did not have edit in runtime > > 3.0.0M6 did > > Rational organisation does not > > > > I think that Ramp Down policies mean we must put edit in runtime to minimise > > upset. Nobody has complained about this bloat. Someone might complain about the > > unbloat. Probably nobody cares. (-1). > > If somebody complains, I guess that Kenn won't have any problem in accepting > the inclusiong of the edit feature/plugins into the Runtime again. Something is > creaking between our features organization and the different generated zips, > but who cares... We'll have a new major release next year, who knows how the > build process will turn into,etc ... time to reconsider all this stuff ;P > > Cheers, > Adolfo.
(In reply to comment #29) > (In reply to comment #28) > Ok. +1. I guess that 1.3.0 compatibility is more important since 1.3.0 users > won't test till 3.0.0 is out. M6 users will be able to react at RC2. > So, all in place to build RC1a including Xtext RC1.... Alex's turn Cheers, Adolfo.
Comment on attachment 168723 [details] Fixing patch Marking the patch as obsolete since it doesn't really represents the changes made during the resolution of the bug.
FIXED.
