Take a look at something like DemoEquityPortfolioLoader.java in OG-Examples. In the main method you have something which loads the local spring context (in this case called demoPortfolioLoader.xml) from the classpath. It then pulls out the beans that it wants: in that case it’s an instance of the class you’re in, but managed and initialised by the Spring context. The spring file includes another file called loaderContext.xml, which is buried in OG-Financial/src/com/opengamma/financial/portfolio/loader/loaderContext.xml, which is basically a bean bundling all the master interfaces, which themselves are defined in OG-Financial/config/com/opengamma/financial/demoMasters.xml. You can inject this bean into your own class too, and then pull out the pre-initialised and connected masters and sources from there, ready for use. If you need e.g. a HistoricalTimeSeriesMaster, it’ll already be available as a bean in the context called ‘dbHtsMaster’ - this is not cached, so should only be used for inserts.
We know that this is overly complicated and horrible, which is why it’s since been replaced with a completely different component-based configuration system in the current head of the master branch. I would not however, recommend trying to use this branch as it’s still under development and may often break and we don’t support it. Additionally, the branch you are using is not supported either and was an internal branch for a customer demonstration.
Documentation on the new style of configuration is forthcoming by the end of the month, but to give you an idea it’s basically controlled by a single .ini file, which specifies which components to start (possibly over remote interfaces) together with a chain of 1 or more .properties files to specify any installation specific particulars. There’s then a simple template for all the command line tools that provides access to any required master/source interfaces.