Bugzilla – Full Text Bug Listing
| Summary: | Helios SR2 repository contains bad version of acceleo | ||
|---|---|---|---|
| Product: | [Modeling] Acceleo | Reporter: | Bouchet Stéphane <sbouchet> |
| Component: | Core | Assignee: | Project Inbox <acceleo-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P3 | CC: | adolfosbh, david_williams, mariot.chauvin, stephane.begaudeau, thomas |
| Version: | 3.0.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Bouchet Stéphane
Fixed with a maximum version limit. Is this one bug the reason that both of these contribution files changed: m2m-atl.b3aggrcon m2t-acceleo.b3aggrcon Also, can you explain a little of the background about how this happened? Any why not caught until now? One addition: - The m2t-acceleo.b3aggrcon file says: <features name="org.eclipse.acceleo.sdk.feature.group" versionRange="[3.0.2,3.1.0]"> The current 3.1.0.v201008170310 is not picked because it's greater than 3.1.0. In any case I'd exclude 3.1.0 version to avoid confussions. Best Regards, Adolfo (In reply to comment #2) > Is this one bug the reason that both of these contribution files changed: > > m2m-atl.b3aggrcon > m2t-acceleo.b3aggrcon > > Also, can you explain a little of the background about how this happened? Any > why not caught until now? yep, the same behavior has been detected for ATL, too. This error comes from the JET contribution that changed its own repository from http://download.eclipse.org/modeling/m2t/updates/interim/ to http://download.eclipse.org/modeling/m2t/updates/milestones a month ago. Acceleo 3.1.0 used this last one for indigo M1 and this is why it was picked up by the agregator. We did not verify the aggregated repository until now, that is why we request a respin for the agregation repository. ( BTW, ATL is not impacted at all and provide the good SR2 bits ) (In reply to comment #3) > One addition: > > - The m2t-acceleo.b3aggrcon file says: > > <features name="org.eclipse.acceleo.sdk.feature.group" > versionRange="[3.0.2,3.1.0]"> > > The current 3.1.0.v201008170310 is not picked because it's greater than > 3.1.0. In any case I'd exclude 3.1.0 version to avoid confussions. > > Best Regards, > Adolfo Adolfo, you are looking the patched aggregation file, the previous one ( used to create the final repo ) did not contains a maximum version and 3.1.0 was picked up. (In reply to comment #5) > (In reply to comment #3) > > One addition: > > > > - The m2t-acceleo.b3aggrcon file says: > > > > <features name="org.eclipse.acceleo.sdk.feature.group" > > versionRange="[3.0.2,3.1.0]"> > > > > The current 3.1.0.v201008170310 is not picked because it's greater than > > 3.1.0. In any case I'd exclude 3.1.0 version to avoid confussions. > > > > Best Regards, > > Adolfo > > Adolfo, > you are looking the patched aggregation file, the previous one ( used to create > the final repo ) did not contains a maximum version and 3.1.0 was picked up. Apologies for not being clear enough: Although the current version range configuration works, I'm only suggesting that you could set "[3.0.2,3.1.0)" rather than "[3.0.2, 3.1.0]". I'm also starting to use this version range style with my component (in Indigo, obvisously). This bugzilla and playing with the b3 editor have made me realize that I can improve my b3aggrcon file to avoid making changes with each milestone... Cheers, Adolfo. (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > > One addition: > > > > > > - The m2t-acceleo.b3aggrcon file says: > > > > > > <features name="org.eclipse.acceleo.sdk.feature.group" > > > versionRange="[3.0.2,3.1.0]"> > > > > > > The current 3.1.0.v201008170310 is not picked because it's greater than > > > 3.1.0. In any case I'd exclude 3.1.0 version to avoid confussions. > > > > > > Best Regards, > > > Adolfo > > > > Adolfo, > > you are looking the patched aggregation file, the previous one ( used to create > > the final repo ) did not contains a maximum version and 3.1.0 was picked up. > > Apologies for not being clear enough: > > Although the current version range configuration works, I'm only suggesting > that you could set "[3.0.2,3.1.0)" rather than "[3.0.2, 3.1.0]". Wooops, you are right. by doing this, we will exclude all 3.1.0 and next releases founded in provided repo, and actually it only remove the 3.1.0 version founded. > > I'm also starting to use this version range style with my component (in Indigo, > obvisously). yes, this is a very good idea :D > > This bugzilla and playing with the b3 editor have made me realize that I can > improve my b3aggrcon file to avoid making changes with each milestone... that is exactly what we wanted to do. fixing a range to this file and only change the repo used ( from milestones to releases ), and let p2 pick the good version. i hope our mistake will help you to not do the same ;) > > Cheers, > Adolfo. Adding Thomas for comment/review ... I'm not aware of two many who use the [...) form of specifying ranges, and am a little afraid it makes the end result sort of indeterminate. If this is just an easy short hand way of specifying it, that's fine ... just wanted to be sure we weren't replicating that problem if people specify range in a feature.xml "include" statement. Probably not ... just checking. In my opinion, using a [...) range is ideal. A contributor can specify this type of range prior to the first release so that it limits subsequent aggregations according to the rules specified for the service packs (no major or minor changes, just bugfixes). That way, there's no need to change the aggrcon file for each new service pack (or release candidate for that matter). Just publish the bugfix to your contributed repository and you're all set. (In reply to comment #9) > In my opinion, using a [...) range is ideal. A contributor can specify this > type of range prior to the first release so that it limits subsequent > aggregations according to the rules specified for the service packs (no major > or minor changes, just bugfixes). That way, there's no need to change the > aggrcon file for each new service pack (or release candidate for that matter). > Just publish the bugfix to your contributed repository and you're all set. That does sound ideal in some ways ... as long as the resulting metadata in repo ends up saying the same thing .... "this IU includes this one exact version" (which it probably does ... just checking that the content and artifact metadata ends up the same as it would if an exact version was specified). Plus, seems to be a little more danger if someone said they were contributing [3.0.2,3.1.0) and someone else (mistakenly?) said they required version [3.0.2,3.0.9) then two (or wrong?) version would silently end up in repo, with no error message given? (mid-air collision) mmm... I see another minor inconvenience. How does the aggregator build realize that some content in an interested repository changed ? Usually, these minor version-range adjustments which needed a commit were the stater of the job. I guess that there is no way to make hudson realize that the content of a p2 repo has changed... ... Another idea is switching to periodic builds... but giving that the builds are not very quick, I'm not sure if this is really ideal >.< Cheers, Adolfo. (In reply to comment #10) > (In reply to comment #9) > Plus, seems to be a little more danger if someone said they were contributing > [3.0.2,3.1.0) and someone else (mistakenly?) said they required version > [3.0.2,3.0.9) then two (or wrong?) version would silently end up in repo, with > no error message given? The b3 aggregator would find a working solution where only one version is included. If that's considered incorrect, then yes. That would be a problem. We (Buckminster) would never encounter this problem since we never keep old stuff around in our contributed repository. Our train contribution contains exactly what our last build produced, no old stuff lingering. Also please note that this problem is not just confined to features and contributions. It pertains to all bundles that one way or another is specified as requirements and not inclusions. I guess most Orbit bundles are specified that way for instance, since they are not "owned" by any of the contributors. (In reply to comment #11) > ... Another idea is switching to periodic builds... but giving that the builds > are not very quick, I'm not sure if this is really ideal >.< > Periodic builds strikes me as a good idea. I've always thought that running this mega-build more than twice a day seems a bit excessive. |