Bug 96050 - Allow java/javavmwrapper to report the location of the JVM
Summary: Allow java/javavmwrapper to report the location of the JVM
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Greg Lewis
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-19 16:50 UTC by Jean-Baptiste Quenot
Modified: 2006-06-08 19:03 UTC (History)
1 user (show)

See Also:


Attachments
file.diff (2.00 KB, patch)
2006-04-19 16:50 UTC, Jean-Baptiste Quenot
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Baptiste Quenot 2006-04-19 16:50:15 UTC
Please see discussion at
http://lists.freebsd.org/pipermail/freebsd-java/2006-April/005152.html

The Java ports infrastructure provides ${JAVA_HOME} and ${JAVA} on build-time to
a port's Makefile, but it would be great to set the Java version requirement on
a per-port basis in the rc flags.  This requires to get JAVA_HOME and java
executable path from javavmwrapper at runtime.

The idea is to make javavm recognize two special environment variables:

JAVAVM_PRINT_JAVA_HOME

  When set, find the best suitable JVM and print the corresponding value of
  JAVA_HOME instead of executing the java program


JAVAVM_PRINT_JAVA_PROGRAM

  When set, find the best suitable JVM and print the path of the Java program
  instead of executing it

For this to  work correctly, we need javavm to  stop upon failure.  Until  now,
when  the  java program  cannot  be exec-uted,  javavm issues a warning and goes
on to the next JVM.

Thanks in advance!
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2006-04-19 16:56:08 UTC
Responsible Changed
From-To: freebsd-ports-bugs->glewis

Over to maintainer
Comment 2 Greg Lewis freebsd_committer freebsd_triage 2006-06-08 19:01:28 UTC
State Changed
From-To: open->closed

Thanks for the ideas.  I've implemented them in a different way using a 
single variable (JAVAVM_DRYRUN).  You should still be able to get the 
information you need (and more).  An example of extracting it is in the 
javavm manual page.