I’m maintaining a perl script which runs an automated install of our base server software. One of the new requirements is to install the Inline::Java module.
Our usual strategy of installing using Yum seems to fall down as there’s no Inline::Java available in yum. I can’t find an RPM release for it so can’t install as an RPM. The only options seem to be installing through CPAN or shipping the tar and having a step which identifies the SDK location and runs ‘perl Makefile.PL J2SDK=; make; make install’.
Instinctually I think that’s a little shaky for an automated install, I’ve had problems with CPAN installs failing in the past and I don’t really want to have to make on a live server, but I can’t think of a better option.
The other option I considered was just shipping the .pm file, placing it in a user defined directory and using ‘use lib’ to define that as a location but due to the way Inline::Java works I don’t think this is possible, it needs the location of the InlineJavaServer and such too.
Does anyone have a better solution or an opinion on which of the ones proposed above is the best?
Inline::Javawill look forInlineJavaServer.jarand the other files it needs in the same location as theInline/Java.pmfile. Copying the whole distribution from the install directory on one machine and copying it to another machine (with the same architecture) isn’t as crazy as it sounds. If you only have a few different systems (not all linux, 32 bit vs 64 bit, perl 5.6 vs perl 5.10, etc.), it is tractable to make a separate package for each system.There is some install-time configuration in
Inline::Java, including specifying the default Java installation to use. But this (and other default configurations) can always be overridden with environment variables likePERL_INLINE_JAVA_J2SDK(see the Inline::Java perldoc for the complete list). You could packageInline::Javawith your own custom module, say,MyCompany::InlineJavaConfig, that can set the appropriate environment variables before theInline::Javamodule gets loaded in each script.There’s some other install-time configuration like whether to configure JNI and other native support. It might be a little dicier to copy the files that support these features from one machine to another. But I can’t think of any reason off-hand that it wouldn’t work.