Perhaps provide ability to install java in ~/Library instead

[toonetown]

I don't know all the details of how it would work, but it would be nice to be able to install the java JDK in a user's directory instead of forcing it to be in /Library (like the installer does).

I have patched up a version of java7.rb from caskroom/homebrew-versions as a proof of concept, and it seems to work fine...Rather than trying to submit it as a pull request, I thought I'd post it here for comment first.

Basically, it just unarchives the files and links them to the correct location. It did bring up something that I thought might be nice - it would be good to have the Java directory available as a variable, and that it could be specified as command-line options too (i.e. --javadir=<path> that defaults to /Library/Java...or even could default to ~/Library/Java).

This is just a thought - and I thought I'dd add it to this to solicit some feedback.

class Java7User < Cask
  version '1.7.0_67'
  sha256 'fa6b9bcc18ed951726da29d04252879c4263891178087e90ea224e68dd624bd2'

  url 'http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jdk-7u67-macosx-x64.dmg',
      :cookies => {
                    'oraclelicense' => 'accept-securebackup-cookie'
                  }
  homepage 'http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html'

  pkg_name = 'JDK 7 Update 67'
  artifact_name = "jdk#{version}.jdk"
  artifact_path = "#{ENV['HOME']}/Library/Java/JavaVirtualMachines/#{artifact_name}"

  preflight do
    unpacked = destination_path.join("#{pkg_name}.upkg")
    instdir = destination_path.join(artifact_name)
    system '/usr/sbin/pkgutil', '--expand', destination_path.join("#{pkg_name}.pkg"), unpacked
    system '/bin/mkdir', '--', instdir
    `/usr/bin/gzcat "#{unpacked}/jdk#{version.gsub(/[\._]/, '')}.pkg/Payload" | (cd "#{instdir}" && pax -r)`

    # Patch the jdk so that we don't have packaged application issues
    system '/usr/libexec/PlistBuddy', '-c', 'Add :JavaVM:JVMCapabilities: string BundledApp', "#{instdir}/Contents/Info.plist"
    system '/usr/libexec/PlistBuddy', '-c', 'Add :JavaVM:JVMCapabilities: string JNI',        "#{instdir}/Contents/Info.plist"
    system '/usr/libexec/PlistBuddy', '-c', 'Add :JavaVM:JVMCapabilities: string WebStart',   "#{instdir}/Contents/Info.plist"
    system '/usr/libexec/PlistBuddy', '-c', 'Add :JavaVM:JVMCapabilities: string Applets',    "#{instdir}/Contents/Info.plist"
  end

  artifact "#{artifact_name}", :target => "#{artifact_path}"

  caveats <<-EOS.undent
    This Cask makes minor modifications to the JRE to prevent any packaged
    application issues.

    If your Java application still asks for JRE installation, you might need to
    reboot or logout/login.

    The JRE packaging bug is discussed here:

        https://bugs.eclipse.org/bugs/show_bug.cgi?id=411361

    Installing this Cask means you have AGREED to the Oracle Binary Code License
    Agreement for Java SE at

        http://www.oracle.com/technetwork/java/javase/terms/license/index.html

    EOS
end

[rolandwalker]

That is beautiful.

We don't really want to put this much procedural code into a Cask, and we certainly don't want code in the Cask to be writing under destination_path. That's the job of the backend.

However, it would be nice to have backend code to support some subversions of the pkg install process, like you have in mind. See #5442. Note that I list two lines of attack, then a third possibility at the end. (The third way seems appealingly simple, but I have not tried it.)

One upshot of that discussion was the implementation of container :type => :xar, which I believe you could use to simplify your draft — it should unpack the pkg file and place the contents under destination_path where you want it.

But I assume the :xar container type is not sufficient, because there are archives within the pkg archive. I thought those would all be xar archives too, and that we could create container :type => :recursive_xar to keep unxaring down the tree. But I see you are using gzcat and pax. So I guess there are some other file formats in there.

In any case, it would be entirely reasonable to have something like :recursive_xar that fully unpacks pkg payloads and permits a symlink approach to installation. Because that's just treating a pkg like we treat any other type of archive.

The other approaches in #5442 may also be doable. So long as the complicated stuff happens in the backend.

[toonetown]

Yes - that is exactly what I'd like to have! It would be awesome (in some instances) to be able to "unpackage" a pkg file. They are, after all, mostly just xar and gzipped pax files. Sometimes a package does other stuff - but for the most part, you can just unpack it and move the stuff into any prefix you want.

It wouldn't be as simple to have as the pkg stanza.

[vitorgalvao]

Rejecting, in light of #13201.