Community
Participate
Working Groups
I am trying a local test build using Tycho 0.23.0-SNAPSHOT (which has a fix for logging "nest jars" correctly) and got a LOT of compile errors (not just warnings) in swt.tests and swt.tools. I imagine perhaps this was a "point in time" issue, if someone is making changes there ... and not a result of correctly logging 'nested jars', but thought I'd open this bug before I try a "re-run", just in case they are "real" errors. Or, could (maybe?) be a but in Tycho 0.23.0-snapshot? I'll attach "full set", but the compile errors were very "basic" things, where dependencies appear incorrect: [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:0.23.0-SNAPSHOT:compile (default-compile) on project org.eclipse.swt.tools: Compilation failure: Compilation failure: [ERROR] /data/shared/eclipse/builds/4N/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.swt/bundles/org.eclipse.swt.tools/JNI Generation/org/eclipse/swt/tools/internal/JNIGeneratorAppUI.java:[1] [ERROR] /******************************************************************************* [ERROR] ^ [ERROR] The type org.eclipse.swt.widgets.Composite cannot be resolved. It is indirectly referenced from required .class files [ERROR] /data/shared/eclipse/builds/4N/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.swt/bundles/org.eclipse.swt.tools/JNI Generation/org/eclipse/swt/tools/internal/JNIGeneratorAppUI.java:[1] [ERROR] /******************************************************************************* [ERROR] ^ [ERROR] The type org.eclipse.swt.widgets.Event cannot be resolved. It is indirectly referenced from required .class files [ERROR] /data/shared/eclipse/builds/4N/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.swt/bundles/org.eclipse.swt.tools/JNI Generation/org/eclipse/swt/tools/internal/JNIGeneratorAppUI.java:[17] [ERROR] import org.eclipse.swt.custom.*; [ERROR] ^^^^^^^^^^^^^^^^^^^^^^ [ERROR] The import org.eclipse.swt.custom cannot be resolved [ERROR] /data/shared/eclipse/builds/4N/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.swt/bundles/org.eclipse.swt.tools/JNI Generation/org/eclipse/swt/tools/internal/JNIGeneratorAppUI.java:[19] [ERROR] import org.eclipse.swt.layout.*; [ERROR] ^^^^^^^^^^^^^^^^^^^^^^ [ERROR] The import org.eclipse.swt.layout cannot be resolved [ERROR] /data/shared/eclipse/builds/4N/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.swt/bundles/org.eclipse.swt.tools/JNI Generation/org/eclipse/swt/tools/internal/JNIGeneratorAppUI.java:[24] [ERROR] Display display; [ERROR] ^^^^^^^
Created attachment 251299 [details] full list of errors at end of console log. I will immediately try again, in case someone was "in the middle" of making some changes?
I don't see any compile errors in my workspace. The org.eclipse.swt.tools project hasn't been touched for a few weeks. The only changes I see in the swt repos since I20150303-0800 is a build input, which looks unnecessary, but not wrong.
Failed a second time, in similar way. So ... guessing something subtle in 0.23.0-SNAPSHOT. Might still be "valid" issue ... that just wasn't seen before, so will leave this bug open a bit, but will revert parent pom back to 0.22.0 until there is time to study it better.
(In reply to David Williams from comment #3) > Failed a second time, in similar way. So ... guessing something subtle in > 0.23.0-SNAPSHOT. Might still be "valid" issue ... that just wasn't seen > before, so will leave this bug open a bit, but will revert parent pom back > to 0.22.0 until there is time to study it better. One thing that "looks funny" ... will need to compare to a 22.0 build .... is that the swt binaries comes "after" the processing of "tools" and "tests". SWT itself was indeed compiled much earlier, without error, so maybe this "reactor order" is just saying when "binaries" was completely done being processed? But ... I'd think it'd be done before anything else related to swt. [INFO] org.eclipse.swt.tools ............................. FAILURE [0.620s] [INFO] org.eclipse.swt.examples .......................... FAILURE [1.038s] [INFO] org.eclipse.swt.examples.browser.demos ............ FAILURE [0.103s] [INFO] org.eclipse.swt.examples.launcher ................. FAILURE [0.084s] [INFO] org.eclipse.swt.examples.ole.win32 ................ SUCCESS [0.170s] [INFO] org.eclipse.swt.examples.views .................... SKIPPED [INFO] org.eclipse.swt.tests ............................. FAILURE [0.565s] [INFO] org.eclipse.swt.tools.feature ..................... SKIPPED [INFO] eclipse.platform.swt.binaries ..................... SUCCESS [0.007s]
(In reply to David Williams from comment #4) > (In reply to David Williams from comment #3) > > Failed a second time, in similar way. So ... guessing something subtle in > > 0.23.0-SNAPSHOT. Might still be "valid" issue ... that just wasn't seen > > before, so will leave this bug open a bit, but will revert parent pom back > > to 0.22.0 until there is time to study it better. > > One thing that "looks funny" ... will need to compare to a 22.0 build .... > is that the swt binaries comes "after" the processing of "tools" and > "tests". > I notice in the aggregator pom, that binaries does indeed come after swt: <module>eclipse.platform.swt</module> <module>eclipse.platform.swt.binaries</module> Anyone remember a reason for that? Seems to me binaries should "come first"? Perhaps something in 22.0 makes it "resolve" to come first, and that's now gone from 23-snapshot? It'd be something to try .. unless someone knows for sure it needs to come after swt?
(In reply to David Williams from comment #5) > It'd be something to try .. unless someone knows for sure it needs to come > after swt? Well, not so sure it'd matter ... I've started a test build after reverting to 0.22.0 and it appears it will be "compiled" in same order: [INFO] org.eclipse.swt.tools [INFO] org.eclipse.swt.examples [INFO] org.eclipse.swt.examples.browser.demos [INFO] org.eclipse.swt.examples.launcher [INFO] org.eclipse.swt.examples.ole.win32 [INFO] org.eclipse.swt.examples.views [INFO] org.eclipse.swt.tests [INFO] org.eclipse.swt.tools.feature [INFO] eclipse.platform.swt.binaries And, presumably, will work! But, I will need to be offline a bit this afternoon, so will have to end my investigation now.
To cross-reference, Pascal tracked the SWT issues to a change made in Tycho, see bug 453446, which was related to SWT bug 361901.
New Gerrit change created: https://git.eclipse.org/r/43342
The provided patch fails the gerrit build, but it does allow the complete platform build to pass. The difference I have noticed is that while the platform build includes all the bundles and the fragments in the same "build", it is not the case for the SWT gerrit build and this fails. The only suggestion I have at this point is for the gerrit build to also include the swt fragments in the reactor.
(In reply to Pascal Rapicault from comment #9) > The provided patch fails the gerrit build, but it does allow the complete > platform build to pass. > The difference I have noticed is that while the platform build includes all > the bundles and the fragments in the same "build", it is not the case for > the SWT gerrit build and this fails. > The only suggestion I have at this point is for the gerrit build to also > include the swt fragments in the reactor. And ... you do mean "passes the whole build" even without Tycho 23.0-snapshot, I assume? If so, that is, it "passes the whole build" with Tycho 0.22.0, the way this is usually handled, is that "the whole build" is done in a Nightly, and the next day, the Gerrit build is well again, since it "points to" the N-build repo. (Not positive that'll work, in this case, since it is kind of unusual anyway, but my guess is that it would.)
> And ... you do mean "passes the whole build" even without Tycho > 23.0-snapshot, I assume? No I mean it passes the whole build with Tycho 0.23.0-SNAPSHOT but w/o changing tycho (at least not reverting the tycho change about swt)
(In reply to Pascal Rapicault from comment #9) > The provided patch fails the gerrit build, but it does allow the complete > platform build to pass. > The difference I have noticed is that while the platform build includes all > the bundles and the fragments in the same "build", it is not the case for > the SWT gerrit build and this fails. > The only suggestion I have at this point is for the gerrit build to also > include the swt fragments in the reactor. Just to check whether I understand correctly. You suggest to have everything from swt.binaries included in o.e.swt top pom? This would have been possible if we were not storing binaries in git (very wrong in my eyes) but breaking the ability to build only single repo would make the nightmare that developing swt even bigger. Can't these changes be done in a way which puts needed configs only/except for build-individual-bundles profile thus keeping both releng.aggregator and separate repos builds?
(In reply to Alexander Kurtakov from comment #12) > (In reply to Pascal Rapicault from comment #9) > > The provided patch fails the gerrit build, but it does allow the complete > > platform build to pass. > > The difference I have noticed is that while the platform build includes all > > the bundles and the fragments in the same "build", it is not the case for > > the SWT gerrit build and this fails. > > The only suggestion I have at this point is for the gerrit build to also > > include the swt fragments in the reactor. > > Just to check whether I understand correctly. You suggest to have everything > from swt.binaries included in o.e.swt top pom? > This would have been possible if we were not storing binaries in git (very > wrong in my eyes) but breaking the ability to build only single repo would > make the nightmare that developing swt even bigger. > Can't these changes be done in a way which puts needed configs only/except > for build-individual-bundles profile thus keeping both releng.aggregator and > separate repos builds? What I'm suggesting is for the gerrit build to clone the swt repo, clone the swt.binaries repo, and have a pom that builds those in one shot. I had not considered the profile approach. Could you provide a patch for it and I'll try on the platform build.
(In reply to comment #9) > The provided patch [1] fails the gerrit build, but it does allow the complete > platform build to pass. > The difference I have noticed is that while the platform build includes all the > bundles and the fragments in the same "build", it is not the case for the SWT > gerrit build and this fails. The background of this observed behaviour is that when the profileProperty org.eclipse.swt.buildtime=true is not set, the build expects that there are SWT fragments available with identical version as the SWT host. This is the case when the swt and swt.binaries repositories are built together, but not when only swt is built. (In reply to comment #13) > I had not considered the profile approach. Could you provide a patch for it and > I'll try on the platform build. So if the swt repository shall be buildable standalone, org.eclipse.swt.buildtime=true must continue to be set for all bundles in that repository. But then, there needs to be a different way to express that e.g. org.eclipse.swt.tools needs the SWT fragments. I've proposed a new patch that does this: https://git.eclipse.org/r/43658 This patch introduces a new, empty bundle which has a dependency to all SWT fragments (just like org.eclipse.swt) but with an open version range. Then, this bundle is required via a build-time only dependency (<extraRequirements>) from the org.eclipse.swt.tools bundle. This fixes the compile errors. What is missing in the patch is to have this build-time dependency configuration in all bundles in the swt repository which require the SWT fragments. The easiest way to do this is to introduce an additional parent POM used by these bundles. I wasn't sure where you'd want to place such a parent POM, so I didn't add it yet. But in any case the solution should be clear, and you should be able to take the patch from there and add the missing bits. [1] https://git.eclipse.org/r/43342
SWT Team, This will need to be fixed soon, for us to move to Tycho 23-SNAPSHOT, and we are getting close to doing that. I have been running test builds by applying the patch in comment 8. Can you apply that one? Seem's the simplest way forward, for M6, even if you devise some other solution later? (And, if you make a "pom only" change, don't forget to "touch" the bundle/feature, to increase the qualifier.) As soon as I've seen you've done this, I'll stop applying your patch during test builds, and will have to use patched Tycho build for "nightlies". (Still waiting for one more fix to use "regular" 23-snapshot). Thanks,
New Gerrit change created: https://git.eclipse.org/r/43848
Gerrit change https://git.eclipse.org/r/43848 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=9c21286548a1eeb87aa8e958c2df8e8747f0167b
New Gerrit change created: https://git.eclipse.org/r/43849
Gerrit change https://git.eclipse.org/r/43849 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2015cd98ef5b2c9ff44d19f27b2e4161df8682ce
Hi David, the 2 swt repos are buildable standalone only with build-individual-bundles profile. Thus I've moved org.eclipse.swt.buildtime=true to be set only when this profile is enabled. As the profile is not enabled in the whole aggregator build and per Tobias comment I believe that my 2 commits should fix the problem. Would you please verify it?
(In reply to Alexander Kurtakov from comment #20) > Hi David, > the 2 swt repos are buildable standalone only with build-individual-bundles > profile. Thus I've moved org.eclipse.swt.buildtime=true to be set only when > this profile is enabled. As the profile is not enabled in the whole > aggregator build and per Tobias comment I believe that my 2 commits should > fix the problem. > Would you please verify it? To be sure, are all the commits already in master?
(In reply to Alexander Kurtakov from comment #20) > Hi David, > the 2 swt repos are buildable standalone only with build-individual-bundles > profile. Thus I've moved org.eclipse.swt.buildtime=true to be set only when > this profile is enabled. As the profile is not enabled in the whole > aggregator build and per Tobias comment I believe that my 2 commits should > fix the problem. > Would you please verify it? I've started an "X-build" without the SWT patch, approx. 11:30 AM Saturday (Eastern) ... if all goes well, should show up on DL site about 2:30 PM. (I did merge in a few other "administrative" changes to 'macapp' branch ... so, some chance I'll need to fix typos, or something ... but, in either case there should be something "this afternoon".)
(In reply to David Williams from comment #22) > I've started an "X-build" without the SWT patch, approx. 11:30 AM Saturday > (Eastern) ... if all goes well, should show up on DL site about 2:30 PM. > Either didn't help, or as Pascal suggests, are not actually in master? (And, I say "didn't help" ... but, did "change the error" from a bunch of compile errors, to a fast failure.). Did I misunderstand the request? [ERROR] The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='org.eclipse.swt:org.eclipse.swt.cocoa.macosx.x86_64:3.104.0-SNAPSHOT'}' and 'Vertex{label='org.eclipse.swt:org.eclipse.swt:3.104.0-SNAPSHOT'}' introduces to cycle in the graph org.eclipse.swt:org.eclipse.swt:3.104.0-SNAPSHOT --> org.eclipse.swt:org.eclipse.swt.cocoa.macosx.x86_64:3.104.0-SNAPSHOT --> org.eclipse.swt:org.eclipse.swt:3.104.0-SNAPSHOT -> [Help 1] org.apache.maven.ProjectCycleException: The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='org.eclipse.swt:org.eclipse.swt.cocoa.macosx.x86_64:3.104.0-SNAPSHOT'}' and 'Vertex{label='org.eclipse.swt:org.eclipse.swt:3.104.0-SNAPSHOT'}' introduces to cycle in the graph org.eclipse.swt:org.eclipse.swt:3.104.0-SNAPSHOT --> org.eclipse.swt:org.eclipse.swt.cocoa.macosx.x86_64:3.104.0-SNAPSHOT --> org.eclipse.swt:org.eclipse.swt:3.104.0-SNAPSHOT at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:297) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: org.codehaus.plexus.util.dag.CycleDetectedException: Edge between 'Vertex{label='org.eclipse.swt:org.eclipse.swt.cocoa.macosx.x86_64:3.104.0-SNAPSHOT'}' and 'Vertex{label='org.eclipse.swt:org.eclipse.swt:3.104.0-SNAPSHOT'}' introduces to cycle in the graph org.eclipse.swt:org.eclipse.swt:3.104.0-SNAPSHOT --> org.eclipse.swt:org.eclipse.swt.cocoa.macosx.x86_64:3.104.0-SNAPSHOT --> org.eclipse.swt:org.eclipse.swt:3.104.0-SNAPSHOT at org.codehaus.plexus.util.dag.DAG.addEdge(DAG.java:141) at org.apache.maven.project.ProjectSorter.addEdge(ProjectSorter.java:219) at org.apache.maven.project.ProjectSorter.addEdge(ProjectSorter.java:184) at org.apache.maven.project.ProjectSorter.<init>(ProjectSorter.java:115) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:285) ... 12 more [ERROR] [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectCycleException
(In reply to David Williams from comment #23) > (In reply to David Williams from comment #22) > > I've started an "X-build" without the SWT patch, approx. 11:30 AM Saturday > > (Eastern) ... if all goes well, should show up on DL site about 2:30 PM. > > > > Either didn't help, or as Pascal suggests, are not actually in master? > (And, I say "didn't help" ... but, did "change the error" from a bunch of > compile errors, to a fast failure.). > Did I misunderstand the request? Oh, and from a very quick peek at repo, it seems perhaps only the pom(s) were changed? If so, you'll need to "touch" the bundle (in the forcequalifierupdate.txt file) since our "X-Builds" are just like our "I-Builds" (that is, use the comparator, etc.).
(In reply to David Williams from comment #24) > (In reply to David Williams from comment #23) > > (In reply to David Williams from comment #22) > > > I've started an "X-build" without the SWT patch, approx. 11:30 AM Saturday > > > (Eastern) ... if all goes well, should show up on DL site about 2:30 PM. > > > > > > > Either didn't help, or as Pascal suggests, are not actually in master? > > (And, I say "didn't help" ... but, did "change the error" from a bunch of > > compile errors, to a fast failure.). > > Did I misunderstand the request? > > Oh, and from a very quick peek at repo, it seems perhaps only the pom(s) > were changed? If so, you'll need to "touch" the bundle (in the > forcequalifierupdate.txt file) since our "X-Builds" are just like our > "I-Builds" (that is, use the comparator, etc.). The fact that this failed in Saturday's 3 PM N-build tell's me that something is just plain wrong, with with change. Error is very similar: http://download.eclipse.org/eclipse/downloads/drops4/N20150314-1500/ And, it's using Tycho 22.0 (not a snapshot) and during N-builds, the comparator does not come into play, since each bundles's qualifier is always updated (to build date and time). No offense, but I'd suggest to revert the latest changes, and apply the "known solution" from comment 8. Then, over time work out the stuff you want to do with profiles, that allow building "one swt component".
Please note, I have switched master to use Tycho 0.23.0-SNAPSHOT. It does not work, with this bug, but I can apply a patch, during the full build, and it does work. My SWT patch is to revert the last two commits,(in this bug) and then apply the commit in comment 8. I support your efforts to "build one component", but ... I am sure you are aware this is "milestone stabilization week, so I think the priority needs to be on dong a "complete build" for us to meet our promised deliverables. To be unambiguous, you can see the hash codes of what I revert, and find the patch I apply to the build working tree, at http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/production/patchSWT.sh Thanks,
(In reply to David Williams from comment #26) Hi David, To be sure, can you please list what changes are required in SWT for the build to work? Sorry, but the comments seem to confuse me...
(In reply to Lakshmi Shanmugam from comment #27) > (In reply to David Williams from comment #26) > > > Hi David, > > To be sure, can you please list what changes are required in SWT for the > build to work? Sorry, but the comments seem to confuse me... Sure. Revert Comment 19 Gerrit change https://git.eclipse.org/r/43849 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2015cd98ef5b2c9ff44d19f27b2e4161df8682ce Revert Comment 17 Gerrit change https://git.eclipse.org/r/43848 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=9c21286548a1eeb87aa8e958c2df8e8747f0167b And, then apply Comment 8 New Gerrit change created: https://git.eclipse.org/r/43342 = = = = = = = I'm not saying this is the best fix, for all time, but would at least allow us to "build whole product" again.
(In reply to David Williams from comment #28) > ... but would at least allow us to "build whole product" again. And having one successful N-build before M6 stabilization would be a treat, wouldn't it? :)
New Gerrit change created: https://git.eclipse.org/r/43885
New Gerrit change created: https://git.eclipse.org/r/43886
Gerrit change https://git.eclipse.org/r/43885 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=f01a9f68c43a6a829137200fe8ad27e553667ba1
Gerrit change https://git.eclipse.org/r/43342 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=1b83dc73c478fbb7739c32608ebf36254deffdd9
(In reply to David Williams from comment #28) > (In reply to Lakshmi Shanmugam from comment #27) > > (In reply to David Williams from comment #26) Thanks David, for the steps. I've made the required changes and done build input. Hope this fixes the build.
(In reply to Lakshmi Shanmugam from comment #34) > > Thanks David, for the steps. I've made the required changes and done build > input. Hope this fixes the build. Not sure if the last change helped or not, but SWT build is still broken, see last build results on the patch below: https://git.eclipse.org/r/43837/
(In reply to Andrey Loskutov from comment #35) > (In reply to Lakshmi Shanmugam from comment #34) > > > > Thanks David, for the steps. I've made the required changes and done build > > input. Hope this fixes the build. > > Not sure if the last change helped or not, but SWT build is still broken, > see last build results on the patch below: > > https://git.eclipse.org/r/43837/ This has been discussed with the SWT team during the arch call and is known to be a temporary situation as tycho 0.23.0-SNAPSHOT is being adopted and necessary to move forward.
(In reply to Pascal Rapicault from comment #36) > (In reply to Andrey Loskutov from comment #35) > > > > Not sure if the last change helped or not, but SWT build is still broken, > > see last build results on the patch below: > > > > https://git.eclipse.org/r/43837/ > This has been discussed with the SWT team during the arch call and is > known to be a temporary situation as tycho 0.23.0-SNAPSHOT is being adopted > and necessary to move forward. Pascal, can you please evaluate a little more or just point me to some links regarding what can be done to fix the build or how long this temporary situation will take, or what is blocking the adoption?
(In reply to Andrey Loskutov from comment #37) > (In reply to Pascal Rapicault from comment #36) > > (In reply to Andrey Loskutov from comment #35) > > > > > > Not sure if the last change helped or not, but SWT build is still broken, > > > see last build results on the patch below: > > > > > > https://git.eclipse.org/r/43837/ > > This has been discussed with the SWT team during the arch call and is > > known to be a temporary situation as tycho 0.23.0-SNAPSHOT is being adopted > > and necessary to move forward. > > Pascal, can you please evaluate a little more or just point me to some links > regarding what can be done to fix the build or how long this temporary > situation will take, or what is blocking the adoption? I'll let Pascal answer the hard parts, but as for "what is blocking the adoption" it is described in comment 23: [ERROR] The projects in the reactor contain a cyclic reference. (and that was with using Tycho 23 snapshot, but same error occurred in N-build, using Tycho 22 release as mentioned in comment 25. (And, those errors occur with doing "a full build"). As far as I know, maybe the solution was close? And, perhaps just some "activation" was incorrect? (But, I must say, the problem, and solutions, certainly seem convoluted ... not very "maven like" ... makes me wonder if "radical change" would be better? And, I'm of course, just guessing, from ignorance, but instead of publishing the fragments into the git repo when they are compiled, to publish them to a (special) p2 repository that would be used by subsequent builds? Just an idea.)
New Gerrit change created: https://git.eclipse.org/r/43894
Gerrit change https://git.eclipse.org/r/43894 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=6fc93feae9b578070f4e4fd93eb2fdd6b74d1f73
(In reply to comment #40) > Gerrit change https://git.eclipse.org/r/43894 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=6fc93feae9b578070f4e4fd93eb2fdd6b74d1f73 Now you get the compile errors again when the build-individual-bundles profile is activated. To fix this, you need to apply my patch: https://git.eclipse.org/r/#/c/43658/ Note that the patch currently only fixes org.eclipse.swt.tools. To fix the other projects in the org.eclipse.swt repository, you need to make sure that all of them also have the extra-requirement to org.eclipse.swt.fragments.localbuild [1]. You could achieve this by copying this configuration to the other pom.xmls, but I strongly advise you not to do this. Instead, create a new parent POM that is used by all projects in the repository except org.eclipse.swt and org.eclipse.swt.fragments.localbuild, and move the extra-requirement configuration there. [1] https://git.eclipse.org/r/#/c/43658/4/bundles/org.eclipse.swt.tools/pom.xml
With the latest patch single repo build should be back to working.
I'm marking the bug as fixed as there is no pending item. Please reopen with details of what's left if I missed it.
Since I opened, I'll marked as verified ... there are no longer tons of compile errors :) ... and if anyone wants/needs to do more work like that mentioned in comment 41 I suggest opening a new bug for that (I'm assuming it wasn't already done). Mostly out of curiosity (no plans to move "back") but will "swt still build" if we moved "back" to Tycho 22?
(In reply to David Williams from comment #44) > Since I opened, I'll marked as verified ... there are no longer tons of > compile errors :) ... and if anyone wants/needs to do more work like that > mentioned in comment 41 I suggest opening a new bug for that (I'm assuming > it wasn't already done). http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=f80da13bc43b4b5c9267a50f3864b2511c02a7f4 does all the things discussed. > > Mostly out of curiosity (no plans to move "back") but will "swt still build" > if we moved "back" to Tycho 22? Honestly, I have no idea.
(In reply to comment #45) > > Mostly out of curiosity (no plans to move "back") but will "swt still build" > > if we moved "back" to Tycho 22? > > Honestly, I have no idea. No, the build should still run with Tycho 0.22.0. The submitted changes don't make use of any new Tycho 0.23.0-SNAPSHOT features.
