Community
Participate
Working Groups
IIRC org.eclipse.swt does not have any classes, but all classes are provided through the respective native fragments. Therefor SWT will not work unless a native fragment is present. Nevertheless, bundles which use SWT only require the bundle org.eclipse.swt. This leads to problems when installing the user bundle with p2: p2 will satisfy the dependency from the user bundle to org.eclipse.swt, but since there is no dependency to the fragments, p2 will not install the fragments. To solve this problem, org.eclipse.swt should have install-time dependencies (i.e. p2 dependencies) to its fragments. These dependencies need to be annotated with a filter so that only the applicable fragment is installed. Currently, the workaround is to make sure the Eclipse RCP feature is also installed. This may be reasonable for people using SWT, but it is cumbersome and hard to understand if SWT only shows up in the transitive dependency chain of your project. Also, not only installation with p2 is affected, but also all other tools which use the p2 planner (target definition files, the Tycho test runtime, etc.). All theses tools need to hack around this problem in the p2 metadata of org.eclipse.swt. I would prefer, if SWT could fix the root cause of this problem. I can provide the p2.inf file in order to amend the compile-time dependencies, if you are willing to adopt it in the SWT build.
To be frank, I do not know what has to be done to fix this problem. Please go ahead in provide the p2.inf file.
Created attachment 208539 [details] 361901 Ensure installation of fragments of org.eclipse.swt Patch in git format (for @git am@). Doesn't work with "Team > Apply Patch...", sorry, but if needed, it shouldn't be hard to apply the patch manually: It just adds content at the end of bundles/org.eclipse.swt/META-INF/p2.inf.
Created attachment 208540 [details] 361901 Tools to generate p2.inf of org.eclipse.swt These are the XSLTs I used to generate the p2.inf content. You are welcome to add them to the project, too. The usefulness depends on where you want to maintain the master list of native fragments. If the feature org.eclipse.swt is the master, you can re-generate the p2.inf for org.eclipse.swt with these transformations. If you want to maintain the p2.inf directly (which should also be doable), you probably don't need them.
Happy New Year to everyone! (In reply to comment #2) > Created attachment 208539 [details] > 361901 Ensure installation of fragments of org.eclipse.swt Do you still have questions about the proposed patch?
As per reasons described in the bug 380934, the org.eclipse.swt bundle should never contain any kind of dependency to the fragments, as it will introduce cycles.
(In reply to comment #5) > As per reasons described in the bug 380934, the org.eclipse.swt bundle should > never contain any kind of dependency to the fragments, as it will introduce > cycles. You are trading off SWT-internal build problems with usability of the results. It should be obvious which one should be in the focus of dev team.
But that's the nature of fragments. They're not designed to have a dependency from the bundle to the fragment (they're the ultimate optional IU). Instead a feature (or equivalent p2 IU group/container) specifies the need to include the fragments when including the org.eclipse.swt bundle. That's the way this was designed to work. If it's not meeting some of the current usecases, I'd like to see this problem properly understood and a better solution proposed. PW
(In reply to comment #7) > But that's the nature of fragments. They're not designed to have a dependency > from the bundle to the fragment (they're the ultimate optional IU). This may be true for other fragments, but AFAIK the SWT fragments are not optional. > Instead a feature (or equivalent p2 IU group/container) specifies the need to > include the fragments when including the org.eclipse.swt bundle. That's the way > this was designed to work. This was okay as long as installations were feature-based. But this is no longer true with p2, where dependencies are resolved on bundle/package level. In that concern, the p2 metadata of org.eclipse.swt is broken: it claims to export certain packages, but doesn't ensure they are really there at runtime. There is a simple fix: Add OS-dependent install-time (=p2) dependencies from the host to the fragments (see patch). Then SWT will always be correctly installed by p2, without requiring the SWT users to manually provide the implicit dependencies. > If it's not meeting some of the current usecases, I'd like to see this problem > properly understood and a better solution proposed. More questions?
(In reply to comment #8) > This may be true for other fragments, but AFAIK the SWT fragments are not > optional. Well, they're not optional in the sense that org.eclipse.swt doesn't do anything without them. > > There is a simple fix: Add OS-dependent install-time (=p2) dependencies from > the host to the fragments (see patch). Then SWT will always be correctly > installed by p2, without requiring the SWT users to manually provide the > implicit dependencies. > > More questions? yes ... Will adding a cyclical dependency prevent maven/tycho from building SWT and one of its fragments (including native source)? Or prevent maven/tycho from building all of the SWT fragments in one build (CBI build of the platform is what I'm thinking of)? Will having the the cyclical dependency not cause problem to other consumers? Or is the cyclical dependency the solution to building and installing the SWT plugin and its fragments? Why can't another swt IU be created that groups SWT and its fragments (thus avoiding a cyclical dependency)? PW
(In reply to comment #9) > Will adding a cyclical dependency prevent maven/tycho from building SWT and one > of its fragments (including native source)? Or prevent maven/tycho from > building all of the SWT fragments in one build (CBI build of the platform is > what I'm thinking of)? I'm taking this question to the "how to build" bug 375715. > Will having the the cyclical dependency not cause problem to other consumers? As far as I know the p2 code (e.g. org.eclipse.equinox.internal.p2.director.Slicer), p2 takes special care not to run into endless loops in case of cyclic dependencies. The equinox runtime is not affected because there is no change on OSGi level. > Or is the cyclical dependency the solution to building and installing the SWT > plugin and its fragments? Not sure I understand this question. > Why can't another swt IU be created that groups SWT and its fragments (thus > avoiding a cyclical dependency)? Interesting idea! This may in fact also work: 1. Rename org.eclipse.swt to something else, e.g. "org.eclipse.swt.host" 2. Point the fragments to that bundle 3. Introduce a new org.eclipse.swt with a Require-Bundle: org.eclipse.swt.host;visibility:=reexport, and add the extra p2 dependencies to the fragments from that bundle. Note that for building this with Tycho, Tycho may need to disable its "fixSWT" method - but we want to do this (which is why I opened this bug). We can't remove the method entirely (because that would break Tycho for older SWT versions), so I'd need to know which version of SWT is expected to have this bug fixed.
(In reply to comment #9) > Will adding a cyclical dependency prevent maven/tycho from building SWT and one > of its fragments (including native source)? Or prevent maven/tycho from > building all of the SWT fragments in one build (CBI build of the platform is > what I'm thinking of)? Currently, this would fail the build because Tycho considers all install-time dependency as build-time dependency. Tycho should have the option to specify extra install-time-only dependencies. In the meantime, you could yield the same effect with the following workaround: Make sure that the p2.inf with the install-time-only dependencies (i.e. from the host to the fragments) is not present at the beginning of the build, bug added before the package phase. Then, there should be no "cyclic dependency error" but the final result should have the correct, extra p2 dependencies.
(In reply to comment #10) > Note that for building this with Tycho, Tycho may need to disable its "fixSWT" > method - but we want to do this (which is why I opened this bug). We can't > remove the method entirely (because that would break Tycho for older SWT > versions), so I'd need to know which version of SWT is expected to have this bug > fixed. Disregard this comment - this problem has been hacked away (bug 380934).
(In reply to comment #10) > (In reply to comment #9) > > Why can't another swt IU be created that groups SWT and its fragments (thus > > avoiding a cyclical dependency)? > Interesting idea! This may in fact also work: > 1. Rename org.eclipse.swt to something else, e.g. "org.eclipse.swt.host" > 2. Point the fragments to that bundle > 3. Introduce a new org.eclipse.swt with a Require-Bundle: > org.eclipse.swt.host;visibility:=reexport, and add the extra p2 dependencies to > the fragments from that bundle. Wait, this wouldn't work in case people use Import-Package of the SWT packages, because they would directly get resolved against org.eclipse.swt.host by p2. OSGi would have the possibility to prevent this (through mandatory attributes), but p2 doesn't support this yet (bug 360659). This leaves comment 11 as the most promising option.
I suspect this is the root of problems I've seen in PDE when a target platform includes multiple SWT platform fragments; often times when apply such a target platform to a workspace, PDE gets confused and thinks it can't resolve any SWT classes for plugins in the workspace that declare dependency on org.eclipse.swt. Although I wasn't able to produce a small demo workspace and .target file, I've encountered this problem many times on every version of Eclipse SDK from 3.4 to 3.8. Now I'm using Tycho and I'm running into the manifestation of this described in this bug. I see no activity for more than 7 months - can we please not let this rot on the vine? I know the Tycho team is actively trying to work around the problem, but the gist is that you can NOT build an app with Tycho if any Babel fragments are in the target platform (bug 391011). Needless to say, that's a show-stopper for just about any RCP app.
(In reply to comment #11) > Currently, this would fail the build because Tycho considers all install-time > dependency as build-time dependency. Tycho should have the option to specify > extra install-time-only dependencies. I'll try to add a feature in Tycho to support install-time only dependencies. The plan is to do this by setting "profile properties" (i.e. the properties used to evaluate filters in p2 metadata) during dependency resolution (see bug 391283). The dependencies from the host to the fragments then will need an additional condition in its filter that allows to disable the host to fragment dependency at build time. Such a filter would then for example look like this: (&(osgi.os=win32)(osgi.ws=win32)(osgi.arch=x86_64)(!(org.eclipse.swt.buildtime=true)))
(In reply to comment #15) > The plan is to do this by setting "profile properties" (i.e. the properties used > to evaluate filters in p2 metadata) during dependency resolution (see bug > 391283). More specific Tycho bug for this feature: bug 405440.
Created attachment 229969 [details] Patch: Ensure installation of fragments of org.eclipse.swt
Created attachment 229970 [details] Patch: Tools to generate p2.inf of org.eclipse.swt
(In reply to comment #17) > Created attachment 229969 [details] > Patch: Ensure installation of fragments of org.eclipse.swt This patch (suitable for "git am") adds a p2.inf to org.eclipse.swt that adds the missing install-time dependencies to the fragments. It also makes sure that the integration into the Tycho build works. Note: For this change to work, the platform CBI build needs to switch to Tycho 0.18.0, which contains a new feature that I have just added (bug 405440). To try out the change locally, call the build with -Dtycho.version=0.18.0-SNAPSHOT -Dtycho-extras.version=0.18.0-SNAPSHOT -D -Declipse-sdk-repo.url=http://download.eclipse.org/eclipse/updates/4.3milestones
(In reply to comment #7) > But that's the nature of fragments. They're not designed to have a > dependency from the bundle to the fragment (they're the ultimate optional > IU). > > Instead a feature (or equivalent p2 IU group/container) specifies the need > to include the fragments when including the org.eclipse.swt bundle. That's > the way this was designed to work. > > If it's not meeting some of the current usecases, I'd like to see this > problem properly understood and a better solution proposed. My attention was drawn to this bug by a Stackoverflow question. I have no interest/knowledge in p2, but from a "pure" OSGi perspective this can be easily solved with the Provide/Require-Capability headers that were added in OSGi R4.3 (which has been supported since Equinox Indigo or thereabouts). First, the base SWT bundle simply cannot work without one of the native fragments... so the fragment is not really optional at all! The problem is that we cannot specify in advance which particular fragment, because it depends on the runtime platform. So you could create a capability namespace, say 'org.eclipse.swt.native' that is required by the base SWT bundle: Require-Capability: org.eclipse.swt.native; filter:="(version>=x.x.x)" Then *each* of the SWT native fragments provide the same capability: Provide-Capability: org.eclipse.swt.native; version:Version=x.x.x Now the OSGi resolver -- and other resolvers such as p2, assuming it understands these headers -- can work out that it must supply one of the fragments, and the other constraints on the fragments (such as the platform filter) ensure that only the correct one for the platform is chosen.
(In reply to comment #20) Hey Neil, The problem is more complex than that. Adding (in)direct requirements from swt main bundle to swt fragments creates dependency cycle (because of the indirect dependency from swt fragments to swt main bundle) which is a very painful, because it breaks platform build. To fix this bug properly it would be required to make swt fragments provide a namespace (as you said) but instead of changing swt main bundle, it would be necessary to change every swt client to require swt namespace. But that breaks compatibility...
(In reply to comment #21) > Adding (in)direct requirements from swt > main bundle to swt fragments creates dependency cycle (because of the indirect > dependency from swt fragments to swt main bundle) which is a very painful, > because it breaks platform build. ... which is why I added a new feature to Tycho so that this back-reference can be disabled in the build. The problem would be fixed if the attached patch was accepted.
Thanks for calling my attention to this bug. We are using Tycho 0.18.0 (0.18.1, actually, by now) in both Luna and Kepler streams. I believe the patch is entirely in SWT, right? (from a quick skim read) ... it seems like a reasonable approach to me ... we should try in Luna first, before back-porting. It is not clear to me how to "verify it works" ... again, have only had time to skim read. But, one important "test case" will be if the b3 aggregator still works as expected. I just say that since it checks if everything is "consistent" and at times in the past, this has required that certain "requirements and capabilities" be made consistent not only at plugin level but also feature level ... no idea if that applies here ... just saying it is one test case to verify. [I'll be out rest of morning, but back this afternoon, if anyone wanted a quick test build before the 8 PM nightly].
I pushed the patch. http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=dfe1ddef04caf2e66b4eff69da4870d983ba7159 David, please could you start a test build? Thanks.
The test build completed without error. And, I did a quick "sanity check" with b3 aggregator, and it still aggregated as usual, so, can originators take a look and see if original issue is fixed for them? The test build is on build machine (only). The traditional build DL-type build is at http://build.eclipse.org/eclipse/builds/4I/siteDir/eclipse/downloads/drops4/I20130812-1219/ But probably what's desired is "repo" and it is at http://build.eclipse.org/eclipse/builds/4I/siteDir/updates/4.4-I-builds/I20130812-1219 Thanks,
Is this change related to build failure in today's I-build? http://download.eclipse.org/eclipse/downloads/drops4/I20130813-0800/ Looks related, on the surface. And, in hindsight, I'm not sure I did the test build correctly ... I did a test "I build" but not sure changes were released to "integration branch". Perhaps too, it is related to comparator substitution ... and some swt bundles/fragments need to be "touched" in order to all be "up to date"? I'm honestly not sure how a p2.inf-only change effects the qualifier?
The nightly build did include this change though. Is there something about the I-Build that would cause this to fail, but not in the nightly build?
I have reverted these changes and we are ready to re-spin a I Build (or nightly).
(In reply to comment #27) > The nightly build did include this change though. Is there something about > the I-Build that would cause this to fail, but not in the nightly build? The main thing that is different is that the N-builds all get unique qualifiers (since, they are simply based on build date and time) ... where as in I-build, if there is a "matching" bundle in repository, it is used instead of what is "just built". But, from the first error message: Missing requirement for filter properties ~= $0: org.eclipse.swt 3.102.0.v20130812-2156 requires 'org.eclipse.swt.gtk.linux.x86 [3.102.0.v20130812-2156]' but it could not be found It seems like it is getting "recent changes" ... made late last night. Perhaps that's then master was merged with 'integration'?
(In reply to comment #28) > I have reverted these changes and we are ready to re-spin a I Build (or > nightly). I'll re-schedule an I-build for 12 noon, Eastern.
(In reply to comment #29) > (In reply to comment #27) > > The nightly build did include this change though. Is there something about > > the I-Build that would cause this to fail, but not in the nightly build? > > The main thing that is different is that the N-builds all get unique > qualifiers (since, they are simply based on build date and time) ... where > as in I-build, if there is a "matching" bundle in repository, it is used > instead of what is "just built". But, from the first error message: > > Missing requirement for filter properties ~= $0: org.eclipse.swt > 3.102.0.v20130812-2156 requires 'org.eclipse.swt.gtk.linux.x86 > [3.102.0.v20130812-2156]' but it could not be found > And, in case not obvious, I'll point out the time stamp of the change (2165) is AFTER the nightly build .... which would have started at 2000. Were there other changes made? in addition to this one? Perhaps, for example, if "new fragments" were built, something went wrong with that build process? Or could the new metadata been "lost", if the fragments updated? All just guesses ... but, I am curious if the "revert" was literally just for this change in this bugzilla? Or was "integration" branch simply set back to what it was last week ... which might have had other changes involved?
AFAIK, the v* timestamp is in GMT and the N-build starts at 2000 in the -0400 timezone (i.e. at 2400 GMT). So the same commits were used for N and I builds. Could the problem be that the p2.inf change tied the versions of the org.eclipse.swt and fragment bundles together? These versions are the same for N-builds (build time), but not for I-builds (time of last commit to the respective Git repo).
(In reply to comment #32) > Could the problem be that the p2.inf change tied the versions of the > org.eclipse.swt and fragment bundles together? > > These versions are the same for N-builds (build time), but not for I-builds > (time of last commit to the respective Git repo). If the SWT fragments and the SWT host can have different qualifiers, the patch won't work. The patch required that the qualifiers are the same. But let's take one step back: I was assuming that version-wise there is a 1:1 relationship between the SWT host and each SWT fragment, i.e. one version of the SWT host is only supposed to be used with exactly one version of each SWT fragment. If this was the case, either side could specify a requirement to an exact version of the other side. However, it rather seems that the versions of both the SWT host and the SWT fragments may change independently. This results in an N:M relationship, where the version of the neither side can determine the version of the other side. So to clarify: Is this N:M relationship between host and fragment versions intended? If yes, we could use version ranges from the host to the fragments. This is better than nothing, but I'd still be surprised to get any version of the fragment when requiring a specific version of the host. So instead, we could make the host require an feature which includes the SWT host and the fragments. This requirement wouldn't need a version restriction, because the version restriction imposed by the feature (and the fact the the SWT host and fragments are singleton) would ensure that the right feature is resolved. So in the end, this would ensure that you get a combination of host and fragment which came from one of the builds that produced the selected version of the host. Is there already a feature which only contains the SWT host and fragments? If not, could this be introduced?
(In reply to comment #33) > So to clarify: Is this N:M relationship between host and fragment versions > intended? No, it's a side effect of changing one without changing the other and then using the jgit timestamp provider. A regular submission from SWT commits in o.e.swt and all of the fragments at the same time, so they all get the same qualifier (altthough in rare cases it's possible to get slightly different qualifiers). I guess in this fix case a change was made in the host or the fragments so they have different commit timestamps. PW
(In reply to comment #34) > (In reply to comment #33) > > So to clarify: Is this N:M relationship between host and fragment versions > > intended? > > No, it's a side effect of changing one without changing the other and then > using the jgit timestamp provider. > > A regular submission from SWT commits in o.e.swt and all of the fragments at > the same time, so they all get the same qualifier (altthough in rare cases > it's possible to get slightly different qualifiers). It should be possible to change the jgit timestamp provider to check for the latest change not only in the working tree of the current module but also in other paths in the same repository. In this way, a change to either the host or any of the fragments could increase all timestamps. The host and the fragments are in the same git repository, right?
(In reply to comment #35) > > The host and the fragments are in the same git repository, right? In this case, no. The java code is in eclipse.platform.swt and the fragments with natives are in eclipse.platform.swt.binaries. PW
(In reply to comment #36) > In this case, no. The java code is in eclipse.platform.swt and the > fragments with natives are in eclipse.platform.swt.binaries. In this case, the host and the fragments will almost never have the same timestamp because you'll have distinct commits in both repositories. Changing the jgit timestamp provider to allow checking paths outside of the current Git repository feels really wrong. Would it not be possible to build the fragments also from eclipse.platform.swt? You could leave the binaries in the other git repository and have e.g. the maven-dependency-plugin copy them over during the build. Or do you see any other possibility to make the timestamps of the SWT host and fragments consistent?
(In reply to comment #37) > > Or do you see any other possibility to make the timestamps of the SWT host > and fragments consistent? In the past, the SWT build process controlled the qualifier by updating the map file. Right now, as part of their build process they have an update/commit step to try and bring the timestamps in line (and use the JGit timestamp provider). But I've talked to SWT and we could just have their build process take control of the qualifiers again: 1) put specific qualifiers in the pom files instead of inheriting the JGit timestamp provider 2) have the SWT build process set the qualifier on each contribution and commit the pom changes. AFAIK we would just add the follow to each of the fragments and to o.e.swt: <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>tycho-packaging-plugin</artifactId> <version>${tycho.version}</version> <dependencies> <dependency> <groupId>org.eclipse.tycho.extras</groupId> <artifactId>tycho-sourceref-jgit</artifactId> <version>${tycho-extras.version}</version> </dependency> </dependencies> <configuration> <strictBinIncludes>false</strictBinIncludes> <format>'v20130821-0900'</format> <sourceReferences> <generate>true</generate> </sourceReferences> <archive> <addMavenDescriptor>false</addMavenDescriptor> </archive> <additionalFileSets> <fileSet> <directory>${project.build.directory}</directory> <includes> <include>.api_description</include> </includes> </fileSet> </additionalFileSets> </configuration> </plugin>
(In reply to comment #38) > AFAIK we would just add the following to each of the fragments and to o.e.swt: I don't know about all the other parameters, but for setting the qualifier, you only need to set the format parameter. I wouldn't repeat configuration which is anyway inherited from a parent POM. Although setting the format parameter in the proposed way would work, the forceContextQualifier parameter is more natural for what you want to achieve. So just set that parameter to the manually controlled timestamp (but without the single quotes) in the parent POM of the fragments and in the POM of o.e.swt: <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>tycho-packaging-plugin</artifactId> <version>${tycho.version}</version> <configuration> <forceContextQualifier>v20130821-0900</forceContextQualifier> </configuration> </plugin>
(In reply to comment #39) > > <plugin> > <groupId>org.eclipse.tycho</groupId> > <artifactId>tycho-packaging-plugin</artifactId> > <version>${tycho.version}</version> > <configuration> > <forceContextQualifier>v20130821-0900</forceContextQualifier> > </configuration> > </plugin> I like this much better. But when we use -DforceContextQualifier=N20130822-2000 (for example :-) will that override what's specified there? PW
(In reply to comment #40) > But when we use -DforceContextQualifier=N20130822-2000 > (for example :-) will that override what's specified there? To my own surprise, the value from the command line does not override the value in the plugin configuration. But you can keep it overridable if you set the checked-in qualifier value via a property: <properties> <forceContextQualifier>v20130821-0900</forceContextQualifier> </properties> <build> <plugins> <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>tycho-packaging-plugin</artifactId> <version>${tycho-version}</version> <configuration> <forceContextQualifier>${forceContextQualifier}</forceContextQualifier> </configuration> </plugin> </plugins> </build> (You could even omit the forceContextQualifier=${forceContextQualifier} configuration because this is the default, but I find it more understandable if it's made explicit.)
Comment on attachment 229969 [details] Patch: Ensure installation of fragments of org.eclipse.swt Proposed an updated and rebased patch: https://git.eclipse.org/r/#/c/18022/ Note: This patch still requires that the qualifiers of org.eclipse.swt and the fragments are in sync. @Paul: Has this been implemented yet?
(In reply to Tobias Oberlies from comment #42) > Note: This patch still requires that the qualifiers of org.eclipse.swt and > the fragments are in sync. > @Paul: Has this been implemented yet? I know that is hasn't been ... just by looking at our M3 repository (below). And, I think the fragments all match as sort of a coincidence due to another "build error". I'm not crazy about a solution that requires a "complete rebuild of swt" just to fix something on one platform. I do see the issue, but not sure of the right answer. = = = = = = $ ls -1 org.eclipse.swt[_.][^et]*.jar org.eclipse.swt_3.103.0.v20131030-1514.jar org.eclipse.swt.cocoa.macosx_3.103.0.v20131030-1517.jar org.eclipse.swt.cocoa.macosx.x86_64_3.103.0.v20131030-1517.jar org.eclipse.swt.cocoa.macosx.x86_64.source_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.aix.ppc_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.aix.ppc64_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.hpux.ia64_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.linux.ppc_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.linux.ppc64_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.linux.s390_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.linux.s390x_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.linux.x86_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.linux.x86_64_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.linux.x86_64.source_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.linux.x86.source_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.solaris.sparc_3.103.0.v20131030-1517.jar org.eclipse.swt.gtk.solaris.x86_3.103.0.v20131030-1517.jar org.eclipse.swt.win32.win32.x86_3.103.0.v20131030-1517.jar org.eclipse.swt.win32.win32.x86_64_3.103.0.v20131030-1517.jar org.eclipse.swt.win32.win32.x86_64.source_3.103.0.v20131030-1517.jar org.eclipse.swt.win32.win32.x86.source_3.103.0.v20131030-1517.jar
(In reply to comment #43) > I know that is hasn't been ... just by looking at our M3 repository (below). > And, I think the fragments all match as sort of a coincidence due to another > "build error". > > I'm not crazy about a solution that requires a "complete rebuild of swt" just to > fix something on one platform. I do see the issue, but not sure of the right > answer. So are partial version increments something which needs to be supported? According to comment #38, the SWT team would be happy to manage versions manually (i.e. not using the EGit timestamp provider), but this doesn't answer which flexibility is desired. There is a solution which allows arbitrary qualifier combinations while still ensuring that a consistent pair of host and applicable fragment is installed (see comment #33). This solution would require that a feature with only the swt host and all fragments (a subset of org.eclipse.rcp) is created and maintained. Would this be an option for SWT & release engineering teams?
(In reply to Tobias Oberlies from comment #44) > (In reply to comment #43) > > I know that is hasn't been ... just by looking at our M3 repository (below). > > And, I think the fragments all match as sort of a coincidence due to another > > "build error". > > > > I'm not crazy about a solution that requires a "complete rebuild of swt" just to > > fix something on one platform. I do see the issue, but not sure of the right > > answer. > So are partial version increments something which needs to be supported? > According to comment #38, the SWT team would be happy to manage versions > manually (i.e. not using the EGit timestamp provider), but this doesn't > answer which flexibility is desired. > > There is a solution which allows arbitrary qualifier combinations while > still ensuring that a consistent pair of host and applicable fragment is > installed (see comment #33). This solution would require that a feature with > only the swt host and all fragments (a subset of org.eclipse.rcp) is created > and maintained. Would this be an option for SWT & release engineering teams? I'm happy to do what ever the SWT team desires. But, the 1:1 relationship seems harder to manage over time -- except for the fact that they've done it that way for years due to PDE build? And think we don't do it now, since keeping "the qualifiers of org.eclipse.swt and the fragments in sync" would require a bunch of custom ant/maven code? If we added an swt.feature, I think there is only one other (obvious) feature that would have to change, org.eclipse.e4.rcp, that's where we currently "collect" swt and its fragments (along with many other items). Would this actually solve the use-case you want to solve? That is, is the problem some people want rcp apps, but they don't want all of org.eclipse.e4.rcp? I somehow thought it was at a lower level. That is, adding the feature would not change the metadata of swt itself ... just move it from org.eclipse.e4.rcp to some new swt feature. So, Silenio, and others, feel free to state which you'd prefer. I'm the last to know which is best for committers and community. (But feature seems easier, to me, if that solves the problem ... easier to make patches, easier to recompile fragment for just one platform, etc).
(In reply to comment #45) > If we added an swt.feature, (...) Would this actually solve the > use-case you want to solve? Yes, it would allow a solution: Once the feature is there, we can make org.eclipse.rcp require it (with an 0.0.0 version range) and in that way make sure that a compatible SWT fragment for the running platform is installed. > That is, is the problem some people want rcp apps, but they > don't want all of org.eclipse.e4.rcp? The problem is rather that some units declare a dependency on org.eclipse.swt, but not on the org.eclipse.e4.rcp feature. In fact, virtually all bundles requiring SWT do this.
(In reply to Tobias Oberlies from comment #46) > (In reply to comment #45) > > If we added an swt.feature, (...) Would this actually solve the > > use-case you want to solve? > Yes, it would allow a solution: Once the feature is there, we can make > org.eclipse.rcp require it (with an 0.0.0 version range) and in that way > make sure that a compatible SWT fragment for the running platform is > installed. I assume you meant we can make "org.eclipse.e4.rcp" require it ... or are you really suggesting it could move "up" to "org.eclipse.rcp"? And, I assume you meant the feature would "include" it? (Not sure a "require" with 0.0.0 would have desired effect.) FWIW, I suspect then the feature would need to specify a set of "filters" to list the platforms supported? > > That is, is the problem some people want rcp apps, but they > > don't want all of org.eclipse.e4.rcp? > The problem is rather that some units declare a dependency on > org.eclipse.swt, but not on the org.eclipse.e4.rcp feature. In fact, > virtually all bundles requiring SWT do this. Its unclear to me that a bundle specifying a dependency on swt bundle would profit from swt being in its own feature ... the app/product would still have to specify a dependency on swt feature, right? Or, am I missing something about where the metadata goes? (I believe it still "goes with" the feature ... and would not change the metadata of bundle ... right?).
(In reply to comment #47) > (In reply to Tobias Oberlies from comment #46) > > (In reply to comment #45) > > > If we added an swt.feature, (...) Would this actually solve the > > > use-case you want to solve? > > Yes, it would allow a solution: Once the feature is there, we can make > > org.eclipse.rcp require it (with an 0.0.0 version range) and in that way > > make sure that a compatible SWT fragment for the running platform is > > installed. > > I assume you meant we can make "org.eclipse.e4.rcp" require it ... or are you > really suggesting it could move "up" to "org.eclipse.rcp"? Sorry, typo: The *org.eclipse.swt* plugin would require the swt.feature with an 0.0.0 version range. This implies that when org.eclipse.swt is installed, an swt.feature including that org.eclipse.swt version would be installed, and hence also the platform-specific fragment from the same build. This would make "if it installs, it runs" also apply to swt.
(In reply to Tobias Oberlies from comment #48) > (In reply to comment #47) > > (In reply to Tobias Oberlies from comment #46) > > > (In reply to comment #45) > > > > If we added an swt.feature, (...) Would this actually solve the > > > > use-case you want to solve? > > > Yes, it would allow a solution: Once the feature is there, we can make > > > org.eclipse.rcp require it (with an 0.0.0 version range) and in that way > > > make sure that a compatible SWT fragment for the running platform is > > > installed. > > > > I assume you meant we can make "org.eclipse.e4.rcp" require it ... or are you > > really suggesting it could move "up" to "org.eclipse.rcp"? > Sorry, typo: The *org.eclipse.swt* plugin would require the swt.feature with > an 0.0.0 version range. This implies that when org.eclipse.swt is installed, > an swt.feature including that org.eclipse.swt version would be installed, > and hence also the platform-specific fragment from the same build. > > This would make "if it installs, it runs" also apply to swt. Not sure I've heard of a plugin that requires a feature. So are you saying the feature would only "include" the fragments? Sounds like a special case. Normally, by the time it builds, features are required to be included (require) by an exact version ... that ensures installs and builds are fully reproducible. Are you suggesting we violate that principle with this plan? If so ... doesn't sound good to me. But, I think I am not understanding the scheme/plan very well. Sorry if I'm being dense.
(In reply to Tobias Oberlies from comment #48) > Sorry, typo: The *org.eclipse.swt* plugin would require the swt.feature with > an 0.0.0 version range. This implies that when org.eclipse.swt is installed, > an swt.feature including that org.eclipse.swt version would be installed, > and hence also the platform-specific fragment from the same build. > > This would make "if it installs, it runs" also apply to swt. Would tycho be OK with a requirement on org.eclipse.swt bringing in a feature (o.e.swt.native.feature.group) that brings in the fragments which then have a dependency back on o.e.swt? Wouldn't that just cause the cycle problem mentioned in Bug 380934 ? David, SWT controlled the qualifier of the plugin+fragments for years, and their build is set up to keep them in sync (even for a single change on a specific platform). So the cost of doing it that way is a cost we already assumed for years. PW
(In reply to Paul Webster from comment #50) > (In reply to Tobias Oberlies from comment #48) > David, SWT controlled the qualifier of the plugin+fragments for years, and > their build is set up to keep them in sync (even for a single change on a > specific platform). So the cost of doing it that way is a cost we already > assumed for years. Yes, I was just looking for a way to improve things (reduce costs) ... seems status quo would rule out bug 405753? How will this work with LTS? (And, I'm sure it could, somehow, but ... seems that'd be additional work/cost for somebody). Though I'm sure you, and others, understand why this is needed better than I do. Do we do the same for "file systems" and other natives?
(In reply to David Williams from comment #51) > better than I do. Do we do the same for "file systems" and other natives? No, we don't do the same for the other native fragments, but they are more "traditional" fragments that enhance the functionality of the host (but are entirely optional and don't contribute API that can be used by another plugin) PW
(In reply to Paul Webster from comment #52) > (In reply to David Williams from comment #51) > > better than I do. Do we do the same for "file systems" and other natives? > > No, we don't do the same for the other native fragments, but they are more > "traditional" fragments that enhance the functionality of the host (but are > entirely optional and don't contribute API that can be used by another > plugin) > > PW Thanks Paul, that helps ... now back to the original question in comment 42 ... = = = = Note: This patch still requires that the qualifiers of org.eclipse.swt and the fragments are in sync. @Paul: Has this been implemented yet? = = = = Sounds like that must be the case? But, SWT team should say ... and, I'm still not saying that and the patch is the right approach :) ... but, as I've mentioned several times, I do not know the solution (not even sure I understand the problem, now!). I'm just trying to keep the conversation moving.
(In reply to comment #49) > (In reply to Tobias Oberlies from comment #48) > > (In reply to comment #47) > > Sorry, typo: The *org.eclipse.swt* plugin would require the swt.feature with > > an 0.0.0 version range. This implies that when org.eclipse.swt is installed, > > an swt.feature including that org.eclipse.swt version would be installed, > > and hence also the platform-specific fragment from the same build. > > > > This would make "if it installs, it runs" also apply to swt. > > Not sure I've heard of a plugin that requires a feature. So are you saying the > feature would only "include" the fragments? No. The feature must also include the org.eclipse.swt host. Only in that way, it is ensured that a feature is picked which includes groups the selected org.eclipse.swt bundle plus a compatible fragment. > Normally, by the time it builds, features are required to be included (require) > by an exact version ... that ensures installs and builds are fully reproducible. > Are you suggesting we violate that principle with this plan? The feature includes all bundles with an exact version. Only the back-reference from org.eclipse.swt to the swt.feature has no version constraint because we don't know the feature version when building the bundle, plus one version of the org.eclipse.swt bundle may be included in multiple swt.feature versions (if the optimisation of allowing updates to individual fragments should be implemented). The feature comes into the game as a bracket for selecting valid version combinations from the N:M mapping of org.eclipse.swt versions and native fragments versions. (In reply to comment #50) > (In reply to Tobias Oberlies from comment #48) > Would tycho be OK with a requirement on org.eclipse.swt bringing in a feature > (o.e.swt.native.feature.group) that brings in the fragments which then have a > dependency back on o.e.swt? Wouldn't that just cause the cycle problem > mentioned in Bug 380934 ? The dependency from org.eclipse.swt to the swt.feature would be disabled during the build of the swt host and fragments in order to break this circle. At install-time, there would be a circle, but given the power of the p2 dependency resolver, I'm expecting this to work without problems. (In reply to comment #53) > Thanks Paul, that helps ... now back to the original question in comment 42 ... > > = = = = > Note: This patch still requires that the qualifiers of org.eclipse.swt and the > fragments are in sync. > @Paul: Has this been implemented yet? > = = = = > > Sounds like that must be the case? But, SWT team should say ... and, I'm still > not saying that and the patch is the right approach :) ... but, as I've > mentioned several times, I do not know the solution (not even sure I understand > the problem, now!). I'm just trying to keep the conversation moving. The solution including the feature would not require the same qualifier for org.eclipse.swt and the fragments. I could propose a patch for that solution. But before doing so, I'd like to know who would be willing to submit the patch. @David, Paul: Would you do that? Or do we need someone from the SWT team?
Prep to make the qualifier the same for org.eclipse.swt and fragments: https://git.eclipse.org/r/18191 https://git.eclipse.org/r/18192
(In reply to Tobias Oberlies from comment #54) > The solution including the feature would not require the same qualifier for > org.eclipse.swt and the fragments. I could propose a patch for that solution. > > But before doing so, I'd like to know who would be willing to submit the > patch. @David, Paul: Would you do that? Or do we need someone from the SWT > team? So org.eclipse.swt + all of the fragments are already listed in org.eclipse.e4.rcp Does that mean we just need a p2.inf in org.eclipse.swt that requires org.eclipse.e4.rcp, and a version of 0.0.0? How will the build be told not to resolve that one link? PW
Created attachment 237288 [details] require o.e.e4.rcp As an example, requiring org.eclipse.e4.rcp feature from org.eclipse.swt. I just realized that it needs to be refactored out into its own feature, but the above should work in principle, right? PW
(In reply to comment #57) > As an example, requiring org.eclipse.e4.rcp feature from org.eclipse.swt. > > I just realized that it needs to be refactored out into its own feature, but the > above should work in principle, right? What do you mean with refactor out? IMHO we should not use the org.eclipse.e4.rcp feature for this because not every user of swt may want everything included in the org.eclipse.e4.rcp feature. The patch will not quite work: An optional dependency is not enough. Instead, there needs to be a mandatory dependency to the feature, which again can be deactivated at build time to avoid the dependency cycle. This would require the following changes: * An org.eclipse.swt.feature including the SWT host and all fragments. * Changing org.eclipse.e4.rcp to included the org.eclipse.swt.feature (instead of the host and fragments directly) * The following change in the org.eclipse.swt Git repository: https://git.eclipse.org/r/#/c/18559/ * The same pom.xml change in the org.eclipse.swt.binaries Git repository. Again: This is all for the case that SWT wants to be able to rebuild parts of SWT (e.g. one fragment and nothing else) or SWT cannot ensure consistent qualifiers for host and fragments. Otherwise, we could still go with my original patch: https://git.eclipse.org/r/#/c/18022/
(In reply to Tobias Oberlies from comment #58) > (In reply to comment #57) > > As an example, requiring org.eclipse.e4.rcp feature from org.eclipse.swt. > > > > I just realized that it needs to be refactored out into its own feature, but the > > above should work in principle, right? > What do you mean with refactor out? IMHO we should not use the > org.eclipse.e4.rcp feature for this because not every user of swt may want > everything included in the org.eclipse.e4.rcp feature. I mean we create the o.e.swt.feature with SWT only in it, then have o.e.e4.rcp (with no SWT) include o.e.swt. > Again: This is all for the case that SWT wants to be able to rebuild parts > of SWT (e.g. one fragment and nothing else) or SWT cannot ensure consistent > qualifiers for host and fragments. Otherwise, we could still go with my > original patch: https://git.eclipse.org/r/#/c/18022/ I think we're still planning to fix that so that o.e.swt and all of the fragments have the same qualifier. I'll talk to Silenio tomorrow and we can make that change. PW
(In reply to Paul Webster from comment #59) > ... tomorrow and we can make that change. And?
(In reply to Tobias Oberlies from comment #60) > (In reply to Paul Webster from comment #59) > > ... tomorrow and we can make that change. > And? Sorry Tobias, I dropped the ball on that one. I'll be in the office tomorrow and talk to Silenio then. PW
(In reply to Paul Webster from comment #55) > Prep to make the qualifier the same for org.eclipse.swt and fragments: > > https://git.eclipse.org/r/18191 > https://git.eclipse.org/r/18192 I've pushed updated changes to my patches. But these will need to be co-ordinated with changes in eclipse.platform.swt/bundles/org.eclipse.swt/buildSWT.xml I've pinged SWT. PW
(In reply to comment #62) > I've pinged SWT. Maybe this needs to be done again? Ping!
Created attachment 243712 [details] List of all p2.inf files in the Luna simrel Repository So ... what is the status of this initiative ? I skimmed through the comments, but I'm confused. I created a little script to list all the p2.inf file present in the Luna simrel repository, and it looks like some clients came up with workarounds that require some SWT fragments through p2.inf (see attached). To me it feels like an internal complexity is pushed onto clients here, and the underlying issue should rather be solved through this initiative ? As a client, I want a safe way to depend on SWT, which makes sure that p2 installs for me not only SWT itself but also any required fragments. We have a very similar problem in TCF, where we want cdt.core and its fragments - but only cdt.core and not all the rest of the CDT: https://bugs.eclipse.org/bugs/show_bug.cgi?id=435150 Is using a feature still the recommended approach ? - That seems a bit awkward to me since it can't work with import-package kind of dependencies.
(In reply to Martin Oberhuber from comment #64) > So ... what is the status of this initiative ? I think "fallen through the cracks" would be a good description? :) Seriously, though, I know the "entire team" has been working so hard on getting things "to work correctly" that "to make things easier for clients" has had to be given a lower priority. This is really up to SWT and PMC (not me), but if I might suggest, this be put on "Mars plan" ... which is no promise it will be fixed/resolved, but I hope at least allows enough of us to set aside some time to focus on it. SWT, if you don't like me touching your "targets" and "priorities", feel free to set as you'd like. I'm not sure we know the best answer yet, but don't see how this is too much different that what we do for "equinox.executable" ... where we jump through hoops to have a special IU in rep that "pulls in" the correct versions? (But, I'm probably just showing my lack of understanding of the issues ... which I don't mind at all ... since that'd prove my point too :)
(In reply to comment #65) > I'm not sure we know the best answer yet According to Paul (see comment #59), the answer for SWT is to enforce consistent qualifiers between in the fragments and the host. This allows to pull in the fragments from the host without needing a feature. (In reply to comment #65) > I think "fallen through the cracks" would be a good description? :) BTW, could anyone nominate Paul Webster for committer of SWT? To me, it seems that the SWT commiters don't dare to touch their own build, so they really should have someone one their project who does.
(In reply to Tobias Oberlies from comment #66) > (In reply to comment #65) > > I'm not sure we know the best answer yet > > According to Paul (see comment #59), the answer for SWT is to enforce > consistent qualifiers between in the fragments and the host. This allows to > pull in the fragments from the host without needing a feature. > > (In reply to comment #65) > > I think "fallen through the cracks" would be a good description? :) > > BTW, could anyone nominate Paul Webster for committer of SWT? To me, it > seems that the SWT commiters don't dare to touch their own build, so they > really should have someone one their project who does. I wouldn't mind nominating Paul if he is willing to. The problem with touching swt build system is way bigger than it looks from outside. First of all we don't have the needed eclipse.org infrastructure for e.g. testing (bug 429237). For building it will be even harder as I don't envision eclipse.org infra including 17 of machines with really strict library version requirements (some of them with non FOSS OSes so licenses and etc. become a problem too). All these work is done by the swt team @ibm (huge thanks for that) but improving the build system is possible only for people that have access to it to verify changes. I've broke the build a few times to know how hard is to find what went wrong and waiting for someone with access to the builders to check/send the logs. This might see irrelevant from java POV but it's important if one wants to really improve the buildsystem. The build system is a weird mixture of ant/pde.build/maven now and my intention is to continue fighting this mess (it really improved for people building swt from source last year) as only after that I can be less afraid that a change in one place wouldn't interfere with some of the other tools used. Overall - help is more than welcome. And some hard decisions are to be made like supported ws/os/arch built by default, where they are built and etc. Without this being decided and fixed somehow contributing is harder than it should be.
Let's look into this early 4.5 with the option to backport to 4.4.1. As for commit rights, they need to be earned upfront on the component itself.
Created attachment 243749 [details] List of all p2.inf files in the Luna simrel Repository
(In reply to comment #68) > Let's look into this early 4.5 with the option to backport to 4.4.1. Who is "us"?
(In reply to Tobias Oberlies from comment #70) > (In reply to comment #68) > > Let's look into this early 4.5 with the option to backport to 4.4.1. > Who is "us"? Those interested in getting this fixed. Paul is no longer actively working on Platform UI and the SWT team has other priorities.
(In reply to comment #71) > Those interested in getting this fixed. Paul is no longer actively working on > Platform UI and the SWT team has other priorities. This is a shame, but this bug was anyway not waiting for Paul. I've proposed two alternative solutions to the problem [1][2], and I need a committer to review them and accept either one on of them. [1] https://git.eclipse.org/r/#/c/18559/ [2] https://git.eclipse.org/r/#/c/18022/
(In reply to Tobias Oberlies from comment #72) > (In reply to comment #71) > > Those interested in getting this fixed. Paul is no longer actively working on > > Platform UI and the SWT team has other priorities. > This is a shame, but this bug was anyway not waiting for Paul. > > I've proposed two alternative solutions to the problem [1][2], and I need a > committer to review them and accept either one on of them. > > [1] https://git.eclipse.org/r/#/c/18559/ > [2] https://git.eclipse.org/r/#/c/18022/ Someone from the SWT team please review. Thanks.
We are currently making changes to enable our builds for auto-tagging. We will also look at the changes needed for this bug. Targetting for the next milestone.
(In reply to Lakshmi Shanmugam from comment #74) > We are currently making changes to enable our builds for auto-tagging. We > will also look at the changes needed for this bug. Targetting for the next > milestone. What does "enable for auto-tagging" mean? I don't know the CBI in particular, but I should be able to help you with Maven and/or Tycho questions that arise while integrating this change.
Pushed the changes to master through gerrit reviews: https://git.eclipse.org/r/#/c/18022/ and https://git.eclipse.org/r/#/c/18192/ http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=4f65f67ac1acdcce420ed3d2b84a82d905bd5b9d http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=1fb1522a48d55b59d07f0c37bf5e56bead8298b5
I'll respond here, to the "build break" note posted to platform-releng-dev: https://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg22699.html I'd noticed the break, looked a little into com.oopsconsultancy.xmltask.ant.XmlTask and it does look like a handy, powerful set of "xml tasks for Ant". My guess is we can add it to "our ant libraries", but there's a number of implications we should be clear on. - First, where did you get your version from? I want to "check the license", etc. We may have to submit a "build-time works-with CQ" or something. These are normally routinely approved, as long as we don't distribute it. - We currently use ant from "/shared/common/... so ... -- I would want to change to use our own "personal copy" rather than impose this library on "everyone else" ... you know, they might make use of something "accidentally", thinking it was a standard part of Ant. And only much later discover that it was not. -- By having this "extra requirement" on our build system, then everyone who wants to "build eclipse" will be "forced" to use the same non-standard library, *and* have to do the additional "setup". --- That is not out of the question, if that is the best (or only) way to do what we want ... but, it is not very "community friendly" --- Is there some way it can be made optional, so that if it was not present, we'd log a [WARNING] that "the build will not be quite right" (or, some better wording). - I'm curious if you investigated other options, and ruled them out? - Even if we use "right now", we may want to open a "CBI-bug" or something, with the idea that someday this could be replaced by a custom, "cbi-plugin" task of some sort?
Fix is discussed in bug 452439 .
(In reply to David Williams from comment #77) > I'll respond here, to the "build break" note posted to platform-releng-dev: > > https://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg22699.html > > I'd noticed the break, looked a little into > com.oopsconsultancy.xmltask.ant.XmlTask > and it does look like a handy, powerful set of "xml tasks for Ant". > > My guess is we can add it to "our ant libraries", but there's a number of > implications we should be clear on. I've moved the target using XmlTask to a separate build file so that it doesn't affect SDK build & other users. This change is committed to master. Is it possible to run a test build to test the changes made for this bug. > > - First, where did you get your version from? I want to "check the license", > etc. We may have to submit a "build-time works-with CQ" or something. These > are normally routinely approved, as long as we don't distribute it. I downloaded it from http://www.oopsconsultancy.com/software/xmltask/ using the link under the download topic. It says it is released under Apache license. We'll use it only in the internal SWT build to generate the libraries. How to submit the CQ for this? > > - We currently use ant from "/shared/common/... so ... > -- I would want to change to use our own "personal copy" rather than impose > this library on "everyone else" ... you know, they might make use of > something "accidentally", thinking it was a standard part of Ant. And only > much later discover that it was not. > -- By having this "extra requirement" on our build system, then everyone who > wants to "build eclipse" will be "forced" to use the same non-standard > library, *and* have to do the additional "setup". > --- That is not out of the question, if that is the best (or only) way to do > what we want ... but, it is not very "community friendly" > --- Is there some way it can be made optional, so that if it was not > present, we'd log a [WARNING] that "the build will not be quite right" (or, > some better wording). I agree that adding a new dependency on xmltask for Eclipse SDK is not community friendly and will break existing users. I guessed some component must already be using it in their build... > - I'm curious if you investigated other options, and ruled them out? I checked the other option - style/xslt task, but XmlTask seemed very straightforward to use for modifying the XML files. > - Even if we use "right now", we may want to open a "CBI-bug" or something, > with the idea that someday this could be replaced by a custom, "cbi-plugin" > task of some sort? If no other team/component requires the task, is it still worth doing this?
(In reply to Lakshmi Shanmugam from comment #79) > (In reply to David Williams from comment #77) > ... Is it possible to run a test build to > test the changes made for this bug. I've scheduled an N-build for 7 AM this morning (Eastern). > ... We'll use it only in the internal SWT build to generate the > libraries. How to submit the CQ for this? Not sure, but suspect best to come up with a "non-internal" solution, and then CQ question will be answerable. > If no other team/component requires the task, is it still worth doing this? Sure! Probably the better question is how to substitute the whole "antrun" step with a custom maven task ... even if not possible at the moment, it might make it more obvious how to "divide up the work" so that in the end, it all fits together as part of a "build-custom-natives" plugin, or similar. From a slightly different angle, I'm not sure what you are doing with XML, but it'd probably be pretty easy to do it in Java, and just have a custom ant-task, as a first step in having a custom maven plugin. (I'm guessing ... since we all know how to make custom ant tasks, but none of us know how to make custom maven plugins :)
(In reply to David Williams from comment #80) > (In reply to Lakshmi Shanmugam from comment #79) > > (In reply to David Williams from comment #77) > > ... Is it possible to run a test build to > > test the changes made for this bug. > > I've scheduled an N-build for 7 AM this morning (Eastern). > > > ... We'll use it only in the internal SWT build to generate the > > libraries. How to submit the CQ for this? > > Not sure, but suspect best to come up with a "non-internal" solution, and > then CQ question will be answerable. > > > If no other team/component requires the task, is it still worth doing this? > Sure! Probably the better question is how to substitute the whole "antrun" > step with a custom maven task ... even if not possible at the moment, it > might make it more obvious how to "divide up the work" so that in the end, > it all fits together as part of a "build-custom-natives" plugin, or similar. > From a slightly different angle, I'm not sure what you are doing with XML, > but it'd probably be pretty easy to do it in Java, and just have a custom > ant-task, as a first step in having a custom maven plugin. (I'm guessing ... > since we all know how to make custom ant tasks, but none of us know how to > make custom maven plugins :) If I may jump in :). There are few steps to fix the problem: * fix mixing IBM internal machine setup with generic build scripts - we have to fix this as first step and should be pretty straightforward. * fix to not use antrun in fragments build (without rebuilding natives) - what this does is basically coping the right sources to the fragment and running 64to32 conversion (if needed). This itself contains few problematic parts building swt.jar and swt-debug.jar - the second one being a rebuild with changed source - this is entirely against Maven workflow and is the major blocker here. * fix to not use antrun in fragments build when rebuilding natives (aka -Dnative=gtk.linux.x86_64) - as fewer people need this and it's not enabled by default it is not urgent but using maven-exec-plugin to call ./build.sh (which is what the antrun call is doing at the end) sounds like a possible way. * eventually switch the IBM internal build system to rely on maven to do the build and not ant or come up with eclipse.org hosted machines for the builds that does that What do others think ?
(In reply to David Williams from comment #80) > (In reply to Lakshmi Shanmugam from comment #79) > > (In reply to David Williams from comment #77) > > ... Is it possible to run a test build to > > test the changes made for this bug. > > I've scheduled an N-build for 7 AM this morning (Eastern). Well, the build seems to be working again: http://download.eclipse.org/eclipse/downloads/drops4/N20141120-0700/ Now that I think about it, though. Did you mean you needed a test *I-build* to confirm versioning is all worked out? If so, I can do one of those too (but, a true test build, just on build machine). Let me know.
(In reply to Alexander Kurtakov from comment #81) > (In reply to David Williams from comment #80) > > (In reply to Lakshmi Shanmugam from comment #79) > > > (In reply to David Williams from comment #77) > What do others think ? If you are asking me, sounds good, but, I am not sure I understand it enough to know exactly what you mean, or what implications are, or who has to do what. So, if there's anything you (SWT Team) need my help with, please let me know and I'd be glad to do what I can.
(In reply to David Williams from comment #82) > (In reply to David Williams from comment #80) > > (In reply to Lakshmi Shanmugam from comment #79) > > > (In reply to David Williams from comment #77) > > > ... Is it possible to run a test build to > > > test the changes made for this bug. > > > > I've scheduled an N-build for 7 AM this morning (Eastern). > > Well, the build seems to be working again: > > http://download.eclipse.org/eclipse/downloads/drops4/N20141120-0700/ > > Now that I think about it, though. Did you mean you needed > a test *I-build* to confirm versioning is all worked out? > If so, I can do one of those too (but, a true test build, > just on build machine). Let me know. Yes David, I was requesting for a test I-build to make sure the changes are working fine and don't break the I-build. Sorry for not being clear.
(In reply to Lakshmi Shanmugam from comment #84) > > Yes David, I was requesting for a test I-build to make sure the changes are > working fine and don't break the I-build. Sorry for not being clear. Ok, I have started on this "morning" (Eastern). I will be in and out today, so will post where to look, if you get a change in a few hours: Main URL: http://build.eclipse.org/eclipse/builds/4I/siteDir/eclipse/downloads/drops4/I20141121-0953/ Then the "unanticipated comparator errors" (if any) will be under http://build.eclipse.org/eclipse/builds/4I/siteDir/eclipse/downloads/drops4/I20141121-0953/buildlogs/ (assuming nothing goes wrong before that)
(In reply to David Williams from comment #85) > (In reply to Lakshmi Shanmugam from comment #84) > > > > > Yes David, I was requesting for a test I-build to make sure the changes are > > working fine and don't break the I-build. Sorry for not being clear. > > Ok, I have started on this "morning" (Eastern). > Assuming it was a "good test" (i.e. you'd made version changes since Tuesday's I-build), it appears it built ok, and doesn't report any comparator errors: http://build.eclipse.org/eclipse/builds/4I/siteDir/eclipse/downloads/drops4/I20141121-0953/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt
(In reply to David Williams from comment #86) > Assuming it was a "good test" (i.e. you'd made version changes since > Tuesday's I-build), it appears it built ok, and doesn't report any > comparator errors: Thanks David! I downloaded the above test build and verified that the swt plugin and fragment have the qualifier set in the pom file. Tobias, Can you please try the test build (or next I-build) and confirm that things are working fine with p2?
(In reply to comment #87) > Can you please try the test build (or next I-build) and confirm that things are > working fine with p2? I've looked at the p2 metadata in the build result, and it looks good. But I'll also do an end-to-end test with Tycho (see bug 453446). For the Tycho change, I need to understand the SWT versions. Luna has 3.103.x.xxx and Mars >= 3.104.0, correct?
(In reply to Tobias Oberlies from comment #88) > For the Tycho change, I need to understand the SWT versions. Luna has > 3.103.x.xxx and Mars >= 3.104.0, correct? Yes, Luna was 3.103.x.xxx and Mars is 3.104.x.xxx
(In reply to comment #88) > I've looked at the p2 metadata in the build result, and it looks good. But I'll > also do an end-to-end test with Tycho (see bug 453446). The end-to-end test passed. Also, I've removed the workaround for this bug in Tycho. So all users of the current Tycho SNAPSHOT version 0.23.0-SNAPSHOT will also test fix. @Lakshmi: Thank you very much for integrating my patch!
(In reply to Tobias Oberlies from comment #90) > (In reply to comment #88) > > I've looked at the p2 metadata in the build result, and it looks good. But I'll > > also do an end-to-end test with Tycho (see bug 453446). > > The end-to-end test passed. > Also, I've removed the workaround for this bug in Tycho. So all users of the > current Tycho SNAPSHOT version 0.23.0-SNAPSHOT will also test fix. > > @Lakshmi: Thank you very much for integrating my patch! Tobias, thanks for the patch & for testing!
@Tobias: do you think this is something to call out in the New & Noteworthy? If so, can you please provide a note that I can add to the N&N. Thanks!
Verified as per comment 90.
(In reply to comment #92) > @Tobias: do you think this is something to call out in the New & Noteworthy? If > so, can you please provide a note that I can add to the N&N. Thanks! This change potentially makes the life of RCP builders easier because they may no longer need to list all SWT fragments in their bundle-based products. However I suppose that there are still other instances of the same problem ("host bundle doesn't work unless a fragment is present") in the Eclipse Platform so I don't think that the "if it installs, it runs" promise is fulfilled yet. So this change by itself is IMHO not noteworthy.
This patch breaks eclipse.platform.swt.binaries build with -P build-individual-bundles. let's keep it reopen till we figure it out.
The failure is : [ERROR] Cannot resolve project dependencies: [ERROR] Software being installed: org.eclipse.swt.cocoa.macosx.x86_64 3.104.0.qualifier [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141216-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141216-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141217-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141217-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141218-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141218-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141219-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141219-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141220-1500 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141220-1500]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141221-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141221-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141222-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141222-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141223-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141223-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141225-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141225-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141226-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141226-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141227-1500 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141227-1500]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141228-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141228-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141229-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141229-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141230-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141230-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20141231-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20141231-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20150101-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20150101-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20150102-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20150102-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20150103-1500 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20150103-1500]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20150104-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20150104-2000]' but it could not be found [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt 3.104.0.N20150105-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 [3.104.0.N20150105-2000]' but it could not be found [ERROR] Cannot satisfy dependency: org.eclipse.swt.cocoa.macosx.x86_64 3.104.0.qualifier depends on: bundle org.eclipse.swt [3.0.0,4.0.0) All other fragments fail the same.
(In reply to comment #96) > The failure is : > [ERROR] Cannot resolve project dependencies: > [ERROR] Software being installed: org.eclipse.swt.cocoa.macosx.x86_64 > 3.104.0.qualifier > [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt > 3.104.0.N20141216-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 > [3.104.0.N20141216-2000]' but it could not be found > [ERROR] Missing requirement for filter properties ~= $0: org.eclipse.swt > 3.104.0.N20141217-2000 requires 'org.eclipse.swt.cocoa.macosx.x86_64 > [3.104.0.N20141217-2000]' but it could not be found Right. The dependency from the host to the fragments require a fixed version, so the dependency resolution of the fragments cannot use the "older" host bundles. But we don't need the host to fragment dependency at build time, so it can simply be disabled: https://git.eclipse.org/r/#/c/39112/ @Alexander: Could you check if this fixes the problem?
Works for me Tobias. Would you please teach me what/where this property changes before I push the patch?
(In reply to comment #98) > Works for me Tobias. Would you please teach me what/where this property changes > before I push the patch https://git.eclipse.org/r/#/c/39112/ The dependency-resolution/profileProperties configuration affects how filters on dependencies are evaluated during Tycho's dependency resolution. In this particular case, it makes the dependencies declared in the p2.inf of org.eclipse.swt non-applicable. This p2.inf e.g. declares this dependency requires.14.namespace = org.eclipse.equinox.p2.iu requires.14.name = org.eclipse.swt.cocoa.macosx.x86_64 requires.14.range = [$version$,$version$] requires.14.filter = (&(osgi.os=macosx)(osgi.ws=cocoa)(osgi.arch=x86_64)(!(org.eclipse.swt.buildtime=true))) With org.eclipse.swt.buildtime set to true, the filter evaluates to false which means that the dependency is ignored. This fixes the dependency resolution problem you are seeing.
Thanks for the explanation. Pushed.
