On 11-02-16 04:17 PM, David Jencks wrote:
I could use more details.... and I'm not entirely sure of what karaf does now either, and am thinking mostly about what I'd like it to do soon to solve this kind of problem :-)
Sure : I have my own build system creating what I've called karafcore, in conjunction with mvn assembly:assembly. It has the etc directory, which has startup.properties (and the other files such as config.properties, custom.properties, etc). The pom file has dependencies corresponding to all the stuff started in startup.properties.
I have a subdirectory called alternateBuilds, which has one subdirectory for each "type" of system I'm constructing. One for poking around with jpa. One for poking around with configadmin. Etc etc. In general, each alternate build aims to be the simplest it can be, focusing on its small core purpose. Each of these subdirectories has a pom.xml, for the dependencies, and a startup.properties file, for the bundles to start. Refactoring the pom part is pretty clear, the startup.properties is the hard bit. Right now, all of the startup.properties files have 30 bundles worth of exact duplication, followed by startup at run-level > 50 for whatever sort of extension they're aiming at. The extension portion is usually a very small handful of bundles, although sometimes more.
I could solve the problem with some sort of shell script to manually concatenate core bits to extension bits each time I swap between alternate systems, I was just hoping karaf (or osgi; or felix; or maven; or java itself; whichever level of technology makes the most sense) would have a better approach, particularly since a shell script based approach will grow increasingly complex as the alternate builds progress to a level where they are themselves composed of other alternate builds plus core (like, a build with configadmin functionality that also uses JPA and has some gui extensions, or some such).
-Jamie
