John Cheers for the response...
It's quite possibly i'm over-thinking the possible permeations on the Java side, and probably need to strip it back to as simple as possible. In that vein, I've gone with your suggestion of asserting what the JAVA_HOME *will be* once the relevant package has been installed by this module. Will get the latest changes pushed shortly for comment. Cheers Gavin On Wednesday, 2 July 2014 14:09:50 UTC+1, jcbollinger wrote: > > > > On Wednesday, July 2, 2014 5:06:46 AM UTC-5, Gavin Williams wrote: >> >> Morning all >> >> I'm currently working on a module[1] to support installation and >> configuration of Apache Karaf[2], a Java OSGi container... >> >> I've got most of the installation piece sorted, and am starting to work >> on the configuration side of things. >> Unfortunately I've hit a bit of a blocker which I'm not sure of the best >> way to work-around. >> >> As part of the service installation process, a Java wrapper config file >> is created. >> This config file needs to be modified to specify the 'JAVA_HOME' value. >> However I'm not sure of the best way to calculate this JAVA_HOME value, due >> to the variable nature of both Java variants (Java 6 vs 7, Oracle vs >> OpenJDK, release version) and the fact that Java might not be installed at >> the start of the Puppet run. >> The intention is to use a template for the config file, so it's >> modifiable by Puppet. >> >> Options I can think of: >> >> 1. Use a fact to provide JAVA_HOME. This fails if Java isn't >> installed at the start of the agent run, which is a valid scenario if >> this >> module is also installing Java... >> 2. Hard code the value based on a pre-determined file path based on >> chosen Java distro and version. Not very clean/configurable... >> 3. Update wrapper config file to pull in system env for JAVA_HOME. >> However this fails if the system version isn't the one that the app >> should >> use... >> >> Am I missing a trick somewhere along the lines, or is hoping to achieve >> all this - Install Java, Install Karaf, configure Karaf service - in one >> run asking too much? >> > > Your criticisms of those options present an inconsistent view of your > requirements. If the app needs to use a specific Java version that may be > different from the system's default (per remarks about #3) then it's going > to be pretty tricky to get the correct value from a fact, too (alternative > #1). That seems to say that knowing the requisite Java version in advance > (#2) is one of your requirements, so whether that's clean or configurable > is irrelevant. > > >> Thoughts/ideas welcome. >> > > Since you are managing the Java package, in principle you can know what > JAVA_HOME you will need based on which package you are ensuring installed. > That is, you can know what the appropriate JAVA_HOME *will be* once > Puppet is done because it is (or can be) part of what you are managing, > albeit indirectly. > > If you want to be a little less prescriptive and a little more adaptive, > at the risk of possibly needing two runs to reach a stable configuration, > then you could try a combination of your alternatives 1 and 2: use a custom > fact to try to choose JAVA_HOME from among those of the runtimes available > before the run, and if there isn't any (or if none is suitable) then use a > prediction based on knowledge of what you are about to install. Honestly, > though, this seems harder and messier than my previous alternative. > > > John > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/368007c0-f334-4105-8245-17b593b7c5aa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
