Cannot find any information if Jaeger can be executed without docker?
Does a standalone jar exist, or will there be a release in the future for Jaeger like Zipkin has ?
The Downloads page (https://www.jaegertracing.io/download/) lists both the Docker images and the raw binaries built for various platforms (Linux, macOS, windows). You can also build binaries from source.
Just to add to Yuris answer, you can also download the source from github - Github - Jaeger This is useful for diagnosing issues, or just getting a better understanding of how it all works.
I have run both the released apps and custom versions on both windows and linux servers without issues. For windows I would recommend running as a service using Nssm. Nssm details
I want virtocommerce in my own local repository.
storefront is a solution that will configure it according to the following link:
Storefront Source Code Getting Started
And it works.
But I want to have a solution For platforms and modules,
Like the link below:
vc-integrations
But I need the platform and modules to be connected to the github for the latest changes.
I've studied the link below:
Source Code Getting Started
but I do not understand how should I configure for my goals (one solution for platfrom and modules and fork, clone ,upstream for all for get latest versions of them)
We've used to have a single repository and single solution for Virto Commerce Manager and modules (vc-integrations). It was difficult to maintain and release often. That's why the single repository was split into many "1 module per repository" pieces.
We consider that in most cases having only Virto Commerce Manager configured should be sufficient. What's your scenario? Check "Manual module installation from source code" section in Source Code Getting Started to get started.
I have Cocoa application with custom XPC service. I would like to create tests for that XPC, so I created new test bundle for that and created some tests. But when I run those tests (whose doesn't show any error in Xcode), IDE is not able to link them to tested XPC bundle. Of course I set Target Dependency to my XPC bundle but it still doesn't work.
I think that problem will be at Test host settings but I'm not good at Xcode configuration. I also studied Apple's tutorial (Daemons and Services Programming Guide) but it doesn't mention testing XPC bundle. Neither their example SandboxedFetch.
On Xcode 7, I managed to test my XPC by adding it in the Copy file build phase of my test target (specifying XPC Services for destination.
I just downloaded the full 4.0.1_r1 Android Source Code repository according to the official instructions. Can someone help me understand the repository's basic naming scheme?
For example, in the root directory of the repository, what exactly is the "frameworks" directory? How does this differ from the "packages" directory?
I have spend quite a bit of time around the android source code the last few years, so let me take a shot at explaining the different folders in the root. These are roughly (depending a bit on the android version):
bionic
The standard c library used and developed for Android specifically.
bootable
Contains the bootloader (which the device manufacture normally provides) and the recovery application which is execute when the phone is booted into recovery mode.
build
Android has very unique modular build system, which itself is built on top of ordinary make-files. For example in build/target/products you will find all the generic build targets you see when you launch lunch.
cts
Compatibility Test Suite. When a device manufactures wants to get their device certified (and thus get Google Play and other proprietary apps) they need to pass the CTS. The source of CTS is contained in this directory.
dalvik
The dalvik virtual machine. Android uses java for the better part of the framework as well as for all the apps. Because each app runs as its own process under its own uid, in its own virtual machine, the virtual machine have to have a rather small memory footprint, so Android have chosen to use a custom virtual machine for Java called dalvik. The source of dalvik is placed here.
development
I haven't used this repository really, but it seems supporting stuff for developing android apps are placed here.
device
Each device vendor put all the stuff that defines their specific devices here. For example you can provide a devices/{yourname}/products/{yourdevice}.mk defining exactly which apps should be build for your device (as well as a few other things). This adds an entry to the lunch menu called {yourdevice} that you can build.
docs
As far as I understand this is actually the source of http://source.android.com.
external
Almost all of the third party projects that Android pull in and which makes up the base Android Linux OS are located here. They are maintained in their own git repositories, which makes it easy to pull new versions from upstream. You see things like bzip2, dbus, ping, tcpdump, and many other projects here.
frameworks
This is the source of the Android framework. All the stuff that you use when you build an app for Android. I think it is somewhere around 50% Java code and 50% C++ (and sometimes C), which is bound together using jni. When you for example play some audio in an app, you are probably accessing AudioManager. The source of AudioManager as well as all the internal Android source supporting AudioManager is placed under frameworks/base/media. You will find the bulk of the Android SDK implemented somewhere under frameworks/base/.
hardware
Android talks to a set of libraries which then controls the hardware (such as vibrator, lights, proximity sensor, gps, audio, etc.). These libraries are collectively called the HAL (Hardware Abstraction Layer). Some default implementations are contained in the hardware folder, however manufactures implement their own libraries and place them in hardware/{manufcaturename} (or in device/{manufacture}).
libcore
I don't know about this one.
ndk
The native development kit which allows app developers to code some (or all) of their apps as native code (in c and c++ usually). Basically it is a toolchain to crosscompile to the different cpu architectures Android runs on.
out
All Android build artifacts are placed here. So removing the out folder will clean the sources completely. out is divided into different folders, the main ones are host and target where stuff compiled for the host machine (e.g. adb) and for the target device (most of the android system) are separated. There are further subdivisions below, and in general the out folder is quite nicely sorted, so you should just explore it a bit yourself.
packages
These contains all the default apps, providers, inputmethods, and so on, that are built along with Android. The phone app, contacts, calender, calculator, default soft-keyboard, etc, are placed here. They are not 3rd party apps, they are internal apps where many of them are build against non-public android apis. So most of the apps here cannot build against the public Android SDK (e.g. in eclipse), but have to be build as part of the complete Android build process.
prebuilt
Stuff that is distributed along with Android as binaries. The primary thing located here are the crosscompiler(s) for building Android for ARM (and now also x86). They are prebuilt such that you do not have to actually build the crosscompilers yourself. (This could be very time-consuming if you besides Android also had to compile the crosscompilers.)
sdk
All the tools that are part of the Android SDK, such as ddms, the emulator, sdkmanager, etc.
system
The core system processes running on an android device. These are native (c or c++) programs. Mediaservice is an example of such a system service.
This is all from my experience with working with the Android source, I do not have any (other) references. I hope this helps you get an overview of the folder structure.
I was running the samples from trunk on Source Forge and they are busted so I started debugging the code and found the bug. Then I took a look at the code in master from GitHub and it is totally different(sans bug). Which repository should we be looking at? NServiceBus.com points you to Source Forge, but more activity seems to be going on at GitHub.
Github is the current master for NServiceBus