In Karaf 3.x (and SMX 6.x) also this entries should work mvn\:commons-io/commons-io/1.4=80 mvn\:commons-beanutils/commons-beanutils/1.8.3=80
But I think you use the Karaf 2.x based SMX distribution. You have to use the form shown bellow. Regards Krzysztof On 07.12.2014 15:17, Krzysztof Sobkowiak wrote: > Try this please > > commons-io/commons-io/1.4/commons-io-1.4.jar=80 > commons-beanutils/commons-beanutils/1.8.3/commons-beanutils-1.8.3.jar=80 > > Regards > Krzysztof > > On 07.12.2014 14:59, Andrew Thorburn wrote: >> Thanks Krzysztof, I gave that a shot, and now I'm getting the following: >> >> Please wait while Apache ServiceMix is starting... >> Bundle listed in startup.properties configuration not found: >> commons-io/commons-io/1.4 >> Bundle listed in startup.properties configuration not found: >> commons-beanutils/commons-beanutils/1.8.3 >> Could not create framework: java.lang.Exception: Aborting due to >> missing startup bundles >> java.lang.Exception: Aborting due to missing startup bundles >> at org.apache.karaf.main.Main.processConfigurationProperties(Main.java:1249) >> at org.apache.karaf.main.Main.loadStartupProperties(Main.java:1062) >> at org.apache.karaf.main.Main.launch(Main.java:343) >> at org.apache.karaf.main.Main.main(Main.java:555) >> >> I have the following JAR files: >> >> $SMX_HOME/system/commons-io/commons-io/1.4/commons-io-1.4.jar >> $SMX_HOMEsystem/commons-beanutils/commons-beanutils/1.8.3/commons-beanutils-1.8.3.jar >> >> With the following two lines at the *end* of my startup.properties file: >> >> commons-io/commons-io/1.4=80 >> commons-beanutils/commons-beanutils/1.8.3=80 >> >> That looks to be the same format as everything else - any thoughts? >> I'm kinda tired ATM so may have missed something obvious. But just >> looking at the file, it appears to be used for setting the start-level >> of already-installed bundles, rather than installing new bundles. A >> quick check suggests that most (all?) of the bundles in >> startup.properties are referenced in >> servicemix/system/org/apache/karaf/assemblies/features/standard/2.4.0/standard-2.4.0-features.xml >> or some other features.xml file that is loaded on startup. >> >> Might be easiest just to create a new features file for those two bundles... >> >> Thanks, >> >> - Andrew >> >> On Sun, Dec 7, 2014 at 9:43 PM, Krzysztof Sobkowiak >> <[email protected]> wrote: >>> Hi Andrew >>> >>> You can use startup.properties file to specify which bundles should be >>> installed at boot time. We are doing it in SMX to add the OBR bundles. >>> You can simply modify the existing file after unpacking SMX and append >>> your additional bundles. You must ensure the bundles are available for >>> SMX - you must copy them into the system subdirectory (according to the >>> maven coordinates). I think the both thing can be simple done in the >>> Docker script. >>> >>> Regards >>> Krzysztof >>> >>> On 07.12.2014 09:57, Andrew Thorburn wrote: >>>> Hey folks, >>>> >>>> I've been playing around with setting up docker images for SMX, and >>>> one of the things it would be very helpful to be able to do is specify >>>> a list of *bundles* (not features!) that are installed the first time >>>> SMX boots up. >>>> >>>> I know how to do features - just edit the >>>> etc/org.apache.karaf.features.cfg file - but I want to ensure the >>>> following bundles are installed: >>>> >>>> mvn:commons-io/commons-io/1.4 >>>> mvn:commons-beanutils/commons-beanutils/1.8.3 >>>> >>>> And I don't see a way to do that without having to boot it up first >>>> (which is a right pain to do in Docker). >>>> >>>> On a related note, is it possible to install the features without >>>> having to boot up SMX? My primary aim for what I'm doing now is to be >>>> able to create a Docker instance which is fully pre-configured for the >>>> other developers to use (and potentially to use in production, at some >>>> later stage). >>>> >>>> I could create a Maven POM to add the necessary extra JARs to the >>>> system directory, I imagine, but I'd rather have them installed during >>>> creation of the image, if I can - the less things that can go wrong >>>> when other people get their hands on it, the better. >>>> >>>> And yeah, I could build my own SMX (doesn't seem like it would be that >>>> hard, but not sure it would solve the non-feature bundles, above), but >>>> I'm trying to see what I can and can't do in Docker, and it just feels >>>> like it would be a bit easier to just download the binary and install >>>> stuff, as opposed to cloning the SMX repo and keeping that up-to-date. >>>> Might be wrong, but hey. >>>> >>>> Thanks, >>>> >>>> -Andrew -- Krzysztof Sobkowiak JEE & OSS Architect | Senior Solution Architect @ Capgemini | Committer @ ASF Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center <http://www.pl.capgemini-sdm.com/> | Wroclaw e-mail: [email protected] <mailto:[email protected]> | Twitter: @KSobkowiak Calendar: http://goo.gl/yvsebC
