Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #405031 +++ This bug is to discuss and track the contribution of the Chromium support from https://github.com/maketechnology/chromium.swt to Eclipse SWT. More details on mailing list posts - https://www.eclipse.org/lists/platform-swt-dev/msg08380.html and https://www.eclipse.org/lists/platform-dev/msg01784.html
For the contribution we need to file CQs for the code and any dependencies/usages. It would be very useful if you could call out the following details for clarity? 1. All 3rd party dependencies and usages including those required at build and runtime both in the code and binaries? 2. All the proposed plugins/features/fragments that will be part of the contribution to Eclipse SWT Git repository. 3. Anything that is required for the integration, but will be hosted outside the Eclipse SWT Git repository. 4. Where will the native libraries be built, who builds them? (Currently we build all our native libraries on the Eclipse Foundation machines using Jenkins - https://hudson.eclipse.org/releng/view/SWT%20Natives/. The natives are built whenever there is a change that requires any new libraries and the revision is incremented every time there is a native build.)
The project is 27 kloc of *Rust* code that depend on 120 MB of 3rd party binaries. This way to extreme for the main SWT repo and the use of Rust is not justified.
(In reply to Nikita Nemkin from comment #2) > The project is 27 kloc of *Rust* code that depend on 120 MB of 3rd party > binaries. > This way to extreme for the main SWT repo and the use of Rust is not > justified. Agreed, I think something like this should be built + shipped separately. Something like "SWT with Chromium Support". That way users of SWT can download the "regular" version.
If I understand the proposal correctly, we should be able to integrate the Chromium support into SWT without affecting the existing SWT developers and users. Please correct me if I missed something. Only the Java classes [1] for the Chromium support will be in the SWT source repo and they don't have any 3rd party dependencies. So, existing SWT developers should not be affected. The binaries will be separate fragments in the SWT binaries repo. Since the SWT binaries repo is already huge and due to Rust dependency may be we could propose to have the chromium binaries in a separate binaries repo. Discussion is required on how the SWT-Chromium integration binaries will be made available to the users. It could be similar to the XULRunner support, where SWT shipped the SWT-XULRunner integration libraries and user had to download and install XULRunner on the system. For chromium support, SWT would ship the SWT-Chromium integration libraries and user has to download the CEF binaries from an update site. When I last checked the repo, the SWT-Chromium binaries for one platform were ~ 2MB in size. If the size is a concern for standalone SWT downloads, we could have 2 separate SWT downloads - with and without Chromium binaries. Thoughts? [1] - https://github.com/maketechnology/chromium.swt/tree/master/org.eclipse.swt.chromium
i think integrating this or something like this is quite important for eclipse Because on windows where do you go? The IE that is currently used is already kind of deprecated by Microsoft. So how are you going forward with that if you wouldn't include something like chromium or maybe what MS will give you on windows, who knows they will give Edge (the chromium edition) also as a an embedded browser? But that could take years.
(In reply to Lakshmi Shanmugam from comment #4) > If I understand the proposal correctly, we should be able to integrate the > Chromium support into SWT without affecting the existing SWT developers and > users. Please correct me if I missed something. > > Only the Java classes [1] for the Chromium support will be in the SWT source > repo and they don't have any 3rd party dependencies. So, existing SWT > developers should not be affected. > The binaries will be separate fragments in the SWT binaries repo. Since the > SWT binaries repo is already huge and due to Rust dependency may be we could > propose to have the chromium binaries in a separate binaries repo. +1 for having the Chromium binaries in a separate repo. > Discussion is required on how the SWT-Chromium integration binaries will be > made available to the users. > It could be similar to the XULRunner support, where SWT shipped the > SWT-XULRunner integration libraries and user had to download and install > XULRunner on the system. For chromium support, SWT would ship the > SWT-Chromium integration libraries and user has to download the CEF binaries > from an update site. > When I last checked the repo, the SWT-Chromium binaries for one platform > were ~ 2MB in size. If the size is a concern for standalone SWT downloads, > we could have 2 separate SWT downloads - with and without Chromium binaries. I agree with this approach (2 separate downloads), in order to minimize the impact for those using SWT as a standalone toolkit.
(In reply to Lakshmi Shanmugam from comment #1) > For the contribution we need to file CQs for the code and any > dependencies/usages. > It would be very useful if you could call out the following details for > clarity? > > 1. All 3rd party dependencies and usages including those required at build > and runtime both in the code and binaries? > > 2. All the proposed plugins/features/fragments that will be part of the > contribution to Eclipse SWT Git repository. > > 3. Anything that is required for the integration, but will be hosted outside > the Eclipse SWT Git repository. > > 4. Where will the native libraries be built, who builds them? > (Currently we build all our native libraries on the Eclipse Foundation > machines using Jenkins - > https://hudson.eclipse.org/releng/view/SWT%20Natives/. The natives are built > whenever there is a change that requires any new libraries and the revision > is incremented every time there is a native build.) Here are details for the proposal. 1. 3rd Party Dependencies - Runtime CEF binaries: for the swt chromium implementation to work it requires CEF binaries put in a specific folder (~/.swt/ or -Dswt.library.path). CEF binaries which can be build from source (https://bitbucket.org/chromiumembedded/cef/), downloaded from http://opensource.spotify.com/cefbuilds/index.html or obtained from a ready to use P2 repository provided by Make Technology. CEF binaries are not part of any SWT repository and follow the same approach as XUL runner or webkit implementations, where the actual binaries of those are provided separately by end users or application developers. There are no other third party dependencies besides the platform: java + windows system (gtk3, win32, cocoa) - Buildtime For JNI lib: - same as SWT binaries build (c toolchain) plus CEF headers in some folder indicated at build time. For SWT CEF native bindings: - rust toolchain - rust libraries ("crates"): winapi: rust bindings to win32 nix: rust bindings to Unix system functions objc: rust bindings to Objective C - CEF headers and CEF shared library in order to link the swt chromium integration shared library. This means, downloading the CEF distro per platform and placing it somewhere and pointing it during build time. Similar as it happens today with libwebkit. - Development cargo crate "bindgen" was used for generating CEF binding code in rust. This is not used during build or runtime, only at development time to simplify CEF version updates. This is optional but simplifies updates to new CEF versions. 25k of the 27k loc of rust code are autogenerated. 2. Git Repositories / Fragments / Feature - Git SWT Source repository - Java and JNI library code (*.c, *.h) included as another Browser implementation in its own folder (`/org.eclipse.swt/Eclipse SWT Chromium`) following standard SWT project layout in the existing SWT project. JNI code is generated with existing SWT jni generation mechanism (https://www.eclipse.org/swt/jnigen.php). - Rust code for CEF to Java bindings native library and subprocess helper executable (less than 20 .rs files) in a subfolder with build instructions. - Junit tests in Test_org_eclipse_swt_browser_Browser class - Maybe a feature including the fragments below for easy consumption? - Git SWT Binaries repository - 3 platform fragments containing the swt chromium binaries (jni lib, cef binding lib and subprocess executable) org.eclipse.swt.chromium.cocoa.macosx.x86_64 org.eclipse.swt.chromium.gtk.linux.x86_64 org.eclipse.swt.chromium.win32.win32.x86_64 The resulting jar for each fragment below is about ~500kB. Uncompressed natives are about ~2MB for each platform. - SWT download For the swt zip file downloaded from https://download.eclipse.org/eclipse/downloads/ this can include the separate chromium fragment .jar to keep the main swt.jar free of chromium libs. 3. Only CEF binaries which are required at runtime. These will not be part of SWT. Make Technology provides a ready to use p2 repository or end user can download it or app developers can ship it in their apps. 4. Who builds and when JNI lib can be easily build as part of standard SWT build with minimal adaptation of existing scripts. We are already doing this. The other native libraries (rust) can also be build in jenkins provided rust is installed (trivial installation, even possible to install during build in user space). SWT ant build script can be modified to validate the rust toolchain and call the rust build. All native files follow the same naming mechanism as the swt libs, including revision number and are loaded via the existing swt Library class. Code is already prepared to follow the same swt mechanism. Summary - SWT source repository is minimally affected including new java code, generated jni code and minimal rust code. - SWT binary repo is affected by adding 3 new fragments each ~2MB in uncompressed form. - No third party dependencies are forced. CEF is not required at runtime unless the new chromium implementation is wanted. SWT Chromium can be an opt-in during build, otherwise development and build behaves as currently. Native libs produced by rust are no required to be build if there are no rust code changes. - Standard SWT distribution is minimally affected including 3 new fragments which are optional. IMHO, I cannot think in a more streamlined way of making this contribution, that will actually work and be effective and maintained in the long term. There has been many iterations in the current code and approach to make the simplest possible solution to a very complex problem.
sad...no Win32
(In reply to Guillermo Zunino from comment #7) > 2. Git Repositories / Fragments / Feature > > - Git SWT Source repository > - Rust code for CEF to Java bindings native library and subprocess helper > executable (less than 20 .rs files) in a subfolder with build instructions. From https://www.eclipse.org/lists/platform-dev/msg01784.html I mistook that only java code (https://github.com/maketechnology/chromium.swt/tree/master/org.eclipse.swt.chromium) will be part of the source repo. From your proposal, the rust code (https://github.com/maketechnology/chromium.swt/tree/master/chromium-library) will be part of the source repo. Where are the C files? Does it also include the files required for building the rust code? > - Git SWT Binaries repository > > - 3 platform fragments containing the swt chromium binaries (jni lib, cef > binding lib and subprocess executable) > org.eclipse.swt.chromium.cocoa.macosx.x86_64 > org.eclipse.swt.chromium.gtk.linux.x86_64 > org.eclipse.swt.chromium.win32.win32.x86_64 > The resulting jar for each fragment below is about ~500kB. Uncompressed > natives are about ~2MB for each platform. > I think it's better to have these in a separate SWT repo since the binaries repo is already very big. Also, does it requires git-lfs?
(In reply to Lakshmi Shanmugam from comment #9) > (In reply to Guillermo Zunino from comment #7) > > 2. Git Repositories / Fragments / Feature > > > > - Git SWT Source repository > > - Rust code for CEF to Java bindings native library and subprocess helper > > executable (less than 20 .rs files) in a subfolder with build instructions. > > From https://www.eclipse.org/lists/platform-dev/msg01784.html I mistook that > only java code > (https://github.com/maketechnology/chromium.swt/tree/master/org.eclipse.swt. > chromium) will be part of the source repo. > From your proposal, the rust code > (https://github.com/maketechnology/chromium.swt/tree/master/chromium- > library) will be part of the source repo. Where are the C files? Does it > also include the files required for building the rust code? > > > - Git SWT Binaries repository > > > > - 3 platform fragments containing the swt chromium binaries (jni lib, cef > > binding lib and subprocess executable) > > org.eclipse.swt.chromium.cocoa.macosx.x86_64 > > org.eclipse.swt.chromium.gtk.linux.x86_64 > > org.eclipse.swt.chromium.win32.win32.x86_64 > > The resulting jar for each fragment below is about ~500kB. Uncompressed > > natives are about ~2MB for each platform. > > > I think it's better to have these in a separate SWT repo since the binaries > repo is already very big. Also, does it requires git-lfs? I think it makes sense to keep all source code in the same repo to simplify the building and allowing to build it from jenkins also if that is desired. The rust build script (build.rs) also included. CEF c headers files not part of the repo, but downloaded separately and pointed during the build (like libwebkit2). The generated c files for the jni lib (generated using swt tools jni mechanism from annotated java classes) will be part of the repo also as any other swt native code, in folder bundles/org.eclipse.swt/Eclipse SWT Chromium/common (I don't have these pushed into the chromium.swt repo, but in an swt fork that I'm preparing for the proposal)
(In reply to Guillermo Zunino from comment #10) We need to specify the licence information when filing the CQs. What will be the license for these files that'll be part of the source repo: 1. rust files 2. rust build script and CEF c headers that will be used during the build.
(In reply to Lakshmi Shanmugam from comment #11) > (In reply to Guillermo Zunino from comment #10) > > We need to specify the licence information when filing the CQs. What will be > the license for these files that'll be part of the source repo: > 1. rust files > 2. rust build script > and CEF c headers that will be used during the build. 1. rust files: EPL 2. rust build script: EPL 3. CEF C headers are part of the CEF project, which is BSD licensed.
@Guillermo, Can you please let us know, when do you plan to create the gerrit patches with the code? We will create CQs for the code contribution after the code is in gerrit. I'll check if we can create CQs for the dependencies before.
(In reply to Guillermo Zunino from comment #10) > I think it makes sense to keep all source code in the same repo to simplify > the building and allowing to build it from jenkins also if that is desired. > The rust build script (build.rs) also included. CEF c headers files not part > of the repo, but downloaded separately and pointed during the build (like > libwebkit2). > > The generated c files for the jni lib (generated using swt tools jni > mechanism from annotated java classes) will be part of the repo also as any > other swt native code, in folder bundles/org.eclipse.swt/Eclipse SWT > Chromium/common (I don't have these pushed into the chromium.swt repo, but > in an swt fork that I'm preparing for the proposal) I think we can have the code in the SWT source repo. Can you put all the code in a separate fragment in the SWT source repo, instead of having it in the main SWT project? This will keep the Chromium code separate and also help in easy maintenance.
(In reply to Lakshmi Shanmugam from comment #13) > @Guillermo, > Can you please let us know, when do you plan to create the gerrit patches > with the code? We will create CQs for the code contribution after the code > is in gerrit. I'll check if we can create CQs for the dependencies before. Hi @Lakshmi, I will work in the gerrit patches. Should be ready for next week. I'll create fragments to keep it separate. I think the only changes in main code will be a new constant and some changes in BrowserFactory. And small additions to make*.mak
(In reply to Guillermo Zunino from comment #7) @Guillermo, I'm planning to create CQ for the runtime dependencies. > Here are details for the proposal. > > 1. 3rd Party Dependencies > - Runtime > CEF binaries: for the swt chromium implementation to work it requires CEF > binaries put in a specific folder (~/.swt/ or -Dswt.library.path). CEF > binaries which can be build from source > (https://bitbucket.org/chromiumembedded/cef/), downloaded from > http://opensource.spotify.com/cefbuilds/index.html or obtained from a ready > to use P2 repository provided by Make Technology. > CEF binaries are not part of any SWT repository and follow the same > approach as XUL runner or webkit implementations, where the actual binaries > of those are provided separately by end users or application developers. > There are no other third party dependencies besides the platform: java + > windows system (gtk3, win32, cocoa) Please provide the supported CEF version. Which distribution from the downloads page [1] needs to be used? For the license, I found this https://bitbucket.org/chromiumembedded/cef/src/master/LICENSE.txt. Is there any link which specifies the license for the CEF runtime? Are the CEF binaries in the p2 repo [2] same as one in the downloads page [1] and do they have the same license? [1] http://opensource.spotify.com/cefbuilds/index.html [2] http://dl.maketechnology.io/chromium-cef/rls/repository
(In reply to Guillermo Zunino from comment #15) > Hi @Lakshmi, I will work in the gerrit patches. Should be ready for next > week. (In reply to Lakshmi Shanmugam from comment #16) > @Guillermo, > I'm planning to create CQ for the runtime dependencies. Any updates on this? Chromium support would really be beneficial to users! :)
I second that! This feature would be really helpful! Using the default SWT browser in Windows nowdays makes it very difficult if not impossible to integrate modern web applications as part of an Eclipse RCP application.
(In reply to Pierre-Yves B. from comment #17) > (In reply to Guillermo Zunino from comment #15) > > Hi @Lakshmi, I will work in the gerrit patches. Should be ready for next > > week. > > (In reply to Lakshmi Shanmugam from comment #16) > > @Guillermo, > > I'm planning to create CQ for the runtime dependencies. > > > Any updates on this? Chromium support would really be beneficial to users! :) We are waiting for the gerrit patches from Guillermo. @Guillermo, Any updates on when you will be able to create the gerrit patches?
(In reply to Lakshmi Shanmugam from comment #19) > (In reply to Pierre-Yves B. from comment #17) > > (In reply to Guillermo Zunino from comment #15) > > > Hi @Lakshmi, I will work in the gerrit patches. Should be ready for next > > > week. > > > > (In reply to Lakshmi Shanmugam from comment #16) > > > @Guillermo, > > > I'm planning to create CQ for the runtime dependencies. > > > > > > Any updates on this? Chromium support would really be beneficial to users! :) > > We are waiting for the gerrit patches from Guillermo. > > @Guillermo, > Any updates on when you will be able to create the gerrit patches? Hi, sorry for the delays, gerrit patches hopefully coming before EOY.
Agreed. This would, for example, help with https://bugs.openjdk.java.net/browse/JMC-6531.
(In reply to Guillermo Zunino from comment #20) > Hi, sorry for the delays, gerrit patches hopefully coming before EOY. Is there anything I could help you with? This regularly pops up, slowly becoming a real blocker.
The OpenJDK JMC project is suffering a bit. We're considering various stop-gap measures for: https://bugs.openjdk.java.net/browse/JMC-6531 For example: https://github.com/openjdk/jmc/pull/41 Is there anything we haven't considered that could help?
New Edge is out https://www.microsoft.com/edge. It's a much better option for SWT than Chromium/CEF. I don't think Chromium/CEF should be merged directly into SWT.
The power of SWT-Chromium is that it is the same engine on win, mac, and linux. The problem with native is that you never know what browser you're going to get. Eclipse RCP has been able to ship "native webapps" since the very beginning, but it hasn't been used for that very much. Electron saw huge uptake very quickly, because it made "write once deploy everywhere" really work on the desktop (guaranteed same browser engine for all your users), in a way that "write once and hope that the installed browser will mostly render your app" cannot. The plan is not, and has never been, to make Chromium a required part of SWT. It is to make it an optional, available part of SWT. If you want to use web tech for one of your views, it is a game changer - relying on the native browser will always be whack-a-mole.
(In reply to Nikita Nemkin from comment #24) > New Edge is out https://www.microsoft.com/edge. It's a much better option > for SWT than Chromium/CEF. > I don't think Chromium/CEF should be merged directly into SWT. How do you see that for you? It's not even released really to the general population. We need something that we know is there, and will Microsoft open that engine to have apis to embed the engine?? It's not that you can just use this... There must be something I think around or in it that gives that support. But as Ned says eclipse should have an option that really embeds on all platforms the same stuff. That's really important, I think eclipse should have done this already for years, it's really missing the big flow already. I also wonder what MS is really going to do with what you can embed in native window apps... Do they have already something else the the IE engine?
(In reply to Ned Twigg from comment #25) > The power of SWT-Chromium is that it is the same engine on win, mac, and > linux. The problem with native is that you never know what browser you're > going to get. You're going to get (forked) WebKit on every platform. (In reply to Johan Compagner from comment #26) > How do you see that for you? > It's not even released really to the general population. > We need something that we know is there, and will Microsoft open that engine > to have apis to embed the engine?? It's not that you can just use this... > There must be something I think around or in it that gives that support. It is released, since January 15 and the embedding API is available.
(In reply to Nikita Nemkin from comment #24) > New Edge is out https://www.microsoft.com/edge. It's a much better option > for SWT than Chromium/CEF. For the record: unless someone steps up and does the work no browser will be added to SWT. Thus, I encourage everyone who would like to see Edge being used in SWT to provide a high-quality patch that implements this. I can help reviewing/sorting out any license/IP questions.
Isn't this issue about integrating Chromium into SWT - and that Guillermo Zunino is working on gerrit patches? I also asked if there is anything I could help with. I think if Edge is now a topic, this should be handled in a newly created bug.
(In reply to Guillermo Zunino from comment #20) > (In reply to Lakshmi Shanmugam from comment #19) > > (In reply to Pierre-Yves B. from comment #17) > > > (In reply to Guillermo Zunino from comment #15) > > > > Hi @Lakshmi, I will work in the gerrit patches. Should be ready for next > > > > week. > > > > > > (In reply to Lakshmi Shanmugam from comment #16) > > > > @Guillermo, > > > > I'm planning to create CQ for the runtime dependencies. > > > > > > > > > Any updates on this? Chromium support would really be beneficial to users! :) > > > > We are waiting for the gerrit patches from Guillermo. > > > > @Guillermo, > > Any updates on when you will be able to create the gerrit patches? > > Hi, sorry for the delays, gerrit patches hopefully coming before EOY. @Guillermo, Any updates on when you will be able to provide the gerrit patches? Let us know if you need any help.
(In reply to Marco Descher from comment #29) > Isn't this issue about integrating Chromium into SWT - and that Guillermo > Zunino is working on gerrit patches? > > I also asked if there is anything I could help with. > > I think if Edge is now a topic, this should be handled in a newly created > bug. Nikita, if it's possible to default to embedding Edge rather than IE when supported, in core SWT, I think this would be a great change, no matter if Chromium becomes available as an optional SWT fragment. If you add this as a new bug, as suggested by Marco, I'd certainly vote for it.
(In reply to Marcus Hirt from comment #31) > Nikita, if it's possible to default to embedding Edge rather than IE when > supported, in core SWT, I think this would be a great change, no matter if > Chromium becomes available as an optional SWT fragment. If you add this as a > new bug, as suggested by Marco, I'd certainly vote for it. I wouldn't mind an _optional_ fragment. But the topic here is merging code with very troublesome dependencies directly into main SWT repo. Edge2 integration is Bug 538991.
Ah. Had forgotten about https://bugs.eclipse.org/bugs/show_bug.cgi?id=538991. :) Well, IMHO 538991 makes sense no matter what happens with this bug.
@Guillermo - are you still in any way occupied with this bug? Thx for feedback!
We are almost ready to create the gerrit patches, we are cleaning the code and making sure it builds and run fine on all platforms.
New Gerrit change created: https://git.eclipse.org/r/159486
New Gerrit change created: https://git.eclipse.org/r/159487
(In reply to Lakshmi Shanmugam from comment #30) > (In reply to Guillermo Zunino from comment #20) > > (In reply to Lakshmi Shanmugam from comment #19) > > > (In reply to Pierre-Yves B. from comment #17) > > > > (In reply to Guillermo Zunino from comment #15) > > > > > Hi @Lakshmi, I will work in the gerrit patches. Should be ready for next > > > > > week. > > > > > > > > (In reply to Lakshmi Shanmugam from comment #16) > > > > > @Guillermo, > > > > > I'm planning to create CQ for the runtime dependencies. > > > > > > > > > > > > Any updates on this? Chromium support would really be beneficial to users! :) > > > > > > We are waiting for the gerrit patches from Guillermo. > > > > > > @Guillermo, > > > Any updates on when you will be able to create the gerrit patches? > > > > Hi, sorry for the delays, gerrit patches hopefully coming before EOY. > > @Guillermo, > Any updates on when you will be able to provide the gerrit patches? Let us > know if you need any help. @Lakshmi two gerrit reviews have been created for source and bin repos (Although binaries are not included, let me know if I should add them). More info in the commit msg. This is based on previous discussions and there are minimal changes to current code.
CQ created: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=21808
(In reply to Lakshmi Shanmugam from comment #39) > CQ created: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=21808 In the CQ, I specified the organisation as Make Technology based on - https://github.com/maketechnology/chromium.swt#status-and-plan. Is it right since I just noticed that license text in the gerrit patch says Equo?
(In reply to Guillermo Zunino from comment #38) > @Lakshmi two gerrit reviews have been created for source and bin repos > (Although binaries are not included, let me know if I should add them). > More info in the commit msg. This is based on previous discussions and there > are minimal changes to current code. Thanks Guillermo, please include the binaries as well in the gerrit patch as they should be added to source control and will also be required for testing.
(In reply to Lakshmi Shanmugam from comment #40) > (In reply to Lakshmi Shanmugam from comment #39) > > CQ created: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=21808 > > In the CQ, I specified the organisation as Make Technology based on - > https://github.com/maketechnology/chromium.swt#status-and-plan. Is it right > since I just noticed that license text in the gerrit patch says Equo? Recently we changed the name to "Equo" (https://www.equoplatform.com). So that should be the organization.
(In reply to Lakshmi Shanmugam from comment #41) > (In reply to Guillermo Zunino from comment #38) > > @Lakshmi two gerrit reviews have been created for source and bin repos > > (Although binaries are not included, let me know if I should add them). > > More info in the commit msg. This is based on previous discussions and there > > are minimal changes to current code. > > Thanks Guillermo, please include the binaries as well in the gerrit patch as > they should be added to source control and will also be required for testing. Hi Lakshmi, the chromium.swt binaries can be build by invoking the usual mvn build with -Dnatives={ws}.{os}.{arch}. The build scripts where changed to allow building them. The only requirement is Rust installed. I think these binaries should be built and pushed by jenkins to ensure same OS compatibility as swt binaries. Installing Rust in the jenkins build should allow to built them from there. If you point me where jenkins scripts/images are defined for swt I can try to contribute that change also. I'm just double checking if you really want me to push the binaries built on my machine.
(In reply to Guillermo Zunino from comment #43) > (In reply to Lakshmi Shanmugam from comment #41) > > (In reply to Guillermo Zunino from comment #38) > > > @Lakshmi two gerrit reviews have been created for source and bin repos > > > (Although binaries are not included, let me know if I should add them). > > > More info in the commit msg. This is based on previous discussions and there > > > are minimal changes to current code. > > > > Thanks Guillermo, please include the binaries as well in the gerrit patch as > > they should be added to source control and will also be required for testing. > > Hi Lakshmi, the chromium.swt binaries can be build by invoking the usual mvn > build with -Dnatives={ws}.{os}.{arch}. The build scripts where changed to > allow building them. The only requirement is Rust installed. > I think these binaries should be built and pushed by jenkins to ensure same > OS compatibility as swt binaries. Thanks Guillermo, I agree. > Installing Rust in the jenkins build > should allow to built them from there. If you point me where jenkins > scripts/images are defined for swt I can try to contribute that change also. This wiki page has the details about the job to build the SWT natives at Eclipse Foundation - https://wiki.eclipse.org/SWT/Native_Builds_on_Foundation. Please let us know if you are unable to view the job or have any questions. > I'm just double checking if you really want me to push the binaries built on > my machine. Please push the binaries you have built to gerrit, it would be useful for anyone testing and reviewing the patch till we have the build setup ready locally and on the build machine. We could remove them from the gerrit patch before merge.
Hi Lakshmi, I added the binaries to gerrit https://git.eclipse.org/r/#/c/159487/ Regarding jenkins, I looked to jenkins builds, but I don't know where can I propose changes to the machine/docker definitions in order to install Rust for those. That should be the only change for jenkins to be able to build the binaries. (In reply to Lakshmi Shanmugam from comment #44) > (In reply to Guillermo Zunino from comment #43) > > (In reply to Lakshmi Shanmugam from comment #41) > > > (In reply to Guillermo Zunino from comment #38) > > > > @Lakshmi two gerrit reviews have been created for source and bin repos > > > > (Although binaries are not included, let me know if I should add them). > > > > More info in the commit msg. This is based on previous discussions and there > > > > are minimal changes to current code. > > > > > > Thanks Guillermo, please include the binaries as well in the gerrit patch as > > > they should be added to source control and will also be required for testing. > > > > Hi Lakshmi, the chromium.swt binaries can be build by invoking the usual mvn > > build with -Dnatives={ws}.{os}.{arch}. The build scripts where changed to > > allow building them. The only requirement is Rust installed. > > I think these binaries should be built and pushed by jenkins to ensure same > > OS compatibility as swt binaries. > Thanks Guillermo, I agree. > > > Installing Rust in the jenkins build > > should allow to built them from there. If you point me where jenkins > > scripts/images are defined for swt I can try to contribute that change also. > This wiki page has the details about the job to build the SWT natives at > Eclipse Foundation - > https://wiki.eclipse.org/SWT/Native_Builds_on_Foundation. Please let us know > if you are unable to view the job or have any questions. > > > I'm just double checking if you really want me to push the binaries built on > > my machine. > Please push the binaries you have built to gerrit, it would be useful for > anyone testing and reviewing the patch till we have the build setup ready > locally and on the build machine. We could remove them from the gerrit patch > before merge.
I tried to use the latest gerit-patches to try the chromium under ubuntu but I get following problem: (I added the printStackTrace() myself, it would not print it by itself). SWT.CHROMIUM style was used but chromium.swt gtk (or CEF binaries) fragment/jar is missing. java.lang.UnsatisfiedLinkError: /home/mathias/.swt/lib/linux/x86_64/chromium-3071/libchromium_swt_4934r5.so: /home/mathias/.swt/lib/linux/x86_64/chromium-3071/libchromium_swt_4934r5.so: undefined symbol: gdk_x11_window_get_xid at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method) at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2430) at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2487) at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617) at java.base/java.lang.Runtime.load0(Runtime.java:767) at java.base/java.lang.System.load(System.java:1834) at org.eclipse.swt.browser.BaseChromium.loadLib(BaseChromium.java:1549) Can somebody point me into any direction? Is this a problem of my local setup? I downloaded and used the cef binary_3.3071.1649.g98725e6_linux64_minimal from http://opensource.spotify.com/cefbuilds/index.html.
(In reply to Missing name from comment #46) > I tried to use the latest gerit-patches to try the chromium under ubuntu but > I get following problem: (I added the printStackTrace() myself, it would not > print it by itself). > > SWT.CHROMIUM style was used but chromium.swt gtk (or CEF binaries) > fragment/jar is missing. > java.lang.UnsatisfiedLinkError: > /home/mathias/.swt/lib/linux/x86_64/chromium-3071/libchromium_swt_4934r5.so: > /home/mathias/.swt/lib/linux/x86_64/chromium-3071/libchromium_swt_4934r5.so: > undefined symbol: gdk_x11_window_get_xid > at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method) > at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2430) > at > java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java: > 2487) > at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684) > at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617) > at java.base/java.lang.Runtime.load0(Runtime.java:767) > at java.base/java.lang.System.load(System.java:1834) > at org.eclipse.swt.browser.BaseChromium.loadLib(BaseChromium.java:1549) > > > Can somebody point me into any direction? Is this a problem of my local > setup? I downloaded and used the cef > binary_3.3071.1649.g98725e6_linux64_minimal from > http://opensource.spotify.com/cefbuilds/index.html. Hi, unfortunately cefbuilds for linux from opensource.spotify.com are linked to gtk2 and don't work with swt (besides other patches required). We maintain our own cef build in a p2 repo (http://dl.maketechnology.io/chromium-cef/rls/repository/), you can download linux build from http://dl.maketechnology.io/chromium-cef/rls/repository/plugins/com.make.chromium.cef.gtk.linux.x86_64_0.4.0.201908130254.jar
(In reply to Guillermo Zunino from comment #47) > Hi, unfortunately cefbuilds for linux from opensource.spotify.com are linked > to gtk2 and don't work with swt (besides other patches required). We > maintain our own cef build in a p2 repo > (http://dl.maketechnology.io/chromium-cef/rls/repository/), you can download > linux build from > http://dl.maketechnology.io/chromium-cef/rls/repository/plugins/com.make. > chromium.cef.gtk.linux.x86_64_0.4.0.201908130254.jar Hi Guillermo, In the CQ for SWT-Chromium support, I have specified the third party dependency only on the CEF binaries from http://opensource.spotify.com/cefbuilds/index.html (based on comment#7). If this support works *only* with the binaries in your P2 repository, it needs to go through additional legal process for approval. 1. Do the CEF builds in the p2 repo already have legal approval? 2. What is the license for the builds in the p2 repo (I didn't find any license information while trying to install using p2)?
(In reply to Lakshmi Shanmugam from comment #48) > (In reply to Guillermo Zunino from comment #47) > > Hi, unfortunately cefbuilds for linux from opensource.spotify.com are linked > > to gtk2 and don't work with swt (besides other patches required). We > > maintain our own cef build in a p2 repo > > (http://dl.maketechnology.io/chromium-cef/rls/repository/), you can download > > linux build from > > http://dl.maketechnology.io/chromium-cef/rls/repository/plugins/com.make. > > chromium.cef.gtk.linux.x86_64_0.4.0.201908130254.jar > > Hi Guillermo, > In the CQ for SWT-Chromium support, I have specified the third party > dependency only on the CEF binaries from > http://opensource.spotify.com/cefbuilds/index.html (based on comment#7). If > this support works *only* with the binaries in your P2 repository, it needs > to go through additional legal process for approval. > 1. Do the CEF builds in the p2 repo already have legal approval? > 2. What is the license for the builds in the p2 repo (I didn't find any > license information while trying to install using p2)? Hi Lakshmi, this requires CEF binaries in place. Those binaries can be obtained from: - Our P2 repository, which has custom builds with some patches and optimizations, and ensures compatibility with java and swt. - http://opensource.spotify.com/cefbuilds/index.html. Works in mac and windows. Currently doesn't work on linux due those are linked to gtk2 and swt is gtk3 only. - CEF Binaries can be build by anyone, with different args (linked to gtk3 for example), customized for specific purposes, enabling/disabling parts, etc. I think saying that *only* works with our P2 repo is not correct. With that said, here are the answers for your question: 1. Not that I'm aware. As was discussed previously in the original bug, my understanding was that CEF binaries should be keep outside eclipse. 2. There is "no license" in our cef P2 repository as this was not decided at the moment of creation. I don't have any issue with specifying it as BSD license which is the license of CEF project. I have no problem to republish the p2 repo with explicit BSD license if required.
Hi Guillermo, I tried out the gerrit patches on Windows10, but couldn't get the setup working. It would be helpful if you could share some step by step detail for us to try, on how to test your gerrit patches.(Also a separate set of steps: On how to build the dlls from your source code locally on our side will be helpful to test your patches throughly) Currently while testing your gerrit patches(source/binaries) we are getting below error while running JUnits from Test_org_eclipse_swt_browser_Chromium.java: -------------------------------------------------------------------------------- Running Test_org_eclipse_swt_browser_Browser#test_BrowserFunction_callback_with_javaReturningString SWT.CHROMIUM style was used but chromium.swt win32 (or CEF binaries) fragment/jar is missing. --------------------------------------------------------------------------------- Note: Lakshmi too noticed similar error on MAC and we are stuck at the moment. In the meantime shared few initial comments in general on your gerrit patch: https://git.eclipse.org/r/#/c/159486/
(In reply to Niraj Modi from comment #50) > Hi Guillermo, > > I tried out the gerrit patches on Windows10, but couldn't get the setup > working. > > It would be helpful if you could share some step by step detail for us to > try, on how to test your gerrit patches.(Also a separate set of steps: On > how to build the dlls from your source code locally on our side will be > helpful to test your patches throughly) > Currently while testing your gerrit patches(source/binaries) we are getting > below error while running JUnits from > Test_org_eclipse_swt_browser_Chromium.java: > ----------------------------------------------------------------------------- > --- > Running > Test_org_eclipse_swt_browser_Browser#test_BrowserFunction_callback_with_javaR > eturningString > SWT.CHROMIUM style was used but chromium.swt win32 (or CEF binaries) > fragment/jar is missing. > ----------------------------------------------------------------------------- > ---- > Note: Lakshmi too noticed similar error on MAC and we are stuck at the > moment. > > In the meantime shared few initial comments in general on your gerrit patch: > https://git.eclipse.org/r/#/c/159486/ Hi, I have updated the swt review with preview fixes for the build. Please find steps to run tests, examples and build natives in the gerrit review commit message.
(In reply to Guillermo Zunino from comment #51) > Hi, I have updated the swt review with preview fixes for the build. > Please find steps to run tests, examples and build natives in the gerrit > review commit message. @Guillermo, Thanks for the steps. I was able to run the snippets and tests on Mac with the Chromium binaries downloaded from [1]. I've posted comments in Bug 405031. Since there are multiple topics, I suggest we continue to keep Bug 405031 (and gerrit) for comments on the code/testing and this bug for discussions on the contribution such as CQ, license, build. [1] - http://opensource.spotify.com/cefbuilds/cef_binary_3.3071.1649.g98725e6_macosx64_minimal.tar.bz2
(In reply to Guillermo Zunino from comment #49) > Hi Lakshmi, this requires CEF binaries in place. Those binaries can be > obtained from: > - Our P2 repository, which has custom builds with some patches and > optimizations, and ensures compatibility with java and swt. > - http://opensource.spotify.com/cefbuilds/index.html. Works in mac and > windows. Currently doesn't work on linux due those are linked to gtk2 and > swt is gtk3 only. > - CEF Binaries can be build by anyone, with different args (linked to gtk3 > for example), customized for specific purposes, enabling/disabling parts, > etc. > Hi Guillermo, thanks for your response. Please see comments inline. > I think saying that *only* works with our P2 repo is not correct. I think atleast for Linux it's true since the patch doesn't work with the official builds. Someone can build them from source, but are the required changes/customization documented to make it work? For Mac, I tried the official builds and they worked fine. > With that > said, here are the answers for your question: > > 1. Not that I'm aware. As was discussed previously in the original bug, my > understanding was that CEF binaries should be keep outside eclipse. The CEF binaries is a third party dependency and will be outside eclipse. The question was if it's allowed/approved to fork CEF and distribute the binaries. > 2. There is "no license" in our cef P2 repository as this was not decided at > the moment of creation. I don't have any issue with specifying it as BSD > license which is the license of CEF project. I have no problem to republish > the p2 repo with explicit BSD license if required. I checked with the Eclipse license team on this. Quoting their response here: "Chromium is released under the BSD-3-Clause License, however, other parts are subject to a variety of other licenses (MIT, LGPL, Ms-PL, etc.). I would encourage ensuring the applicable license information is addressed to ensure consumers are made aware of the applicable licensing even from the workswith point of view." Can you please specify the license in the repo? It is important for the CQ and for clients looking to use/distribute the CEF binaries from your p2 repo. I'll open a separate "Workswith" third party CQ for dependency on the CEF binaries from the p2 repo. A couple of questions: 1. Is the source code or documentation of the changes in your fork available somewhere (github?), so that anyone interested can look at the changes and apply them? 2. Have you considered contributing the changes back to CEF so that they are part of the official builds?
(In reply to Lakshmi Shanmugam from comment #53) > (In reply to Guillermo Zunino from comment #49) > > Hi Lakshmi, this requires CEF binaries in place. Those binaries can be > > obtained from: > > - Our P2 repository, which has custom builds with some patches and > > optimizations, and ensures compatibility with java and swt. > > - http://opensource.spotify.com/cefbuilds/index.html. Works in mac and > > windows. Currently doesn't work on linux due those are linked to gtk2 and > > swt is gtk3 only. > > - CEF Binaries can be build by anyone, with different args (linked to gtk3 > > for example), customized for specific purposes, enabling/disabling parts, > > etc. > > > > Hi Guillermo, thanks for your response. Please see comments inline. > > > I think saying that *only* works with our P2 repo is not correct. > > I think atleast for Linux it's true since the patch doesn't work with the > official builds. Someone can build them from source, but are the required > changes/customization documented to make it work? > For Mac, I tried the official builds and they worked fine. > > > With that > > said, here are the answers for your question: > > > > 1. Not that I'm aware. As was discussed previously in the original bug, my > > understanding was that CEF binaries should be keep outside eclipse. > > The CEF binaries is a third party dependency and will be outside eclipse. > The question was if it's allowed/approved to fork CEF and distribute the > binaries. > > > 2. There is "no license" in our cef P2 repository as this was not decided at > > the moment of creation. I don't have any issue with specifying it as BSD > > license which is the license of CEF project. I have no problem to republish > > the p2 repo with explicit BSD license if required. > > I checked with the Eclipse license team on this. Quoting their response > here: > "Chromium is released under the BSD-3-Clause License, however, other parts > are subject to a variety of other licenses (MIT, LGPL, Ms-PL, etc.). I > would encourage ensuring the applicable license information is addressed to > ensure consumers are made aware of the applicable licensing even from the > workswith point of view." > > Can you please specify the license in the repo? It is important for the CQ > and for clients looking to use/distribute the CEF binaries from your p2 repo. > > I'll open a separate "Workswith" third party CQ for dependency on the CEF > binaries from the p2 repo. > > A couple of questions: > 1. Is the source code or documentation of the changes in your fork available > somewhere (github?), so that anyone interested can look at the changes and > apply them? > > 2. Have you considered contributing the changes back to CEF so that they are > part of the official builds? Hi Lakshmi, P2 Repo http://dl.maketechnology.io/chromium-cef/rls/repository is republished with license information (BSD and in compliance with CEF project). Regarding required changes for the linux build, see answers below to you questions: 1. Those changes are available in CEF project, involve applying one patch and building with use_gtk3=true, respectively discussed on these issues: - https://bitbucket.org/chromiumembedded/cef/issues/1936/ - https://bitbucket.org/chromiumembedded/cef/issues/2014/ 2. Changes are already applied in more recent versions.
(In reply to Guillermo Zunino from comment #54) > Hi Lakshmi, > > P2 Repo http://dl.maketechnology.io/chromium-cef/rls/repository is > republished with license information (BSD and in compliance with CEF > project). Thanks Guillermo, I've opened a 3rd party dependency CQ for using CEF binaries from the P2 repo - https://dev.eclipse.org/ipzilla/show_bug.cgi?id=22202 > > Regarding required changes for the linux build, see answers below to you > questions: > > 1. Those changes are available in CEF project, involve applying one patch > and building with use_gtk3=true, respectively discussed on these issues: > - https://bitbucket.org/chromiumembedded/cef/issues/1936/ > - https://bitbucket.org/chromiumembedded/cef/issues/2014/ > 2. Changes are already applied in more recent versions. Thanks, that's good to know. What will be the effort involved to support newer CEF versions? Do you plan to provide support for the latest/recent CEF versions after the initial implementation is merged?
(In reply to Lakshmi Shanmugam from comment #55) > (In reply to Guillermo Zunino from comment #54) > > Hi Lakshmi, > > > > P2 Repo http://dl.maketechnology.io/chromium-cef/rls/repository is > > republished with license information (BSD and in compliance with CEF > > project). > > Thanks Guillermo, I've opened a 3rd party dependency CQ for using CEF > binaries from the P2 repo - > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=22202 > > > > > Regarding required changes for the linux build, see answers below to you > > questions: > > > > 1. Those changes are available in CEF project, involve applying one patch > > and building with use_gtk3=true, respectively discussed on these issues: > > - https://bitbucket.org/chromiumembedded/cef/issues/1936/ > > - https://bitbucket.org/chromiumembedded/cef/issues/2014/ > > 2. Changes are already applied in more recent versions. > > Thanks, that's good to know. > What will be the effort involved to support newer CEF versions? Do you plan > to provide support for the latest/recent CEF versions after the initial > implementation is merged? Yes, version 68 or 69 should be the next one, which we have in good state. And newer versions are being worked also.
(In reply to Guillermo Zunino from comment #45) > Hi Lakshmi, > > I added the binaries to gerrit https://git.eclipse.org/r/#/c/159487/ > > Regarding jenkins, I looked to jenkins builds, but I don't know where can I > propose changes to the machine/docker definitions in order to install Rust > for those. That should be the only change for jenkins to be able to build > the binaries. > @Guillermo, I'm working on setting up the build. I've opened bugs to have Rust installed and download CEF minimal distribution on the build machines. 1. The build job will copy the extracted CEF package to the required location before the build starts. 2. The native builds don't use maven, but directly execute the build scripts. On Mac, for example, this is the call: sh build.sh install So, for chromium library to be built, I'll change it to: sh build.sh install make_chromium 3. I'm not sure how to invoke the build for the rust part from build.sh. May be we can have a separate job to build the rust code only when required? Is there a way to detect when the rust code needs to be built?
(In reply to Lakshmi Shanmugam from comment #57) > (In reply to Guillermo Zunino from comment #45) > > Hi Lakshmi, > > > > I added the binaries to gerrit https://git.eclipse.org/r/#/c/159487/ > > > > Regarding jenkins, I looked to jenkins builds, but I don't know where can I > > propose changes to the machine/docker definitions in order to install Rust > > for those. That should be the only change for jenkins to be able to build > > the binaries. > > > > @Guillermo, > I'm working on setting up the build. I've opened bugs to have Rust installed > and download CEF minimal distribution on the build machines. > > 1. The build job will copy the extracted CEF package to the required > location before the build starts. > > 2. The native builds don't use maven, but directly execute the build scripts. > On Mac, for example, this is the call: > sh build.sh install > > So, for chromium library to be built, I'll change it to: > sh build.sh install make_chromium > > 3. I'm not sure how to invoke the build for the rust part from build.sh. > May be we can have a separate job to build the rust code only when required? > Is there a way to detect when the rust code needs to be built? Hi Lakshmi, I think this is mostly implemented (I follow the same patterns than the swt fragments, so the same approach should work). 1) This is implemented already in getCef ant target: Downloads CEF zip and expands: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486/9/bundles/org.eclipse.swt.browser.chromium/buildChromium.xml#34 2) I followed same patterns than swt fragments. ant call for rust build and the jni libs: https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/159487/6/bundles/org.eclipse.swt.browser.chromium.gtk.linux.x86_64/pom.xml#93 https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/159487/6/bundles/org.eclipse.swt.browser.chromium.gtk.linux.x86_64/pom.xml#107 Normal Build.sh for the C jni libs extended with and env var: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486/9/bundles/org.eclipse.swt/buildSWT.xml#795 For the jni libs targets property is passed to build.sh, so I think it should be build.sh chromium_install (for linux and mac) build.bat chromium_install (for win) 3) I didn't put it in build.sh as I thought it was initiated from ant (or mvn). See Rust build command in ant: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486/9/bundles/org.eclipse.swt.browser.chromium/buildChromium.xml#53 The test depends on the output of getCef target. The rust code needs to be build when there is any change on bundles/org.eclipse.swt.browser.chromium/common/rust-library. If /target folder is keep between builds, cargo detects if it needs to build anything or not. How is this handled for swt jni libs?
(In reply to Guillermo Zunino from comment #58) > > Hi Lakshmi, I think this is mostly implemented (I follow the same patterns > than the swt fragments, so the same approach should work). Hi Guillermo, The build machine uses Ant script to build the SWT fragments. But the natives are built on separate Windows/Linux/Mac machines without Ant. Please see this wiki page https://wiki.eclipse.org/SWT/Native_Builds_on_Foundation for the detailed steps and links to view the jobs. copy_library_src_and_create_zip target in buildSWT.xml creates a zip of library sources for each platform based on ${library_src}. We need to now make sure that the required chromium sources are also zipped so that they can be copied to the native build machines. > > 1) This is implemented already in getCef ant target: > Downloads CEF zip and expands: > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486/9/bundles/ > org.eclipse.swt.browser.chromium/buildChromium.xml#34 https://bugs.eclipse.org/bugs/show_bug.cgi?id=564825#c4 > > 2) I followed same patterns than swt fragments. > ant call for rust build and the jni libs: > https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/159487/ > 6/bundles/org.eclipse.swt.browser.chromium.gtk.linux.x86_64/pom.xml#93 > https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/159487/ > 6/bundles/org.eclipse.swt.browser.chromium.gtk.linux.x86_64/pom.xml#107 > > Normal Build.sh for the C jni libs extended with and env var: > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486/9/bundles/ > org.eclipse.swt/buildSWT.xml#795 > > For the jni libs targets property is passed to build.sh, so I think it > should be > build.sh chromium_install (for linux and mac) > build.bat chromium_install (for win) As described in the wiki, Ant is used for building the SWT fragments, but for building the natives we directly execute the build scripts - build.sh/bat. I'll update the target in the native build jobs to build chromium libs. > > 3) I didn't put it in build.sh as I thought it was initiated from ant (or > mvn). See Rust build command in ant: > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486/9/bundles/ > org.eclipse.swt.browser.chromium/buildChromium.xml#53 > The test depends on the output of getCef target. Is it possible to have the cargo commands in build.sh or make file or a separate file such as buildRust.sh which can be invoked directly? > > The rust code needs to be build when there is any change on > bundles/org.eclipse.swt.browser.chromium/common/rust-library. If /target > folder is keep between builds, cargo detects if it needs to build anything > or not. > How is this handled for swt jni libs? This is checked in the check_natives_changed target [1] and natives_changed is set to true if natives need to be rebuilt. [1] https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/buildSWT.xml#n463 Can a similar check be added for building rust code?
(In reply to Lakshmi Shanmugam from comment #59) > (In reply to Guillermo Zunino from comment #58) > > > > Hi Lakshmi, I think this is mostly implemented (I follow the same patterns > > than the swt fragments, so the same approach should work). > > Hi Guillermo, > The build machine uses Ant script to build the SWT fragments. But the > natives are built on separate Windows/Linux/Mac machines without Ant. Please > see this wiki page https://wiki.eclipse.org/SWT/Native_Builds_on_Foundation > for the detailed steps and links to view the jobs. > > copy_library_src_and_create_zip target in buildSWT.xml creates a zip of > library sources for each platform based on ${library_src}. We need to now > make sure that the required chromium sources are also zipped so that they > can be copied to the native build machines. > > > > > > 1) This is implemented already in getCef ant target: > > Downloads CEF zip and expands: > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486/9/bundles/ > > org.eclipse.swt.browser.chromium/buildChromium.xml#34 > https://bugs.eclipse.org/bugs/show_bug.cgi?id=564825#c4 > > > > > 2) I followed same patterns than swt fragments. > > ant call for rust build and the jni libs: > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/159487/ > > 6/bundles/org.eclipse.swt.browser.chromium.gtk.linux.x86_64/pom.xml#93 > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/159487/ > > 6/bundles/org.eclipse.swt.browser.chromium.gtk.linux.x86_64/pom.xml#107 > > > > Normal Build.sh for the C jni libs extended with and env var: > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486/9/bundles/ > > org.eclipse.swt/buildSWT.xml#795 > > > > For the jni libs targets property is passed to build.sh, so I think it > > should be > > build.sh chromium_install (for linux and mac) > > build.bat chromium_install (for win) > As described in the wiki, Ant is used for building the SWT fragments, but > for building the natives we directly execute the build scripts - > build.sh/bat. I'll update the target in the native build jobs to build > chromium libs. > > > > > 3) I didn't put it in build.sh as I thought it was initiated from ant (or > > mvn). See Rust build command in ant: > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486/9/bundles/ > > org.eclipse.swt.browser.chromium/buildChromium.xml#53 > > The test depends on the output of getCef target. > Is it possible to have the cargo commands in build.sh or make file or a > separate file such as buildRust.sh which can be invoked directly? > > > > > The rust code needs to be build when there is any change on > > bundles/org.eclipse.swt.browser.chromium/common/rust-library. If /target > > folder is keep between builds, cargo detects if it needs to build anything > > or not. > > How is this handled for swt jni libs? > > This is checked in the check_natives_changed target [1] and natives_changed > is set to true if natives need to be rebuilt. > [1] > https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org. > eclipse.swt/buildSWT.xml#n463 > Can a similar check be added for building rust code? Thanks for exaplanation. I'll work ensuring these ant tasks work as expected for chromium and also add a cargoBuild.sh or similar to build the rust native.
Hi Lakshmi I added a few changes in order to create the natives builds in jenkins. A brief summary of modified ant task: - check_compilation will do it also for chromium bundle - new_build_with_create_file checks for natives and rust code will create files as expected We could create an specific chromium_changed file but I believe anytime swt binaries are changed (or chromium files) we should rebuild chromium binaries, due the swt version is part of the name of the binaries and java code uses the the swt version to load the binaries. If you see other alternative please let me known. - copy_library_src_and_create_zip called on the chromium platform fragment will create the corresponding zip as expected with the same swt patterns. e.g: `eclipse.platform.swt.binaries/bundles/org.eclipse.swt.browser.chromium.gtk.linux.x86_64/build.xml copy_library_src_and_create_zip` will create eclipse.platform.swt.binaries/bundles/org.eclipse.swt.browser.chromium.gtk.linux.x86_64/tmpdir/org.eclipse.swt.browser.chromium.gtk.linux.x86_64.master.zip with c and rust code to be build in native job - For the jenkins native build: You can modify existing native build jobs to build chromium natives also or add new jobs specific for chromium. The script should get the swt chromium zip from previous step and unzip as usual. unzip cef_binaries to chromium_subp/cef_[linux|win32|macosx] (root folder in zip should be cut) export MODEL=x86_64 (or equivalent for win) export CHROMIUM_OUTPUT_DIR=build/libs or (equivalent for win) sh build.sh chromium_cargo chromium_install (for linux and mac) cmd /c build.bat x86_64 chromium_cargo chromium_install (for win) This will build cargo first and jni later and put all the binaries in libs/chromium-${cef_ver}/* zip libs/ as usual to be retrieved in main job - When copying in main job script, libs/ folder should be copied to corresponding chromium fragment (please note that old binaries should be removed and new added, a warn on mac because there is a .app subfolder with binaries and non-binaries) - check_fragment_libraries will also check for correct version of chromium binaries I think this is all you need and will allow to build chromium bins with minimal changes in current scripts and jobs. But let me known if I'm missing anything or you want me to propose the changes in the jenkins build scripts also. Regards
(In reply to Guillermo Zunino from comment #61) Thanks Guillermo! I'm working on the changes required in the build jobs. Once done, we are planning to merge the changes. I'll let you know if any changes are required in the build scripts. The CQ [1] is not yet approved and is in awaiting_analysis state. But we have been asked to proceed with checkin - https://dev.eclipse.org/ipzilla/show_bug.cgi?id=21808#c13 [1] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=21808
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/166344
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/166344 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=efb32fb17a784ec9d1d29a0b3c173e274b0b9326
The CQ - https://dev.eclipse.org/ipzilla/show_bug.cgi?id=21808 for this contribution has been approved! We are working on the Jenkins jobs required to build the natives. The Mac and Windows native build jobs are successful, but Windows job still needs to be fixed. Once all jobs are successful, we are planning to merge the gerrit patches to master.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/159487 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=122461b3cb3c5415ab9c74a3ca66dfbe480c89f8
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=c62af75bc70ad566bb1cf083a0e728ee5d06fbaf
(In reply to Eclipse Genie from comment #67) > Gerrit change > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486 was > merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=c62af75bc70ad566bb1cf083a0e728ee5d06fbaf This triggers API error in IDE: The micro version is increased unnecessarily since either major or minor version is already increased MANIFEST.MF /org.eclipse.swt/META-INF line 5 Should we revert the version it ASAP (only today build is affected) or should we mute the error?
(In reply to Andrey Loskutov from comment #68) > > Should we revert the version it ASAP (only today build is affected) or > should we mute the error? We should revert, the build was not done yet!
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/166495
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166496
(In reply to Andrey Loskutov from comment #68) > (In reply to Eclipse Genie from comment #67) > > Gerrit change > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486 was > > merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=c62af75bc70ad566bb1cf083a0e728ee5d06fbaf > > This triggers API error in IDE: > The micro version is increased unnecessarily since either major or minor > version is already increased MANIFEST.MF /org.eclipse.swt/META-INF line 5 > > Should we revert the version it ASAP (only today build is affected) or > should we mute the error? I added a api filter for this in the patch, not sure what happened. I'm checking. This change was required for the build, please see the gerrit comments.
(In reply to Lakshmi Shanmugam from comment #72) > This change was required for the build, please see the gerrit > comments. I don't know which gerrit you mean, I don't see why it was needed. However, I see that new ant build files still refer to the old (wrong) minor version of SWT, may be this was the problem? https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/166495/1/bundles/org.eclipse.swt.browser.chromium.win32.win32.x86_64/build.xml#22
(In reply to Andrey Loskutov from comment #73) > (In reply to Lakshmi Shanmugam from comment #72) > > This change was required for the build, please see the gerrit > > comments. > > I don't know which gerrit you mean, I don't see why it was needed. Please see https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486 > > However, I see that new ant build files still refer to the old (wrong) minor > version of SWT, may be this was the problem? > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/166495/ > 1/bundles/org.eclipse.swt.browser.chromium.win32.win32.x86_64/build.xml#22 Both source and fragments have the same version 3.115.100
(In reply to Lakshmi Shanmugam from comment #74) > (In reply to Andrey Loskutov from comment #73) > > (In reply to Lakshmi Shanmugam from comment #72) > > > This change was required for the build, please see the gerrit > > > comments. > > > > I don't know which gerrit you mean, I don't see why it was needed. > Please see https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486 I don't see anything there what would explain why do we need a service version bump in 4.17, if we've already increased minor segment. > > However, I see that new ant build files still refer to the old (wrong) minor > > version of SWT, may be this was the problem? > > > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/166495/ > > 1/bundles/org.eclipse.swt.browser.chromium.win32.win32.x86_64/build.xml#22 > > Both source and fragments have the same version 3.115.100 I believe you didn't understand me. Ant build files in the *merged* patch still refer to *old* 3.114.0 version. This seem to be an error!
(In reply to Andrey Loskutov from comment #75) > (In reply to Lakshmi Shanmugam from comment #74) > > (In reply to Andrey Loskutov from comment #73) > > > (In reply to Lakshmi Shanmugam from comment #72) > > > > This change was required for the build, please see the gerrit > > > > comments. > > > > > > I don't know which gerrit you mean, I don't see why it was needed. > > Please see https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486 > > I don't see anything there what would explain why do we need a service > version bump in 4.17, if we've already increased minor segment. Without the version increment the comparator was giving errors. Comments from the gerrit: [WARNING] MavenProject: org.eclipse.swt:org.eclipse.swt.win32.win32.x86_64:3.115.0-SNAPSHOT @ /home/guille/ws/swt-master-ws/git/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.win32.win32.x86_64/pom.xml: baseline and build artifacts have same version but different contents no-classifier: different org/eclipse/swt/SWT.class: different ... [INFO] MavenProject: org.eclipse.swt:org.eclipse.swt.win32.win32.x86_64:3.115.0-SNAPSHOT @ /home/guille/ws/swt-master-ws/git/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.win32.win32.x86_64/pom.xml The main artifact has been replaced with the baseline version. The following attached artifacts have been replaced with the baseline version: [sources] This cause later the failure of browser.chromium fragments build due is not using the new code of swt sources. This was the orignal reason why I increment the .micro version to .100. The explanation given was: During the maven build we do run a component called comparator. This checks the contents of newly built jar with already available jar from latest I-build. If the version along with qualifier matches with already available jar, the newly built jar is thrown away. A warning is shown if the contents are changed between both.
(In reply to Lakshmi Shanmugam from comment #76) > (In reply to Andrey Loskutov from comment #75) > > (In reply to Lakshmi Shanmugam from comment #74) > > > (In reply to Andrey Loskutov from comment #73) > > > > (In reply to Lakshmi Shanmugam from comment #72) > > > > > This change was required for the build, please see the gerrit > > > > > comments. > > > > > > > > I don't know which gerrit you mean, I don't see why it was needed. > > > Please see https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486 > > > > I don't see anything there what would explain why do we need a service > > version bump in 4.17, if we've already increased minor segment. > > Without the version increment the comparator was giving errors. > Comments from the gerrit: > > [WARNING] MavenProject: > org.eclipse.swt:org.eclipse.swt.win32.win32.x86_64:3.115.0-SNAPSHOT @ > /home/guille/ws/swt-master-ws/git/eclipse.platform.swt.binaries/bundles/org. > eclipse.swt.win32.win32.x86_64/pom.xml: baseline and build artifacts have > same version but different contents > no-classifier: different > org/eclipse/swt/SWT.class: different > ... > [INFO] MavenProject: > org.eclipse.swt:org.eclipse.swt.win32.win32.x86_64:3.115.0-SNAPSHOT @ > /home/guille/ws/swt-master-ws/git/eclipse.platform.swt.binaries/bundles/org. > eclipse.swt.win32.win32.x86_64/pom.xml > The main artifact has been replaced with the baseline version. > The following attached artifacts have been replaced with the baseline > version: [sources] > > This cause later the failure of browser.chromium fragments build due is not > using the new code of swt sources. > This was the orignal reason why I increment the .micro version to .100. > > The explanation given was: > > During the maven build we do run a component called comparator. This checks > the contents of newly built jar with already available jar from latest > I-build. If the version along with qualifier matches with already available > jar, the newly built jar is thrown away. A warning is shown if the contents > are changed between both. comment continued: In other eclipse bundles tycho maven plugins calculate the qualifier based on last commit's timestamp. But in case of SWT, qualifier is provided by build input jobs. That's the reason you have same qualifier. The way to fix it is to increment micro version for now. You won't see this problem when we integrate with build input jobs
(In reply to Lakshmi Shanmugam from comment #77) > (In reply to Lakshmi Shanmugam from comment #76) > > (In reply to Andrey Loskutov from comment #75) > > > (In reply to Lakshmi Shanmugam from comment #74) > > > > (In reply to Andrey Loskutov from comment #73) > > > > > (In reply to Lakshmi Shanmugam from comment #72) > > > > > > This change was required for the build, please see the gerrit > > > > > > comments. > > > > > > > > > > I don't know which gerrit you mean, I don't see why it was needed. > > > > Please see https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486 > > > > > > I don't see anything there what would explain why do we need a service > > > version bump in 4.17, if we've already increased minor segment. > > > > Without the version increment the comparator was giving errors. > > Comments from the gerrit: > > > > [WARNING] MavenProject: > > org.eclipse.swt:org.eclipse.swt.win32.win32.x86_64:3.115.0-SNAPSHOT @ > > /home/guille/ws/swt-master-ws/git/eclipse.platform.swt.binaries/bundles/org. > > eclipse.swt.win32.win32.x86_64/pom.xml: baseline and build artifacts have > > same version but different contents > > no-classifier: different > > org/eclipse/swt/SWT.class: different > > ... > > [INFO] MavenProject: > > org.eclipse.swt:org.eclipse.swt.win32.win32.x86_64:3.115.0-SNAPSHOT @ > > /home/guille/ws/swt-master-ws/git/eclipse.platform.swt.binaries/bundles/org. > > eclipse.swt.win32.win32.x86_64/pom.xml > > The main artifact has been replaced with the baseline version. > > The following attached artifacts have been replaced with the baseline > > version: [sources] > > > > This cause later the failure of browser.chromium fragments build due is not > > using the new code of swt sources. > > This was the orignal reason why I increment the .micro version to .100. I'm sorry, could you please give a direct link to this? I'm unable to see where it was commented on Gerrit or which build was failing. > > The explanation given was: > > > > During the maven build we do run a component called comparator. This checks > > the contents of newly built jar with already available jar from latest > > I-build. If the version along with qualifier matches with already available > > jar, the newly built jar is thrown away. A warning is shown if the contents > > are changed between both. > > comment continued: > > In other eclipse bundles tycho maven plugins calculate the qualifier based > on last commit's timestamp. But in case of SWT, qualifier is provided by > build input jobs. That's the reason you have same qualifier. The way to fix > it is to increment micro version for now. You won't see this problem when we > integrate with build input jobs This was a wrong solution IMHO. In SWT we have to set forceContextQualifier in pom XML to the new version if we have new native build, in both native/not native repositories. This way you can supply new native bits without incrementing already incremented verion.
(In reply to Andrey Loskutov from comment #78) > (In reply to Lakshmi Shanmugam from comment #77) > > (In reply to Lakshmi Shanmugam from comment #76) > > > (In reply to Andrey Loskutov from comment #75) > > > > (In reply to Lakshmi Shanmugam from comment #74) > > > > > (In reply to Andrey Loskutov from comment #73) > > > > > > (In reply to Lakshmi Shanmugam from comment #72) > > > > > > > This change was required for the build, please see the gerrit > > > > > > > comments. > > > > > > > > > > > > I don't know which gerrit you mean, I don't see why it was needed. > > > > > Please see https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486 > > > > > > > > I don't see anything there what would explain why do we need a service > > > > version bump in 4.17, if we've already increased minor segment. > > > > > > Without the version increment the comparator was giving errors. > > > Comments from the gerrit: > > > > > > [WARNING] MavenProject: > > > org.eclipse.swt:org.eclipse.swt.win32.win32.x86_64:3.115.0-SNAPSHOT @ > > > /home/guille/ws/swt-master-ws/git/eclipse.platform.swt.binaries/bundles/org. > > > eclipse.swt.win32.win32.x86_64/pom.xml: baseline and build artifacts have > > > same version but different contents > > > no-classifier: different > > > org/eclipse/swt/SWT.class: different > > > ... > > > [INFO] MavenProject: > > > org.eclipse.swt:org.eclipse.swt.win32.win32.x86_64:3.115.0-SNAPSHOT @ > > > /home/guille/ws/swt-master-ws/git/eclipse.platform.swt.binaries/bundles/org. > > > eclipse.swt.win32.win32.x86_64/pom.xml > > > The main artifact has been replaced with the baseline version. > > > The following attached artifacts have been replaced with the baseline > > > version: [sources] > > > > > > This cause later the failure of browser.chromium fragments build due is not > > > using the new code of swt sources. > > > This was the orignal reason why I increment the .micro version to .100. > > > I'm sorry, could you please give a direct link to this? I'm unable to see > where it was commented on Gerrit or which build was failing. https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486/17#message-0969767871c88cf7f646938faab0ce839fee0eba https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486/17#message-dae24f5d37518b7db6ab3217a426cc3074ab6d7a https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/159486/17#message-019bc6654e9d966df7615501195a6dbdecfa1f39 > > > > > The explanation given was: > > > > > > During the maven build we do run a component called comparator. This checks > > > the contents of newly built jar with already available jar from latest > > > I-build. If the version along with qualifier matches with already available > > > jar, the newly built jar is thrown away. A warning is shown if the contents > > > are changed between both. > > > > comment continued: > > > > In other eclipse bundles tycho maven plugins calculate the qualifier based > > on last commit's timestamp. But in case of SWT, qualifier is provided by > > build input jobs. That's the reason you have same qualifier. The way to fix > > it is to increment micro version for now. You won't see this problem when we > > integrate with build input jobs > > This was a wrong solution IMHO. > > In SWT we have to set forceContextQualifier in pom XML to the new version if > we have new native build, in both native/not native repositories. This way > you can supply new native bits without incrementing already incremented > verion. forceContextQualifier is updated by our native build jobs. Not sure how it's done with maven. Sravan & Alex can you please comment here?
(In reply to Andrey Loskutov from comment #75) > > > > However, I see that new ant build files still refer to the old (wrong) minor > > > version of SWT, may be this was the problem? > > > > > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/166495/ > > > 1/bundles/org.eclipse.swt.browser.chromium.win32.win32.x86_64/build.xml#22 > > > > Both source and fragments have the same version 3.115.100 > > I believe you didn't understand me. Ant build files in the *merged* patch > still refer to *old* 3.114.0 version. This seem to be an error! Sorry, I understand now. Looks like the build.xml was missed in the last few version updates, this should be fixed.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/166507
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166513
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166519
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166519 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0f6946f24b098a7c487f0d53bde3a91b3efa5181
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166521
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/166507 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=48d35b308197755e02a419741c63f1c63b972aaa
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166521 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=9a3bd8a2b20676d51b1ad93af06321e71f3377a0
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166496 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=414d3418d9ac325832b9b4c0ebcff9d9f0ed3f10
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/166495 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=5311829282e1dd136a29f17538cef29c57221360
(In reply to Eclipse Genie from comment #89) > Gerrit change > https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/166495 > was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/ > ?id=5311829282e1dd136a29f17538cef29c57221360 Version changed to 3.115.0 and started an I-build for testing. Thanks Andrey for the patches.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166528
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166528 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=8b80cc4bfc57135722076bf70a4d5fe10fbdece5
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166535
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166535 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=7130ffe14997d4fc266929ca1e3b7f1f61d40878
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166513 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=1f2e44e883d74d8c024d27f9377a525fee7ca5c2
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166545
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/166545 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=914b0b9901ef4cbc966dfafc4c14829b7d5b9c64
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/166565
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/166565 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=5771767d581e8ba7e9e073f9ba857aab5bd60921
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/166578
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/166582
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/166578 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=84ad0c3717c1ed680b0f8eb350cd4d115a64aea5
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/166582 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=0271e835742a8c4a832c9548c0f54d1538ee881f
I haven't checked patches: what do I need to do to test the chromium on Linux? Some env. variable? System property?
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/166633
(In reply to Andrey Loskutov from comment #104) > I haven't checked patches: what do I need to do to test the chromium on > Linux? Some env. variable? System property? There is new SWT.CHROMIUM constant that can be used in the Browser. The latest SDK build has the chromium fragments. Also standalone swt-chromium jars are available in the build page. On testing we found some issues (please see dependent bugs), will update here once the Chromium support can be tested.
@Guillermo, We have merged the patches and the fragments and standalone jars are being built now - https://download.eclipse.org/eclipse/downloads/drops4/I20200722-0610/#SWTChromium But, we are unable to launch the Browser with Chromium style. Please take a look - Bug 565434.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/166695
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/166695 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=2929f6ec5aaee8d45efbefcb6ab9ff725f9a2c83
Guilermo, I have few questions: 1. Is there any developer documentation on how one is supposed to work on the chromium part of swt now? 2. Is there plan to update to newer version ? v59 is ancient by all means 3. What happens with Wayland support? Significant (and constantly growing) part of Linux users are on Wayland so write not chrome support in swt is a no go for them.
Trying cargo build myself ends up with: [akurtakov@localhost chromium_subp]$ cargo build Compiling chromium v59.0.0 (/home/akurtakov/git/eclipse.platform.swt/bundles/org.eclipse.swt.browser.chromium/common/rust-library/chromium_subp) error: failed to run custom build command for `chromium v59.0.0 (/home/akurtakov/git/eclipse.platform.swt/bundles/org.eclipse.swt.browser.chromium/common/rust-library/chromium_subp)` Caused by: process didn't exit successfully: `/home/akurtakov/git/eclipse.platform.swt/bundles/org.eclipse.swt.browser.chromium/common/rust-library/chromium_subp/target/debug/build/chromium-da684b80346454df/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'cargo:warning=Extract and rename cef binary (minimal) distro to "/home/akurtakov/git/eclipse.platform.swt/bundles/org.eclipse.swt.browser.chromium/common/rust-library/chromium_subp/cef_linux"', build.rs:58:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace active toolchain ---------------- stable-x86_64-unknown-linux-gnu (default) rustc 1.45.0 (5c1f21c3b 2020-07-13)
(In reply to Alexander Kurtakov from comment #110) Hi Alexander, > Guilermo, I have few questions: > 1. Is there any developer documentation on how one is supposed to work on > the chromium part of swt now? There is a super basic readme here: https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt.browser.chromium/common/rust-library/README.md And some old docs here: https://github.com/maketechnology/chromium.swt We could possible create something else. > 2. Is there plan to update to newer version ? v59 is ancient by all means Yes, v69 (mid 2019) will be contributed afterwards, once we fix some remaining issues and hopefully get feedback. More recent versions (2020) are work in progress also. Support is always welcome to go faster. > 3. What happens with Wayland support? Significant (and constantly growing) > part of Linux users are on Wayland so write not chrome support in swt is a > no go for them. Native Wayland should be possible when we move to more recent versions of chromium/cef. It does work in wayland today with XWayland.
(In reply to Guillermo Zunino from comment #112) > (In reply to Alexander Kurtakov from comment #110) > Hi Alexander, > > > Guilermo, I have few questions: > > 1. Is there any developer documentation on how one is supposed to work on > > the chromium part of swt now? > > There is a super basic readme here: > https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org. > eclipse.swt.browser.chromium/common/rust-library/README.md > > And some old docs here: https://github.com/maketechnology/chromium.swt > > We could possible create something else. Opened Bug 565507 > > > 2. Is there plan to update to newer version ? v59 is ancient by all means > > Yes, v69 (mid 2019) will be contributed afterwards, once we fix some > remaining issues and hopefully get feedback. More recent versions (2020) are > work in progress also. Support is always welcome to go faster. > Opened Bug 565508
The latest build has Eclipse SDK [1] with Chromium fragments and standalone swt-chromium.jar [2] [1] - https://download.eclipse.org/eclipse/downloads/drops4/I20200724-0600/#EclipseSDK [2] - https://download.eclipse.org/eclipse/downloads/drops4/I20200724-0600/#SWTChromium @Guillermo, Please take a look and verify if all the fragments and downloads are as expected?
(In reply to Lakshmi Shanmugam from comment #114) > The latest build has Eclipse SDK [1] with Chromium fragments and standalone > swt-chromium.jar [2] > > [1] - > https://download.eclipse.org/eclipse/downloads/drops4/I20200724-0600/ > #EclipseSDK > [2] - > https://download.eclipse.org/eclipse/downloads/drops4/I20200724-0600/ > #SWTChromium > > @Guillermo, > Please take a look and verify if all the fragments and downloads are as > expected? - I have reviewed swt and chromium downloads in the 3 platforms. Binaries and source content is correct and as expected. - I have run plain swt example ControlExample and BrowserExample from command line with -Dorg.eclipse.swt.browser.DefaultType=chromium like: java -XstartOnFirstThread -Dorg.eclipse.swt.browser.DefaultType=chromium -classpath swt.jar:org.eclipse.swt.examples_3.106.1000.v20200611-1332.jar:swt-chromium.jar:com.make.chromium.cef.cocoa.macosx.x86_64_0.4.0.202005172227.jar org.eclipse.swt.examples.browserexample.BrowserExample Chromium browser is started and works as expect in the 3 platform for BrowserExample and ControlExample Expanded binaries are properly signed. - I have downloaded Eclpse SDK application, modified Eclipse.ini adding -Dorg.eclipse.swt.browser.DefaultType=chromium Eclipse runs fine and opening Internal Browser view, Chromium browser is created and works as expected in the 3 platforms.
(In reply to Guillermo Zunino from comment #115) @Guillermo, thank you for verifying.
@All, Please try out the Chromium support and open new bugs for any issues. Steps: 1. Download the Eclipse SDK or standalone chromium jar from downloads page [1] 2. Set browser type to chromium using -Dorg.eclipse.swt.browser.DefaultType=chromium or set SWT.CHROMIUM style in the Browser constructor. 2. Install the cef binaries in Eclipse using p2 repo - http://dl.maketechnology.io/chromium-cef/rls/repository 3. Add the required jars to classpath of Browser Example, for example: - SWT-Chromium fragment (org.eclipse.swt.browser.chromium.cocoa.macosx.x86_64) - SWT fragment (org.eclipse.swt.cocoa.macosx.x86_64) - CEF binary (com.make.chromium.cef.cocoa.macosx.x86_64) 4. Launch the Browser Example. [1] - https://download.eclipse.org/eclipse/downloads/drops4/I20200724-0600/ or later I-builds
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/167121
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/167121 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=ba3bc6fa85ea480c65efdae3af477b7fafc2297d
(In reply to Eclipse Genie from comment #119) > Gerrit change > https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/167121 was merged > to [master]. > Commit: > http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/ > ?id=ba3bc6fa85ea480c65efdae3af477b7fafc2297d Added N&N and FAQ entry.
(In reply to Lakshmi Shanmugam from comment #117) > @All, Please try out the Chromium support and open new bugs for any issues. > > Steps: > > 1. Download the Eclipse SDK or standalone chromium jar from downloads page > [1] > > 2. Set browser type to chromium using > -Dorg.eclipse.swt.browser.DefaultType=chromium or set SWT.CHROMIUM style in > the Browser constructor. > > 2. Install the cef binaries in Eclipse using p2 repo - > http://dl.maketechnology.io/chromium-cef/rls/repository > > 3. Add the required jars to classpath of Browser Example, for example: > - SWT-Chromium fragment > (org.eclipse.swt.browser.chromium.cocoa.macosx.x86_64) > - SWT fragment (org.eclipse.swt.cocoa.macosx.x86_64) > - CEF binary (com.make.chromium.cef.cocoa.macosx.x86_64) > > 4. Launch the Browser Example. > > [1] - https://download.eclipse.org/eclipse/downloads/drops4/I20200724-0600/ > or later I-builds Just tested on Mac OS X 10.14.6 with Java 11.0.6 After step 2 an automated restart is done, which crashed hard giving A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fff789c4100, pid=43591, tid=775 # # JRE version: OpenJDK Runtime Environment (11.0.6+10) (build 11.0.6+10) # Java VM: OpenJDK 64-Bit Server VM (11.0.6+10, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64) # Problematic frame: # C [libsystem_platform.dylib+0x2100] _platform_strncmp+0x140 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # a manual restart of eclipse then worked without problems. I don't know what browser example you are writing about, but using the internal browser view of Eclipse then shows me (using https://www.whatismybrowser.com/) that my browser is Chrome 59. With the current snapshot build the Welcome view looks wierd (missing images) - but I don't think that this problem is related to chrome! Thanks a lot for the great work!!
(In reply to Marco Descher from comment #121) > (In reply to Lakshmi Shanmugam from comment #117) > > @All, Please try out the Chromium support and open new bugs for any issues. > > > > Steps: > > > > 1. Download the Eclipse SDK or standalone chromium jar from downloads page > > [1] > > > > 2. Set browser type to chromium using > > -Dorg.eclipse.swt.browser.DefaultType=chromium or set SWT.CHROMIUM style in > > the Browser constructor. > > > > 2. Install the cef binaries in Eclipse using p2 repo - > > http://dl.maketechnology.io/chromium-cef/rls/repository > > > > 3. Add the required jars to classpath of Browser Example, for example: > > - SWT-Chromium fragment > > (org.eclipse.swt.browser.chromium.cocoa.macosx.x86_64) > > - SWT fragment (org.eclipse.swt.cocoa.macosx.x86_64) > > - CEF binary (com.make.chromium.cef.cocoa.macosx.x86_64) > > > > 4. Launch the Browser Example. > > > > [1] - https://download.eclipse.org/eclipse/downloads/drops4/I20200724-0600/ > > or later I-builds > > Just tested on Mac OS X 10.14.6 with Java 11.0.6 > > After step 2 an automated restart is done, which crashed hard giving Thanks for testing! I tested on macOS 10.15.5 and Java 11, but I was unable to reproduce the crash. I added the property in the eclipse.ini under -vmargs. How did you set the chromium property? > > With the current snapshot build the Welcome view looks wierd (missing > images) - but I don't think that this problem is related to chrome! I'm able reproduce this and seems related to chromium. I see these multiple error messages like this in the console - "Not allowed to load local resource: file:///Applications/Eclipse%2014.app/Contents/Eclipse/configuration/org.eclipse.osgi/247/0/.cp/themes/shared/html/shared.css" Opened Bug 565832 to track this.
(In reply to Lakshmi Shanmugam from comment #122) > (In reply to Marco Descher from comment #121) > > Thanks for testing! > I tested on macOS 10.15.5 and Java 11, but I was unable to reproduce the > crash. > I added the property in the eclipse.ini under -vmargs. How did you set the > chromium property? > > > > > With the current snapshot build the Welcome view looks wierd (missing > > images) - but I don't think that this problem is related to chrome! > > I'm able reproduce this and seems related to chromium. I see these multiple > error messages like this in the console - "Not allowed to load local > resource: > file:///Applications/Eclipse%2014.app/Contents/Eclipse/configuration/org. > eclipse.osgi/247/0/.cp/themes/shared/html/shared.css" > > Opened Bug 565832 to track this. Yes, I added the flag under -vmargs, but I started Eclipse via the console with ./eclipse as starting it with double-click says that the "Executable is damaged and I should move it to the bin ..." I just re-tried with yesterdays drop (I20200804-1800). Eclipse crashed again on the same reboot setp with OS X giving me the stacktrace window. Here is a partial excerpt (I can send the entire one if required): ========== Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x00000001d3828000 Exception Note: EXC_CORPSE_NOTIFY VM Regions Near 0x1d3828000: VM_ALLOCATE 0000000100860000-0000000140000000 [ 1.0G] ---/rwx SM=NUL --> STACK GUARD 00007000082ba000-00007000082bb000 [ 4K] ---/rwx SM=NUL stack guard for thread 1 Application Specific Information: abort() called Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff789c02c2 __pthread_kill + 10 ========== # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fff78a6e100, pid=28650, tid=775 # # JRE version: OpenJDK Runtime Environment (11.0.6+10) (build 11.0.6+10) # Java VM: OpenJDK 64-Bit Server VM (11.0.6+10, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64) # Problematic frame: # C [libsystem_platform.dylib+0x2100] _platform_strncmp+0x140 ========== Again, a manual restart did work-out.
(In reply to Marco Descher from comment #123) > (In reply to Lakshmi Shanmugam from comment #122) > > (In reply to Marco Descher from comment #121) > > > > Thanks for testing! > > I tested on macOS 10.15.5 and Java 11, but I was unable to reproduce the > > crash. > > I added the property in the eclipse.ini under -vmargs. How did you set the > > chromium property? > > > > > > > > With the current snapshot build the Welcome view looks wierd (missing > > > images) - but I don't think that this problem is related to chrome! > > > > I'm able reproduce this and seems related to chromium. I see these multiple > > error messages like this in the console - "Not allowed to load local > > resource: > > file:///Applications/Eclipse%2014.app/Contents/Eclipse/configuration/org. > > eclipse.osgi/247/0/.cp/themes/shared/html/shared.css" > > > > Opened Bug 565832 to track this. > > Yes, I added the flag under -vmargs, but I started Eclipse via the console > with ./eclipse as starting it with double-click says that the "Executable is > damaged and I should move it to the bin ..." > Sorry, I should have reversed the order of these 2 steps: > 2. Set browser type to chromium using > -Dorg.eclipse.swt.browser.DefaultType=chromium or set SWT.CHROMIUM style in > the Browser constructor. > > 2. Install the cef binaries in Eclipse using p2 repo - > http://dl.maketechnology.io/chromium-cef/rls/repository On Mac, Eclipse.app is signed and it's signature is checked first time it is opened. Since eclipse.ini is inside Eclipse.app, if it's modified we get this message "Executable is damaged and I should move it to the bin ..." The workaround is to start Eclipse.app first time without any changes. Then modify eclipse.ini and start Eclipse.app. For me on macOS 10.15.5, trying to start eclipse with ./eclipse also gives the same error. I did't get the crash. However, this is not related to Chromium support, we should open a separate bug for the crash issue.
Do you know about a working mirror where the chromium binaries could be downloaded from? The link posted in the SWT FAQ looks outdated or is at least temporarily down: http://dl.maketechnology.io/chromium-cef/rls/repository/plugins/com.make.chromium.cef.win32.win.x86_64_0.4.0.202005172227.jar
(In reply to István Mészáros from comment #125) > Do you know about a working mirror where the chromium binaries could be > downloaded from? BTW, if you plan to use the Chromium libraries from the Eclipse SDK, try installing the CEF binaries in Eclipse from the p2 repo: http://dl.maketechnology.io/chromium-cef/rls/repository > The link posted in the SWT FAQ looks outdated or is at least temporarily > down: > http://dl.maketechnology.io/chromium-cef/rls/repository/plugins/com.make. > chromium.cef.win32.win.x86_64_0.4.0.202005172227.jar @Guillermo, Please check/confirm availability of above link.
(In reply to Niraj Modi from comment #126) > (In reply to István Mészáros from comment #125) > > Do you know about a working mirror where the chromium binaries could be > > downloaded from? > BTW, if you plan to use the Chromium libraries from the Eclipse SDK, try > installing the CEF binaries in Eclipse from the p2 repo: > http://dl.maketechnology.io/chromium-cef/rls/repository > > > The link posted in the SWT FAQ looks outdated or is at least temporarily > > down: > > http://dl.maketechnology.io/chromium-cef/rls/repository/plugins/com.make. > > chromium.cef.win32.win.x86_64_0.4.0.202005172227.jar > > @Guillermo, > Please check/confirm availability of above link. How are these generated ? IMHO if we want it to be considered seriously this should be github project with FOSS license so this can be evolved and alternative downloads provided
(In reply to Niraj Modi from comment #126) > BTW, if you plan to use the Chromium libraries from the Eclipse SDK, try > installing the CEF binaries in Eclipse from the p2 repo: > http://dl.maketechnology.io/chromium-cef/rls/repository Thanks for the hint, but my project is a standalone SWT app. BTW, i think that repo is also not working (i get access denied).
(In reply to István Mészáros from comment #128) > (In reply to Niraj Modi from comment #126) > > BTW, if you plan to use the Chromium libraries from the Eclipse SDK, try > > installing the CEF binaries in Eclipse from the p2 repo: > > http://dl.maketechnology.io/chromium-cef/rls/repository > > Thanks for the hint, but my project is a standalone SWT app. BTW, i think > that repo is also not working (i get access denied). Hi, The repo is available, is not navigable in a browser. You can explore it with Repository Explorer view in eclipse, for example. And there is a typo on the win link, it should be http://dl.maketechnology.io/chromium-cef/rls/repository/plugins/com.make.chromium.cef.win32.win32.x86_64_0.4.0.202005172227.jar instead of http://dl.maketechnology.io/chromium-cef/rls/repository/plugins/com.make.chromium.cef.win32.win.x86_64_0.4.0.202005172227.jar Thanks.
(In reply to Guillermo Zunino from comment #129) > (In reply to István Mészáros from comment #128) > > (In reply to Niraj Modi from comment #126) > And there is a typo on the win link, it should be > > http://dl.maketechnology.io/chromium-cef/rls/repository/plugins/com.make. > chromium.cef.win32.win32.x86_64_0.4.0.202005172227.jar > instead of > http://dl.maketechnology.io/chromium-cef/rls/repository/plugins/com.make. > chromium.cef.win32.win.x86_64_0.4.0.202005172227.jar > > > Thanks. Fixed the broken link.
Would you say it's reasonable to use the SWT Chromium support in an RCP-application based off of Eclipse 4.17 (once released), or should the OpenJDK JMC project hold off a bit longer?
(In reply to Marcus Hirt from comment #131) > Would you say it's reasonable to use the SWT Chromium support in an > RCP-application based off of Eclipse 4.17 (once released), or should the > OpenJDK JMC project hold off a bit longer? SWT Chromium does not support Linux with Wayland (latest Fedora, Ubuntu, RHEL, Suse...). It will work with X11 but you would have to ask your users to fallback to X11. So consider this when you make a decision. Latest Chromium upstream support wayland but swt chromium is on too old version for now.
(In reply to Alexander Kurtakov from comment #132) > (In reply to Marcus Hirt from comment #131) > > Would you say it's reasonable to use the SWT Chromium support in an > > RCP-application based off of Eclipse 4.17 (once released), or should the > > OpenJDK JMC project hold off a bit longer? > > SWT Chromium does not support Linux with Wayland (latest Fedora, Ubuntu, > RHEL, Suse...). It will work with X11 but you would have to ask your users > to fallback to X11. So consider this when you make a decision. > Latest Chromium upstream support wayland but swt chromium is on too old > version for now. Just to be clear here, SWT Chromium does run in any of the mentioned OS with a wayland session, by opening the application with env var GDK_BACKEND=x11. Then the app runs with XWayland, a wayland implementation of x11, not native x11.
(In reply to Guillermo Zunino from comment #133) > (In reply to Alexander Kurtakov from comment #132) > > (In reply to Marcus Hirt from comment #131) > > > Would you say it's reasonable to use the SWT Chromium support in an > > > RCP-application based off of Eclipse 4.17 (once released), or should the > > > OpenJDK JMC project hold off a bit longer? > > > > SWT Chromium does not support Linux with Wayland (latest Fedora, Ubuntu, > > RHEL, Suse...). It will work with X11 but you would have to ask your users > > to fallback to X11. So consider this when you make a decision. > > Latest Chromium upstream support wayland but swt chromium is on too old > > version for now. > > Just to be clear here, SWT Chromium does run in any of the mentioned OS with > a wayland session, by opening the application with env var GDK_BACKEND=x11. > Then the app runs with XWayland, a wayland implementation of x11, not native > x11. Yes, sorry I should have been clearer and this is what I ment by "fallback to X11".
Thanks Guillermo for your work on this feature, closing this top level 'plan' bug for 4.17 now. Thanks to Lakshmi, Paul(sdamrong@redhat.com) and Sravan for all your help in testing, verification and build process setup. Raised bug 566608 to track further improvements and upgrades on Chromium support in SWT for 4.18
