ah well, left a comment, otherwise we can open a JIRA issue

and let's see if I can finally get a new release of puppet-jenkins out, with the systemd changes

See the

puppet-jenkins

module at https://forge.puppet.com/puppet/jenkins?src=slack&channel=voxpupuli

bleh, the helper now fails on unable to resolve class org.jenkinsci.main.modules.cli.auth.ssh.UserPropertyImpl and I don't know how to solve that

This message was deleted.

Anyone else ever tried to wrap their head around https://github.com/puppetlabs/puppetlabs-java/blob/2d9ff91e1c118c3877a9dbac36af95573689d43f/manifests/init.pp#L54-L73 ?

I think it's because the sshd plugin is no longer present

afisher: just today; it's this structure: https://github.com/puppetlabs/puppetlabs-java/blob/2d9ff91e1c118c3877a9dbac36af95573689d43f/manifests/params.pp#L55-L64

The code reads badly enough for someone to write comments in an if/else style, but oddly they didn't rewrite the code itself to avoid the selectors.

afisher: jdk and jre are distributions there

seems fine to me, but package could have just set sensible default to parameters instead of this contraption

afisher: I think some of that can use pick()

afisher: https://github.com/ekohl/puppetlabs-java/blob/simplify-logic/manifests/init.pp I think that's the simplified version

ewoud: I daren't actually try to fix it up. Was just trying to work out how to enforce one version of java is the default when I have 2 openjdk packages installed.

https://github.com/ekohl/puppetlabs-java/blob/simplify-logic/manifests/init.pp#L49 I think that since this can resolve to

undef

the following line would need

pick_default

???

https://github.com/ekohl/puppetlabs-java/blob/simplify-logic/manifests/init.pp#L49 I think that since this can resolve to

undef

the following line would need

pick_default

???

afisher: yes, I just noticed that too

Was hoping that whatever version I installed using the module would already get set as the default and that I could just install 'the other' jdk using a simple package resource.

yes, it doesn't appear to update alternatives

had the same thing with Jenkins earlier

First checked if I had a

Exec['update-java-alternatives']

in my catalog, and I don't. Then was trying to work out why not and how to 'fix' that.

If

java::config

doesn't bring in variables via class parameters, so that didn't give me anything to inspect there either.

The README doesn't mention anything, and the parameter docs just talk about Debian. https://github.com/puppetlabs/puppetlabs-java/blob/2d9ff91e1c118c3877a9dbac36af95573689d43f/manifests/init.pp#L22

The README doesn't mention anything, and the parameter docs just talk about Debian. https://github.com/puppetlabs/puppetlabs-java/blob/2d9ff91e1c118c3877a9dbac36af95573689d43f/manifests/init.pp#L22

(I'm using CentOS 7 here)

afisher: I think it relies on Puppet 3 style variable passing for those

afisher: or was it Puppet 2 which had the inheritance

either way, it looks like this never made it to Puppet 4+

other than data types being added, but the alternatives bit …

It's a private class so honestly can do what it wants. It chooses to access the calling class's variables directly. This is fine. In this particular instance it might have helped me understand my existing catalogs if it didn't, but that's not a good enough reason to suggest private classes should have parameters.