Bugzilla – Full Text Bug Listing
| Summary: | Unable to get baseline version for some bundles | ||
|---|---|---|---|
| Product: | Community | Reporter: | Sravan Kumar Lakkimsetti <sravankumarl> |
| Component: | Servers | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P3 | CC: | akurtakov, daniel_megert, frederic.gurr, mikael.barbero, webmaster |
| Version: | unspecified | ||
| Target Milestone: | 2017-Q3 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 520876 | ||
|
Description
Sravan Kumar Lakkimsetti
> This caused by failure to replace newly built artifact with the old one when there are no changes.
In other words: for the affected bundles, the bundle version (qualifier) will be increased even if there was no change since the baseline. As a result, we will have to increase the service segment for those bundles to avoid false-positives in the version problem reports.
For now, we stopped our M-builds to avoid corrupting those too.
Fred restarted Nexus and we started a new build to see whether the problem got fixed. Has the problem been fixed? (In reply to Frederic Gurr from comment #3) > Has the problem been fixed? I think there was never a problem and the log entry is just misleading. I analyzed other builds, including R4.7 and it looks like [INFO] No baseline version MavenProject: is also issued for bundles that have a change compared to the previous build and hence a new qualifier is mandated. I could not find a case where I can see an actual problem. Sravan, you raised the bug. Please provide a concrete example where 1. It is not a feature 2. It is not a feature branding bundle 3. It does not have a change compared to the previous build Here is the problematic log http://download.eclipse.org/eclipse/downloads/drops4/U20170810-0400/buildlogs/mb060_run-maven-build_output.txt In this log you can see the line 732139 we are getting a maven baseline for org.eclipse.e4.feature:org.eclipse.e4.rcp which is a feature. This should not have happened. This caused Maven resolution to fail. With Nexus reset this problem got resolved. Here is the log where you don't see the comparison with baseline http://download.eclipse.org/eclipse/downloads/drops4/U20170814-0705/buildlogs/mb060_run-maven-build_output.txt Nexus reset definitely helped. You can mark it fixed (In reply to Sravan Kumar Lakkimsetti from comment #5) > Here is the problematic log > > http://download.eclipse.org/eclipse/downloads/drops4/U20170810-0400/buildlogs/mb060_run-maven-build_output.txt The U-builds are somewhat special. Did you see a/the problem in one of our I-builds? If so, which bundle was affected? I did not have a problem on the I-build. U-build is almost same as M-build with two bundles from different branch. Other than the jdt.ui and jdt feature we don't have a any other difference. I'm going through I-builds reports and fixing bundles that need bumps. No instance of the issue so far but at least tomorrow's report should have less qualifier updates to check. (In reply to Alexander Kurtakov from comment #8) > I'm going through I-builds reports and fixing bundles that need bumps. No > instance of the issue so far but at least tomorrow's report should have less > qualifier updates to check. I think we can mark this one fixed. I'll try to also upgrade the features and branding bundles for the next I-build. (In reply to Dani Megert from comment #9) > I'll try to also upgrade the features and branding bundles for the next I-build. Should be fine except for Equinox. I come a day after the fair, but please note that the baseline is never retrieved from a Maven repo (i.e., Nexus) but from a p2 repo hosted on a http server (download.eclipse.org in this case). Moving to community/servers to better reflect that. |