Community
Participate
Working Groups
After installing the Eclipse SDK 4.3.1 into a minimal Eclipse 4.3.1 the splash screen shows 4.3.0 as version. This is confusing. Steps to reproduce: 1) download, unzip and start "Platform Runtime Binary" from http://download.eclipse.org/eclipse/downloads/drops4/R-4.3.1-201309111000/ 2) install Eclipse SDK 3) restart 3) see splash screen -> shows 4.3.0.M20130911-1000 as version
Need to investigate still ... not sure what would cause this, but if still an issue, should try to fix for Kepler SR2. I'll try to reproduce.
CCing a few of the seasoned veterans, to ask some questions to: 1: Do you happen to know where the version in the splash screen comes from? (The version in the about box is correct). 2: Any chance were we supposed to remove that, when we started putting the word "Kepler" (or "Luna") on the splash screen? I ask the latter since I don't see it at all on on my Linux machine, and I see it flash up only briefly on my Windows machine (did not try Mac) ... and on Windows, the first part is truncated (I may have large fonts) but ends up looking like ".3.0.Mxxxxxx" instead of "4.3.0.Mxxxxxx". But, I did confirm the effect, on Windows. But the originator, Michael, either has very good eyes ... or a slow machine :) And, for the first question, I've looked all over the source code, and found only one spot that mentions "4.3.0", and that's the .eclipseproduct in root of Eclipse Platform (Eclipse SDK does not have a root folder ... I guess supposed to reuse the one from "Platform"?) BUT, if I look at what's actually built, it is "all over the place", in p2 metadata "setProperty ... buildId ... " which then, I guess only on "update"? ends up in the configuration area? So, its kind of confusing. I can "experiment", correcting that one .eclipseproduct file to see if that fixes what's "built", but I'm just surprised that that one thing would have such a specialized effect, and that it would still show the correct value on a fresh install. My worst fear is that Tycho "infers" the value from the "artifact id" ... which would mean a larger change ... but, we'll cross that bridge after we get to it. I was just wondering if it happened to come from the executable fragments, or something? If anyone knows off the top of their head.
Created attachment 239035 [details] output of 'grep' on fresh M-build (in 'tychobuild' folder). This grep illustrates what I mean by "4.3.0" appearing "all over the place, in what is built.
I did update .eclipseproduct to have version=4.3.2 ... but that didn't have any effect on built artifacts (but ... should still be updated, IMHO). I understand this pretty well now ... but, not sure of the best way to fix ... or, maybe doesn't matter and we can just pick any of the possibilities. What's going on: The platform.product file, and the sdk.product file, define the "configuration" property as follows: <property name="eclipse.buildId" value="${unqualifiedVersion}.${buildQualifier}" /> For example in context, see http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder/platform/platform.product#n174 As far as I can see, these are the only two "products" that define eclipse.buildId in their configuration. Now, the complicated part: ${unqualifiedVersion} is a "Tycho" variable, in this context, and according to http://eclipse.org/tycho/sitedocs/tycho-packaging-plugin/plugin-info.html <quote> Unqualified project version is assigned to unqualifiedVersion project property. Unqualified version is calculated based on ${project.version} and can be used for any Tycho project (eclipse-update-site, eclipse-application, etc) and regular maven project. </quote> Since we never set the value of "unqualifiedVersion" (nor "project.version") I think this means it simply takes the "artifactId" ... which we've "left" as 4.3.0 throughout, for convenience. So, alternatives: 1. change <property name="eclipse.buildId" value="${unqualifiedVersion}.${buildQualifier}" /> to <property name="eclipse.buildId" value="${buildId}" /> 2. change the "artifact id" of our "products" to be accurate, "4.3.2", instead of "4.3.0". I sort of prefer this approach, since it is more accurate "from a maven point of view", and since we might also have to do that for our main "repository artifact" (i.e. there may be some "hidden" uses of "unqualifiedVersion"), judging from the content.xml files. But, this change might effect others, who "depend on" eclipse product? ... if there is such a thing (i.e. they might depend on hard coded "4.3.0"? I think as long as we do not change the "parent pom" artifact ID, there would be no "ripple effect" ... (which was the reason we were reluctant to do it, to begin with.). 3. It sounds like, from the URL above, for tycho-packaging-plugin, there is some way to "configure" this value ... but seems to be no good example, and I think that's mostly for configuring "qualifier" part, not unqualified part.
Thanh, I don't know if you wrote the original "product definitions" to use <property name="eclipse.buildId" value="${unqualifiedVersion}.${buildQualifier}" /> but wondering if you have any advice on which of the three alternatives to use ... or, if there are other alternatives I don't "see". Thanks. If no one has any other thoughts, I'll start "slowly", and change artifacts IDs of the two "products" first ... and see if that, miraculously, takes care of everything? (And if not, just try a few more artifact IDs here and there ... as long as none of them serve as "parents" to any of our other artifacts.
Created attachment 239063 [details] patch to change select (repository) artifact IDs to "4.3.2" In my test runs, it seems that changing artifact ID of select artifacts to "version 4.3.2" suffices to get the "setProperty" in the meta data to correctly set "4.3.2". I decided to change each of the places in "aggregator" where the artifact is of type "eclipse-repository". I'm not sure each of them is immediately required, but seemed like a "best practice". For example, <artifactId>org.eclipse.rcp.id</artifactId> <version>4.3.2-SNAPSHOT</version> <packaging>eclipse-repository</packaging> You can see in the patch, that the "eclipse-junit-tests.product" did not have any version specified ... but, from what I've read, every artifact should have one ... so ... I see no harm in fully specifying each. Unless better ideas come forward, I'll commit this post RC1, so by RC2 it should show up as changed. If anyone knows of any side effects of this eclipse.buildId, in the config.ini file, please point them out. I'm assuming for now its just use as a simple label, and does not play a central role in "updates" or "reverts". I notice in the "unconfigure" action, it's set to "nothing", so testing "revert" might be worthwhile, to make sure nothing odd happens ... but if it did, seems like that would have been a separate issue we'd have anyway.
(In reply to David Williams from comment #5) > Thanh, I don't know if you wrote the original "product definitions" to use > No it was already there before I started on the project. (In reply to David Williams from comment #6) > Created attachment 239063 [details] > patch to change select (repository) artifact IDs to "4.3.2" This patch should fix the issue. The "unqualified" number comes from the version field in the pom.xml in the same directory. If we want to save some duplication we can also omit the pom.xml's artifact Version and it will inherit the one between the <parent></parent> tags. For example: <parent> <groupId>eclipse.platform.releng.tychoeclipsebuilder</groupId> <artifactId>eclipse.platform.releng.tychoeclipsebuilder</artifactId> <version>4.4.0-SNAPSHOT</version> </parent> <artifactId>org.eclipse.sdk.ide</artifactId> <packaging>eclipse-repository</packaging> In this case since the groupID is also omitted it also inherits the groupId too.
Adding Ian and Pascal to CC, since if anyone should know of side effect of eclipse.buildId in config.ini during updates or reverts, it should be them. As an aside, it appears that the value is wrong in initial materialized product as well ... not sure how "4.3.1" was displayed in original case ... so still many Tycho mysteries. = = = = = Thanks for the comments Thanh. I think I'll leave separately defined for now. I'm not actually positive they should always be exactly the same ... though admit in practice they probably will be for a long time to come.
Main fix committed with http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_3_maintenance&id=01fc682907bcdb64bd397311fe8305fd1666acea Then decided to leave a nice wording comment on one instance: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_3_maintenance&id=c316961bf4bb11d3c629baeb80615c7c133f1b29 Should be ready to verify/test with next week's M-build. (1/22 ... unless we decide to rebuild again :/
(In reply to David Williams from comment #9) > Main fix committed with > > http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/ > commit/?h=R4_3_maintenance&id=01fc682907bcdb64bd397311fe8305fd1666acea > > Then decided to leave a nice wording comment on one instance: > > http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/ > commit/?h=R4_3_maintenance&id=c316961bf4bb11d3c629baeb80615c7c133f1b29 > > Should be ready to verify/test with next week's M-build. (1/22 ... unless we > decide to rebuild again :/ This fix may be involved with build failure of http://download.eclipse.org/eclipse/downloads/drops4/M20140116-1730/ Even though it "worked locally" ... it might interact bug 425922 since this fix was in "poms only", the artifacts in "tycho builder" may have to be "touched" to change qualifiers? (Even though they are all sort of "technical" artifacts, not really delivered.) I'd like to try touching each artifact, and if that doesn't work, will revert this whole set, until bug 425922 is resolved.
(In reply to David Williams from comment #10) > This fix may be involved with build failure of > http://download.eclipse.org/eclipse/downloads/drops4/M20140116-1730/ > I'm seeing this in the logs "Installation of product org.eclipse.platform.sdk for environment hpux/gtk/ia64 failed" but I'm not sure what's causing it.
(In reply to Thanh Ha from comment #11) > (In reply to David Williams from comment #10) > > This fix may be involved with build failure of > > http://download.eclipse.org/eclipse/downloads/drops4/M20140116-1730/ > > > > I'm seeing this in the logs "Installation of product > org.eclipse.platform.sdk for environment hpux/gtk/ia64 failed" but I'm not > sure what's causing it. My theory comes from the previous build, actually, because besides the comparator errors showing the launcher fragments needed to be touched ... http://download.eclipse.org/eclipse/downloads/drops4/M20140116-0900/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt also shows some funky stuff with that funky "rcp.config" feature we have: 21. eclipse.platform.releng.tychoeclipsebuilder/rcp.config classifier-root.gtk.linux.x86_64: different eclipse: different classifier-root.gtk.linux.s390x: different eclipse: different classifier-root.gtk.aix.ppc64: different eclipse: different classifier-root.gtk.linux.s390: different eclipse: different classifier-root.gtk.linux.ppc64: different eclipse: different classifier-root.gtk.hpux.ia64: different eclipse: different classifier-root.gtk.linux.x86: different eclipse: different classifier-root.gtk.linux.ppc: different eclipse: different classifier-root.gtk.aix.ppc: different eclipse: different classifier-root.gtk.solaris.x86: different eclipse: different classifier-root.gtk.solaris.sparc: different eclipse: different no-classifier: different META-INF/ECLIPSE_.RSA: different The main artifact has been replaced with the baseline version. The following attached artifacts have been replaced with the baseline version: [root.gtk.linux.x86_64, root.gtk.linux.s390x, root.win32.win32.x86_64, root.cocoa.macosx.x86, root.gtk.aix.ppc64, root.gtk.linux.s390, root.gtk.linux.ppc64, root.gtk.hpux.ia64, root.gtk.linux.x86, root.gtk.linux.ppc, root.gtk.aix.ppc, root.gtk.solaris.x86, root.win32.win32.x86, root.gtk.solaris.sparc, root.cocoa.macosx.x86_64] So ... I don't think we always have to touch that feature, when the fragments change ... but, I'm wondering if "both changes at once" is throwing (the "products", changing artifact ID versions, and the fragments also changing? Kind of a long shot, but I think easy enough to test. Its not easy to find, in the 350 MB log, but that message is is in the "failed build" log too ... [INFO] Artifact comparison detailed log directory /opt/public/eclipse/builds/4M/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.releng.tychoeclipsebuilder/rcp.config/target/artifactcomparison [WARNING] MavenProject: org.eclipse.rcp.configuration:org.eclipse.rcp.configuration:1.0.0-SNAPSHOT @ /opt/public/eclipse/builds/4M/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.releng.tychoeclipsebuilder/rcp.config/pom.xml: baseline and build artifacts have same version but different contents classifier-root.gtk.linux.x86_64: different eclipse: different classifier-root.gtk.linux.s390x: different eclipse: different .... I suspect we should "disable" that comparison/swap operation for this "configuration feature" ... doesn't really make sense, for it (or, any of the other "tycho builder artifacts").
I've restored the fixes made before the other issues with "executables" last week. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_3_maintenance&id=60c941ae96976d0b5325059127701410afd1fd27 Before I 'touch' rcp.config, I'll do a test build, and see if it shows up with errors in comparator log ... or if that was an issue with executables problem.
(In reply to David Williams from comment #13) > I've restored the fixes made before the other issues with "executables" last > week. > > http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/ > commit/?h=R4_3_maintenance&id=60c941ae96976d0b5325059127701410afd1fd27 > > Before I 'touch' rcp.config, I'll do a test build, and see if it shows up > with errors in comparator log ... or if that was an issue with executables > problem. In my test build, there was no issue with "rcp.config", but there was one oddity in comparator log ... not sure exactly why this happens ... I'll have to study it ... but doesn't cause me concern, since, off-hand, looks to be more of a "false alarm" than anything of substance. 7. rt.equinox.framework/features/org.eclipse.equinox.executable.feature no-classifier: different META-INF/ECLIPSE_.RSA: present in baseline only META-INF/ECLIPSE_.SF: present in baseline only build.properties: present in baseline only build.xml: present in baseline only The main artifact has been replaced with the baseline version. The following attached artifacts have been replaced with the baseline version: [root.gtk.linux.x86_64, root.gtk.linux.s390x, root.win32.win32.x86_64, root.cocoa.macosx.x86, root.gtk.aix.ppc64, root.gtk.linux.s390, root.gtk.linux.ppc64, root.gtk.hpux.ia64, root.gtk.linux.x86, root.gtk.linux.ppc, root.gtk.aix.ppc, root.gtk.solaris.x86, root.win32.win32.x86, root.gtk.solaris.sparc, root.cocoa.macosx.x86_64]
(In reply to David Williams from comment #2) > I ask the latter since I don't see it at all on on my Linux machine, and I > see it flash up only briefly on my Windows machine (did not try Mac) ... and > on Windows, the first part is truncated (I may have large fonts) but ends up > looking like ".3.0.Mxxxxxx" instead of "4.3.0.Mxxxxxx". But, I did confirm > the effect, on Windows. But the originator, Michael, either has very good > eyes ... or a slow machine :) They say confession is good for the soul ... so wanted to admit ... the "time visible" is largely a function of how large a workspace you are opening. In my initial checks, they were empty workspace and did just fly by, faster than my ability to see them. But, once I started using on "real" workspaces, it is visible a long long time ... some of my workspaces take 10 or 20 seconds to load, and in those cases, it is very prominent, which makes it a much worse (and embarrassing) problem. I just didn't want to leave anyone with the wrong impression. Thanks again for the report. I would have likely never noticed it, since I nearly always run with splash screen off. Thanks!
Verified in M20140129-0800.
