IBC as a library about ibc HOT 5 CLOSED

@bantu

I've just uploaded a sample program that shows the use of IBC as a library. You'll find it in the samples/IbcLoader folder: please read the README there.

This program uses the IBC dependency injection mechanism to provide custom settings, login credentials, and trading mode, so that the usual start scripts and the config.ini file are not required. It also, just as a pointless demonstration of capability, sets the TWS/Gateway main window transparency to 80% and overlays a simple clock over the main window.

I've provided a RunIbcLoader.bat command file to run it on Windows (no time to do a bash script yet). Note that this calls another command file to determine where the user's TWS-private Java is located, and to find the TWS jar files, just so that it will run on hopefully any current TWS installation. For a realistic application, you'd just run the javaw command with the Java location and the classpath hardcoded.

from ibc.

You can already use IBC as a library. Just call the method ibcalpha.ibc.IbcTws.load(), and it will start IBC with various defaults.

There is a dependency injection mechanism that allows you to, for example, get settings from a different source rather than from the config.ini file (for example, your calling application might have an XML or YAML config file, and you could inject an object that implements the ibcalpha.ibc.Settings interface and retrieves the relevant values from the application's config file).

I wrote a very small demo of this a couple of years ago before the fork from IBController, and I'm in the process of converting it to run with IBC - minor problem at present with the Gateway entrypoint, but that should be easy enough to resolve.

I'll add this example to the repository when I'm ready, along with some Javadoc annotation for the various interfaces involved in the dependency injection mechanism. Note that IBC is not my top priority, so don't hold your breath!

I have occasionally considered Maven, but I've yet to see any real benefit that isn't totally outweighed by the effort I'd need to make to get properly up to speed with it. By all means try to convince me otherwise, but at present the simplicity of using Ant (about five seconds to build the project and generate the zip files in NetBeans) is a clincher for me. If this were a new project, and/or it had external dependencies that are available on Maven, and/or there were many contributors, it might be a different matter, but at present this is about the simplest possible project you could imagine (in terms of build).

from ibc.

@rlktradewright Thanks a lot for your detailed explanation. Unfortunately, I did not have time to investigate your suggestions. Our strategy has slightly changed in the meantime. We are now trying to provide TWS/IBG as a central (always available) service. As such we do not need to control IBC from our Java application right now. Nevertheless, we think the ability to do so is highly useful in general.

As for Maven, the key benefit of publishing IBC on Maven Central or any other repository is that projects which want to consume your library, can easily depend on your library and do not have to copy your source code into their project. However, fair enough, it probably is already possible to properly depend on this git repository, e.g. using gradle source dependencies. https://blog.gradle.org/introducing-source-dependencies

from ibc.

A project that wants to use IBC programmatically can surely just include a reference to IBC.jar? No need to include the source code.

Indeed, this is exactly what my sample program does.

I don't doubt that using Maven would make this easier, but since the number of people who want to do this is probably only 1 (ie me!), there's no point.

By the way, I do appreciate the benefits of package managers in general, and I use Nuget extensively in my own work. But when I tried creating an experimental Maven project in NetBeans, it insisted on downloading the entire Maven Central repository, which took ages and rather filled up my disk. That struck me as very bad behaviour, and very irritating!

from ibc.

A project that wants to use IBC programmatically can surely just include a reference to IBC.jar? No need to include the source code.

To ensure the expected version of IBC.jar is used, it would have to be tracked in the repository. Binary data (which .jars basically are) do not belong into repositories. But then again I already described the approach I would take (using gradle) above.

from ibc.