Closed magreenblatt closed 4 years ago
magreenblatt
commented
8 years ago As stated on the cef_downloads page, "Deprecated Downloads are temporarily unavailable." Once that problem is fixed a very old (and deprecated) build of JCEF will again be available. However, you should instead build JCEF from source code as described on the BranchesAndBuilding Wiki page. I'll update the overview page to reflect this.
magreenblatt
commented
8 years ago Original comment by Mark (Bitbucket: Mark, GitHub: Mark).
Does that mean that no more 'official' builds will be made available anymore? In a post at the start of the year you suggested that more builds would be made. What would you require to release an 'official' build? Will any source snapshot be tagged as 'release quality'?
magreenblatt
commented
8 years ago Does that mean that no more 'official' builds will be made available anymore? What would you require to release an 'official' build?
Some person or company will likely need to volunteer to run a build server similar to how Adobe is running http://cefbuilds.com.
Will any source snapshot be tagged as 'release quality'?
Providing 'release quality' takes a not-insignificant amount of time. To ensure that level of quality more people will need to volunteer their time/resources to fix bugs, write unit tests, etc.
magreenblatt
commented
7 years ago Original comment by Guus der Kinderen (Bitbucket: guusdk, GitHub: guusdk).
As a developer of an OSS Java-project that would benefit hugely from having pre-build native distributions (preferably, through Maven, but that's one step beyond this thread), I was looking into generating distributions, using free, online tooling, that provide, or hook into the continuous integration of a project. So far, I've had moderate success with combining Travis CI and AppVeyor.
My efforts are registered here:
Travis can be used to build the Mac and Linux builds (and upload them somewhere), while AppVeyor appears to be able to do the same thing for the Windows builds.
I think such a solution would fit the java-cef project well, but before spending more time on this, I'd like some feedback on this from its developers on this approach.
Although I was able to successfully build most binaries, there is still work to do. I'm no expert by far, so I might be missing something, but for some builds, I think it would be helpful if the java-cef build scripts could be modified.
AppVeyor, for instance, builds the 64-bit Windows distribution without errors, but fails to build a 32-bit one. I believe that this relates to the JDK that is being used. For the 32-bit build, it insists on using the 64-bit Java install, even though a 32-bit install is available. I've tried setting JAVA_HOME explicitly, but that does not resolve the issue
Travis can build the Mac and Linux builds, although it does not offer a native 32-bit linux environment. Apparently, there is a Docker-based approach that could circumvent this, but I've yet to explore that.
I did not write anything that does actually upload the generated native binaries anywhere, nor did I test those binaries.
I'm not tied to either AppVeyor or Travis, by the way. I simply started off with the tooling that I was familiar with. I'd be open to suggestions for alternatives.
During development, I found that the buildscript would fail, when I obtained the java-cef sources via a git module. The scrips require a proper git clone, which took me some debugging to figure out. It's not relevant to the issue at hand, but I thought I'd mention it. If it's easily fixable, perhaps that could be considered.
magreenblatt
commented
7 years ago Original comment by Roberto Neto (Bitbucket: BetoN, GitHub: BetoN).
@guusdk thanks about the links. Based on them I created this 2 batch scripts to build win32 and win64.
For x86:
#!batch
@echo off
set path=%path%;"C:\Program Files (x86)\MSBuild\14.0\Bin"
set JAVA_HOME=C:\Program Files (x86)\Java\jdk1.8.0_131
mkdir c:\jcef
rd /s/q c:\jcef\src
git clone --depth=1 https://bitbucket.org/chromiumembedded/java-cef.git c:\jcef\src
cd c:\jcef\src
mkdir jcef_build
cd jcef_build
cmake -G "Visual Studio 14" ..
msbuild "c:\jcef\src\jcef_build\jcef.sln" /property:Configuration=Release /property:Platform=Win32
cd c:\jcef\src\tools
call compile.bat win32
call make_distrib.bat win32
cd c:\jcef\src\binary_distrib\win32
start explorer c:\jcef\src\binary_distrib\win32
pauseand x64 distro
#!batch
@echo off
set path=%path%;"C:\Program Files (x86)\MSBuild\14.0\Bin"
set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_131
mkdir c:\jcef
rd /s/q c:\jcef\src
git clone --depth=1 https://bitbucket.org/chromiumembedded/java-cef.git c:\jcef\src
cd c:\jcef\src
mkdir jcef_build
cd jcef_build
cmake -G "Visual Studio 14 Win64" ..
msbuild "c:\jcef\src\jcef_build\jcef.sln" /property:Configuration=Release /property:Platform=Win64
cd c:\jcef\src\tools
call compile.bat win64
call make_distrib.bat win64
cd c:\jcef\src\binary_distrib\win64
start explorer c:\jcef\src\binary_distrib\win64
pausePlease check the "paths" for your environment.
You need to have:
magreenblatt
commented
7 years ago Original comment by Guus der Kinderen (Bitbucket: guusdk, GitHub: guusdk).
@betonetotbo Thanks for the feedback, but I'm not quite sure how this is helping me. Are you suggesting that my work should be completely replaced? If that's needed, I'm totally willing to do that, but I wonder if you're providing a solution to a problem that I don't have.
My questions are:
magreenblatt
commented
7 years ago Original comment by Former user (Bitbucket: Former user).
it looks like you need to set the path prior to building.
this should add java_home to the front of the path.
magreenblatt
commented
7 years ago Original comment by Guus der Kinderen (Bitbucket: guusdk, GitHub: guusdk).
Thanks for your PR, @Sfmarra ! I like how AppVeyor immediately started to build, proving that you fixed the problem by showing me a green button, even before me looking at it. I really like how these tools work.
Sean's fix appears to have fixed the problem with the win 32-bit based build. That leaves the linux 32-bit build - but I'm confident that in one way or another, that can also be fixed. I'll wait for @magreenblatt's feedback, before progressing.
magreenblatt
commented
7 years ago Original comment by md nazmuddin (Bitbucket: iamnazm).
@guusdk , I found win32 and win64 builds in artifact in appveyour and thank you very much for that. I tried building it many times but failed with errors. I am looking for a mac build in Travis CI but didn't found any. May you please share the link of mac build i will be very thankful to you for that. Thanks again.
magreenblatt
commented
7 years ago Original comment by Guus der Kinderen (Bitbucket: guusdk, GitHub: guusdk).
No, I've not worked on a Mac build yet. As CircleCI appears to have a BitBucket integration that's lacking in TravisCI, I've done some work here: https://circleci.com/bb/guusdk/java-cef - But it's no-where near complete.
magreenblatt
commented
7 years ago Original comment by Francisco Vega (Bitbucket: francisco_vega).
@guusdk , about your question
Do java-cef developers see merit in having online services provide build binary distributions (and > will the consider making available these distributions)?
my answer is yes, it is very useful. Thank you very much. I was spending several hours each month for obtaining a working copy of the last update.
magreenblatt
commented
6 years ago Original comment by Christopher Dembia (Bitbucket: chrisdembia, GitHub: chrisdembia).
Having binaries for JCEF would be fantastic. The binaries could be hosted on Sourceforge. I've previously set up Travis to push binaries to Sourceforge. If you want to do this securely, there are some hoops to go through. Here's an example: https://github.com/simbody/simbody/blob/c9aab73cd4463c106f46136449fd0f17a45a4e9e/.travis.yml#L112
magreenblatt
commented
6 years ago See issue #230 for a discussion of refactoring the java folder for Maven support.
magreenblatt
commented
6 years ago magreenblatt
commented
6 years ago magreenblatt
commented
6 years ago Proposed Maven support PR here: https://bitbucket.org/chromiumembedded/java-cef/pull-requests/20
magreenblatt
commented
6 years ago magreenblatt
commented
6 years ago @guusdk Hosting builds generated by third-party sources would be problematic due to permissions/trust issues. How long do appveyor, travis-ci, etc., keep the builds available for?
magreenblatt
commented
6 years ago Original comment by Christopher Dembia (Bitbucket: chrisdembia, GitHub: chrisdembia).
Travis does not offer hosting. Appveyor has hosting but I do not know how long the "artifacts" would be available. As I mentioned above, I suggest you upload the artifacts/builds to Sourceforge. You can see an example of how to do this securely here: https://github.com/simbody/simbody/blob/c9aab73cd4463c106f46136449fd0f17a45a4e9e/.travis.yml#L112
magreenblatt
commented
6 years ago Original comment by Guus der Kinderen (Bitbucket: guusdk, GitHub: guusdk).
How long do appveyor, travis-ci, etc., keep the builds available for?
Unsure. Likely not as long (and likely subject to change) as you'd want to offer a stable download. I think it'd be wise to securely store the generated artifacts somewhere.
What about creating an "official" mirror of this repository on Github, and make use of their 'release' section? That seems to be supported by most CI-tools:
magreenblatt
commented
6 years ago We have a github mirror currently: https://github.com/chromiumembedded/java-cef/
According to https://www.appveyor.com/docs/deployment/github/ the secure auth token is stored in the appveyor.yml file which, for JCEF, is part of the public repository. That sounds very insecure to me (e.g. anyone with access to the appveyor.yml file will then have read/write access to your Github account).
EDIT: Sounds like Appveyor provides a tool for encrypting the auth token. Maybe that makes it OK...
magreenblatt
commented
6 years ago Original comment by Guus der Kinderen (Bitbucket: guusdk, GitHub: guusdk).
Ohh, that mirror might prove to be useful! Are you comfortable giving me access to it?
As for storing sensitive data in public files: most CI tools have a way to do this in a secure fashion, by allowing to use placeholder values, that, upon build, get replaced by a proper private value (that's known only to the CI tool, and is linked to your account. Appveyor calls these "secure variables": https://www.appveyor.com/docs/build-configuration/#secure-variables
magreenblatt
commented
6 years ago Are you comfortable giving me access to it?
Let me check what permissions Github supports and get back to you on that.
magreenblatt
commented
6 years ago Original comment by Guus der Kinderen (Bitbucket: guusdk, GitHub: guusdk).
I've been playing around a bit with a Github Releases based distribution. I've been successful in getting both AppVeyor and Travis to create builds, and add the generated distribution to a Github Release.
I had a little trouble getting both systems to play together nicely (ideally, you'd want the builds generated by both systems in the same release, if they're based on the same commit).
Github releases are based on git tags. I've had some issues with having either AppVeyor or Travis automatically create Releases (and thus, tags), as such an action was a change that caused the other system to be triggered again, causing a new build (and potentially, a new tag).
The most elegant solution that I could come up with is to generate releases only when a tag has been created manually. I've put this in practice here: https://github.com/guusdk/java-cef/releases
In the above repository, both AppVeyor as well as Travis will automatically start building on any commit (I think even on PRs), which is good for integration testing. However, those builds will only create a proper release when the build was triggered because of a push of a git tag.
@magreenblatt : does this work for you? I'm not sure if we can automatically trigger tags somehow - or even if that's desirable?
magreenblatt
commented
6 years ago magreenblatt
commented
6 years ago @guusdk How would you feel about triggering and hosting releases from your https://github.com/guusdk/java-cef account? I think that might be the approach with least difficulty since you're already familiar with how best to set up and manage the various builders, and this way you continue to own the whole build pipeline. Once you're ready I can link to your releases page from the JCEF README.md.
magreenblatt
commented
5 years ago magreenblatt
commented
5 years ago Original comment by Christoph Läubrich (Bitbucket: Christoph Läubrich).
Is there any progress on this? Building "from source" is not very comfortable in most use-cases since it requires a wide setup (linux, windows, mac) to cover as well as fiddling around with several issues (e.g. build tool versions, dependencies). Even if we would have only monthly, manually distributed version via github this would greatly help in integrating/using jcef.
magreenblatt
commented
5 years ago Original comment by Chigozirim Chukwu (Bitbucket: smac89, GitHub: smac89).
I forked the original repo owned by @{557058:848bb2b1-8e64-4e38-8d95-b04456913aa7} here.
It is currently producing linux/mac builds. If someone has experience with building on windows, they can make a PR for that.
The structure of the build artifacts is just all the jars in one folder and all the “rest” in another folder; and this is zipped up and deployed. If someone has a better idea of how to better structure them for the different platforms, suggestions (and PR’s) are welcome.
We now build for all the platforms
magreenblatt
commented
4 years ago @{557058:a0059138-8b89-4881-8a71-c420c72b5c85} Thanks for setting that up. Can we link to your downloads from the JCEF README.md?
magreenblatt
commented
4 years ago Binary downloads are available from https://github.com/jcefbuild/jcefbuild
magreenblatt
commented
4 years ago Original comment by Chigozirim Chukwu (Bitbucket: smac89, GitHub: smac89).
@{557058:2f2a2aee-b500-4023-9734-037e9897c3ab} Sounds great. Btw the correct link is now https://github.com/jcefbuild/jcefbuild now
magreenblatt
commented
4 years ago @{557058:a0059138-8b89-4881-8a71-c420c72b5c85} Thanks! I’ve added the link to the README.md.
magreenblatt
commented
4 years ago
Original report by Bernd Kolb (Bitbucket: berndkolb).
The overview page here: https://bitbucket.org/chromiumembedded/java-cef/overview states that downloads for JCEF are available from http://www.magpcss.net/cef_downloads/.
Unfortunately I could not find any JCEF download there. Am I missing something?