I think tha JAVA_HOME should be automatically updated, or at least there should
be a way to triggere a custom script to update it.
GVM has a nice
# Attempt to set JAVA_HOME if it's not already set.
if [ -z "${JAVA_HOME}" ] ; then
if ${darwin} ; then
[ -z "${JAVA_HOME}" -a -f "/usr/l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010-07-30 18:57, Maxim Veksler wrote:
> Guys,
>
> Some solution should be found, and it's not necessarily update-
> alternatives.
>
> The JAVA_HOME setting is something _every_ java user on Ubuntu has to
> do, and as such I think a solution sho
Guys,
Some solution should be found, and it's not necessarily update-
alternatives.
The JAVA_HOME setting is something _every_ java user on Ubuntu has to
do, and as such I think a solution should be made.
Please don't assume this is a "corporate" only requirement, large and
highly successful ope
** Changed in: java-common (Ubuntu)
Status: Invalid => Won't Fix
--
update-java-alternatives does not change the JAVA_HOME
https://bugs.launchpad.net/bugs/45348
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailin
Hi
I am closing this as invalid[1]. In general, programs should work
without requiring a particular environment variable is set. Secondly it
is impossible for update-java-alternatives to update the variable of any
running terminal or X11 session. Also, as I recall, messing with
/etc/environment is
Getting to the bottom of the eclipse case, I'm starting to agree with
earlier posters.
If you specifically drop the JAVA_HOME which the eclipse script has
carefully introspected, and just use the java binary which is available
to you on the default path, leaving the final lines of /usr/bin/eclips
For reference, people wanting to get eclipse to work with the JVM it
requires for compatibility, you should edit /etc/eclipse/java_home and
add a comment (#) mark at the start of each line up to the one which
identifies your chosen jvm.
Don't know who this file is maintained by, but if eclipse is
I agree that update-java-alternatives should undertake to use all
available mechanisms to establish the user's chosen default version of
java gets communicated to loading applications which are simply making
standard assumptions about the way this dependency injection gets
resolved.
Above someone
Orthogonal task.
** Changed in: eclipse (Ubuntu)
Status: Confirmed => Invalid
** Changed in: java-common (Ubuntu)
Importance: Medium => Wishlist
--
update-java-alternatives does not change the JAVA_HOME
https://bugs.launchpad.net/bugs/45348
You received this bug notification because y
This is kind of a big issue..
Eclipse is practically unusable without a proper jvm.. It goes from
170MB right after starting it, to 17MB using java-6!
Is a workable workaround was found, it would be great!
** Also affects: eclipse (Ubuntu)
Importance: Undecided
Status: New
** Changed
Uh huh. Sounds about like how it works now, no? update-java-alternatives
configures a JVM tree at /usr. Or, enough of a JVM tree to work. Listing
/usr in either ~/.jvm or /etc/jvm should work fine.
--
update-java-alternatives does not change the JAVA_HOME
https://bugs.launchpad.net/bugs/45348
You
And why not mount the jvm scheme over the update-alternatives scheme?
In my case, I installed maven. Maven searches for /etc/mavenrc and
~/.mavenrc
If I create one of those files, Maven works OK. But as I see it, local
configurations are needed if I don't want to use my default
configuration, so
> could be simpler for a lot of java packages. Using update-java-
> alternatives as the only way of updating java configuration is, IMHO,
> the way to go.
I don't believe update-java-alternatives solves the per-user case, which
at least in my situations, has been very desired. Also, you need root
What I was trying to solve is that some (almost all) not apt-gettable
Java applications require a definition of JAVA_HOME.
- Some not available as DEBs (like Maven (maven.apache.org)).
- Some available but a new version is required (Ant, Eclipse).
Obviously I can edit the launch scripts to add
I don't believe I am particularly interested in setting JAVA_HOME by
default. After all, given a choice of N different JVMs a user may have
installed, which one should be chosen?
Additionally, Debian policy (unsure about Ubuntu's) does not allow a
program to require a certain environmental variabl
R. A. Rivas Diaz:
Your idea doesn't address the current need of applications to be
particular about which JVMs they support for a default experience. Not
all applications can point to a single system-wide default JVM.
Added to this, I suspect per-user configuration of which JVM is used
would stil
Has there been any development regarding this issue? Edgy still doesn't
set the JAVA_HOME variable automatically. Although it's easy to set by
hand, it clearly lowers the out-of-the-box usefulness for Java
developers. The SuSE distribution also uses the update-alternatives
mechanism and there JAVA_
17 matches
Mail list logo
