@jehrhardt I think releasing this as 2.0 is fine, but we'll need have 1.x live on for a while as well. Can you take a look at the puppet-lint issues that caused travis-ci to fail?

You could support multiple version of Java at the same time by renaming init.pp to version.pp, the way the boxen-nodejs and boxen-ruby work. The advantage of this would be that Boxen could be easily configured to install multiple versions of Java.

Something like this:

First rename init.pp to version.pp and make it a define instead of a class:

define java::version (
    $jdk_version, # Note no default value set
    $jdk_dirname,
) {
...
...
$jdk_url = "${base_download_url}/jdk-${jdk_version}-macosx-x64.dmg"
$jdk_dir = "/Library/Java/JavaVirtualMachines/${jdk_dirname}"

Then you can do what the boxen-nodejs package does and create files like this:

v7u51.pp:

class java::v7u51 {
    java::version { 'v7u51' :
        jdk_version = '7u51',
        jdk_dirname = 'jdk1.7.0_51.jdk',
    }
}

v8.pp:

class java::v8 {
    java::version { 'v8':
        jdk_version = '8',
        jdk_dirname = 'jdk1.8.0.jdk',
    }
}

Using this method, I'm not sure if an init.pp is still required or if any other changes would be required to the new version.pp file.

@jbcpollak I will add something like this to the pull request, when it is really necessary. The problems with with different versions do not exist for Java in the same way as for Ruby or node.js. I think a simple versioning of the Boxen module will fit well enough.

@jehrhardt - fair enough, but my reason for suggesting this change was to facilitate easily installing any version boxen users want, from the latest version of this project, without having to be limited to the single version supported by the version of the project. Supporting multiple installs just happens to be a side effect.

However, I do think there are legitimate usecases for having multiple versions of Java installed simultaneously. The most obvious one to me is what we do at my company, when we are upgrading between versions (it helps isolate problems). I know more enterprise level companies compile and release against multiple versions.

Most IDEs let you choose your JDK on a project-by-project basis as well, and I'm pretty sure people take advantage of that.

If I submitted a PR with this implemented, would you consider merging it? I don't think it adds significant complexity to the code.

I would like to get this pull request merged as is. So installation of Java 8 works.

The idea of supporting different versions of Java sounds interesting, but seems to fit better in a separate pull request.

I made an experimental multi-version branch here: https://github.com/jbcpollak/puppet-java/tree/multiVersion

It seems to work fine, although Java 8 is hard to test because its missing from S3. I haven't updated the unit tests yet.

I ran into a problem with the Java 7 installer though when Java 8 is already installed, and I haven't been able to solve that: #34 Its not a problem with the code itself, but it is unfortunately a blocker to supporting multiple Java versions with Boxen. (Or even installing Java 7 with Boxen if a user has already installed Java 8).

Hey @jbcpollak, I'm in the same boat in terms of needing multiple Java versions on the same machine. Do you have your boxen fork somewhere public so I can have a look at how you've done it? Happy to be a guinea pig for the testing. Cheers!

@mikeycmccarthy - you can see my branch here: https://github.com/jbcpollak/puppet-java/tree/multiVersion There is a problem though: If you already have Java 8 installed Java 7's installer will complain. It only complains when run from Boxen though, it doesn't complain when run from the commandline. I haven't figure out why.

My bad - I was actually looking to see your boxen files to see how you specify that you want two versions of Java on your workstation. Do you have a Puppetfile you can share?

Ah sorry, here are some instructions for trying it out:

1. Check out the branch above to ~/src/boxen/puppet-java. As far as I know, this path is not configurable, but I couldn't find a lot of documentation on it.
2. Modify your boxen Puppetfile like this:

#github "java",       "1.4.0"
dev "java"

3. modify manifests/site.pp, or whatever pp file you want to include Java like this:

#include java
include java::v7u51

You can't test installing JDK 8 yet because it hasn't been uploaded to the S3 account (as far as I know). You would use include java::v8u05 if it was available.

What I would really like to see is an installer like the Ubuntu one that downloads the package directly from Oracle.

OK, just gave that a go:

Error: Syntax error at '='; expected '}' at /opt/boxen/repo/shared/java/manifests/v7u51.pp:3 on node gl04632m.local

when I run Boxen. I commit my boxen and point you in the direction of it if it would help.

Will this be released in the near future?

Please merge it!
👍

👍

👍

👍

👍

@dgoodlad will you be pushing java 8 binaries up or should we close this?

👍

👍

When will this module be available in the master branch?

No body in this room?

@julienlavergne there isn't 24/7 support for boxen.

Please rebase this PR and then it can get merged.

It can get merged.

👍

Subscribing to this newsletter.

This should be good to go. Are you cool with that @dgoodlad?

What are your concerns for this module and Java 8 last release (31)?

On February 17, 2015 at 11:57:42 PM, Rick Bradley (notifications@github.com) wrote:

Subscribing to this newsletter.

—
Reply to this email directly or view it on GitHub.

I'm interested in knowing when this module lands to master so I can use it.
Otherwise, I'll import to a fork and redirect my Puppetfile to my fork.

On Tue, Feb 17, 2015 at 3:00 PM, Julien Lavergne notifications@github.com
wrote:

What are your concerns for this module and Java 8 last release (31)?

On February 17, 2015 at 11:57:42 PM, Rick Bradley (
notifications@github.com) wrote:

Subscribing to this newsletter.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#33 (comment).

You can also submit your contribution after that to the master via a pull request

Le 18 févr. 2015 à 00:12, Rick Bradley notifications@github.com a écrit :

I'm interested in knowing when this module lands to master so I can use it.
Otherwise, I'll import to a fork and redirect my Puppetfile to my fork.

On Tue, Feb 17, 2015 at 3:00 PM, Julien Lavergne notifications@github.com
wrote:

What are your concerns for this module and Java 8 last release (31)?

On February 17, 2015 at 11:57:42 PM, Rick Bradley (
notifications@github.com) wrote:

Subscribing to this newsletter.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#33 (comment).

—
Reply to this email directly or view it on GitHub.

I have no more objection to this; the reason I'd held off for quite awhile was worry about compatibility with ElasticSearch etc. I've spoken to a few people, all seems well, and folks who want to stay on Java 7 can simply continue using the older module version.

I reckon we merge and ship this as a new major version (2.0), and continue to maintain a 1.x branch for Java 7 compatibility if necessary.

When will this release 2.0 come? ;)

@dgoodlad Once #55 is merged, it wouldn't be hard to basically implement this fully backwards compatible.

So by default the module installs Java 7, but you can specify 8 if required! 👍

There are numerous use cases in the enterprise that require multiple installs of the JDK on developer machines. Whether supported by a single boxen puppet module or multiple tagged releases for JDK 7 and JDK 8 is not an issue. We will be hosting our DMG downloads internally. Hope something is released for JDK 8 soon. I am having to roll my own in the mean time.