I've looked everywhere and I'm new at this open source stuff but... what's the difference between:[ ]
apache-zookeeper-3.5.6-bin.tar.gz 2019-10-16 01:35 8.8M
apache-zookeeper-3.5.6.tar.gz 2019-10-16 01:35 3.0M
I'm guessing since the top is bigger it's shipping with more dependencies? I having issues running apache-zookeeper-3.5.6.tar.gz has classes missing.
apache-zookeeper-X.Y.Z.tar.gz is standard source-only release
apache-zookeeper-X.Y.Z-bin.tar.gz is the convenience tarball which contains the binaries
https://zookeeper.apache.org/releases.html
Related
There are a couple postings on this topic, but I can't get this to work with the latest version of Eclipse. I am using the JRE that comes with 2021-06, the one it puts in p2, x86_64_16.0.2.
I have tried various configurations of User Libraries, Maven dependencies, setting PATH_TO_FX, searching Eclipse Marketplace for JavaFX-as-a-plugin, e.g.,
How do I use JavaFX 11 in Eclipse? (2.5 years old)
https://www.javatpoint.com/javafx-with-eclipse
https://www.tutorialspoint.com/javafx-with-eclipse
https://gluonhq.com/products/javafx/
On a couple more elaborate examples, a couple builds had a scattering of missing methods, which I assume is due to JavaFX being somewhat in flux or instructions being quite outdated. I can get a simple Hello, World to build with javafx-sdk-17.0.1 as a User Library (what I'm doing now) and also some of the other configurations. When I try to launch Hello, World with various build-able configurations, I keep getting
Error: JavaFX runtime components are missing, and are required to run this application
Well, I was a bit too quick. I kept playing around, and adding quotes in the VM arg seems to work,
--module-path="C:\Program Files\Java\javafx-sdk-17.0.1\lib" --add-modules=javafx.controls
If the project is not a module project, the Used Library goes on the Classpath in the project properties, Libraries tab. If it is a module project, it goes on the Modulepath,and the following module-info.java file must be in the src with this minimal information:
module <myProject> {
requires javafx.controls;
exports <myPackageContainingFXAppClass>;
}
I just don't get it why people prefer to search half of the internet for tutorials instead of just consulting the official documentation first. Here it is: https://openjfx.io/openjfx-docs/#IDE-Eclipse It seems to be the best hidden secret that there actually is documentation for JavaFX that one could start with.
I just did the test. Googling for "javafx documentation" gives https://openjfx.io/ as the first search result.
I use --module-path=${PATH_TO_FX} --add-modules=javafx.controls.
Obviously PATH_TO_FX needs to be defined in Preferences->Run/Debug->String Substitution.
An easy way to get rid of *everything* generated by SBT? asks for an easy way to clean up all files generated from sbt, and didn't find one. I'll ask for a hard one. How do I get a make cleanall with sbt?
UPDATE: For a definition of everything, you have to know why you ever need to clean all. There are two common reasons:
To distribute something: You need to confirm that someone can take a fresh machine, download your code, and build it without problem. (Or, someone can't, and you want to debug).
When something has gone horribly wrong. Some funny version of some jar somewhere is breaking something somehow. Sometimes it's easiest to just start fresh, rather than try to debug... (See Jim Gray's Why Computers Stop)
Here are the usual suspects of things you need to clean:
~/.sbt/boot - Safe cache of sbt itself to avoid disappearing JAR oddiites
~/.sbt/**/target - Compiled global plugin/build definitions.
~/.ivy2/cache - Ivy cache of resolved dependencies
~/.ivy2/local - publishLocal files
<cwd>/project/**/target - Compiled build/plugin definitioins
<cwd>/**/target - Artifacts from building your project, including compiler caches, classfiles, etc.
sbt is unable to provide a "clean everything" task directly, because deleting the JARs/classes sbt is actively using to run your build leads to super odd and evil behavior. But you could write a simple BASH script which can accomplish this if desired.
I found Autofac AggregateService awesome but what is the right way to include it in my project: clone it from code.google.com or use NuGet?
I got used to use NuGet but I can't find nothing about AggegateService there. Any help?
It seems that AggregateService and the other Extras are currently "in limbo". There's been a recent change in that the contributions are now being made part of the same solution as Autofac core, while they were previously a separate solution. From the current build file you can see that extras will be made available as a separate Autofac.Extras package and a separate download from the Autofac page.
Meanwhile, you can use AutofacContrib 2.6.1 or to grab the source and compile a dll yourself.
Btw, thanks for finding AggregateService awesome ;)
Update: actually, reading the build file properly (and looking at the current source structure), the Extras parts will be distributed as individual packages. So expect to find Autofac.Extras.AggregateService on Nuget in the future.
We have defined our own ADD_EXECUTABLE macro (TDS_ADD_EXECUTABLE) for our cmake files which handles some nice internal functionality for us.
The problem is, when I load up our project in KDevelop 4 (linux) while it finds and builds our entire system, it does not add any of the executables to the Project Targets list for configuring the launches. This makes it a real management nightmare to do any work in KDevelop since we have to manually add all of our executables.
Is there a way to tell KDevelop our TDS_ADD_EXECUTABLE performs an ADD_EXECUTABLE... or something like this? I was actually surprised it was unable to fathom this on it's own since it's all scripted.
Any help is appreciated, thank you!
Do I understand this correctly - TDS_ADD_EXECUTABLE is just a macro around ADD_EXECUTABLE? If so, KDevelop should figure that out automagically. Post a small testcase to the correct place: http://bugs.kde.org
So, I now know what to save from nightly builds. What about when I give something to customers?
For example, I probably want to save debugging information (e.g. PDB).
What else?
We use:
installers
binaries
pdbs
tag of source files
any other source files that might not be in svn - for example config.status
build log
You made me wonder if I'm missing anything important
Compiler and library version information (it may not be part of the build log). Somebody else mentioned the whole binaries.
Linker map file (it can sometimes help the remote debugging of a problem).
Unstripped executable (if on a Unix system you strip it the executable before making it available to clients).
For the SDK releases we do include:
PDB and XML for the libraries (packaged with the latest snapshot of the samples)
Packaged snapshot of sources from SVN (just because we can)
Link to the online documentation (docs are generated from the source automatically)
Trace messages don't necessarily need to be generated by default but the possibility to enable them can be very helpful.
Results and Information generated from ATPs that are run on the build (probably as part of the build process).