Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Jason van Zyl]

+1
 
> On Apr 25, 2016, at 7:59 AM, Michael Osipov  wrote:
> 
> Am 2016-04-15 um 22:34 schrieb Michael Osipov:
>> Hi folks,
>> 
>> we all know that people once in a while complain that my JAVA_HOME is
>> not properly discovered on $PLATFORM, etc. Surprisingly, we require
>> JAVA_HOME to be set in the installation documentation, yet we discover
>> it anyway. This is a contradiction. Moreover, our discovery mechanism
>> can never be complete and won't. It bloats.
>> 
>> In MNG-6003 [1], I propose to throw away all of this code and solely
>> rely on the dev's input. If he/she it not able to set it properly,
>> he/she shouldn't write code at all. Most of the time, on Unix/Linux,
>> this isn't even necessary because a JDK is installed by default.
>> 
>> I have created a feature branch [1] for this. If no one objects, I will
>> merge this into master.
>> 
>> The change have been tested with, without JAVA_HOME and invalid
>> JAVA_HOME on
>> 
>> * Windows 10
>> * Cygwin (Git Bash)
>> * Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from
>> /usr/local/bin)
>> * FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with
>> symlinks from /usr/local/bin)
> 
> Verified to work on OS X 10.7.x with latest Oracle JDK 1.8.0_92.
> 
> Compiled from branch snapshot with Maven 3.3.9 and then ran Maven 
> 3.4-SNAPSHOT to compile itself:
> MacPro:maven-MNG-6003-196234a do$ 
> /Users/do/apache-maven-3.4.0-SNAPSHOT/bin/mvn -v
> Apache Maven 3.4.0-SNAPSHOT (NON-CANONICAL_2016-04-23T13:05:55+02:00_do; 
> 2016-04-23T13:05:55+02:00)
> Maven home: /Users/do/apache-maven-3.4.0-SNAPSHOT
> Java version: 1.8.0_92, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "Mac OS X", version: "10.7.5", arch: "x86_64", family: "Unix"
> 
> and help:system says:
> ===
> = Platform Properties Details 
> =
> ===
> 
> ===
> System Properties
> ===
> 
> java.runtime.name=Java(TM) SE Runtime Environment
> sun.boot.library.path=/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib
> java.vm.version=25.92-b14
> gopherProxySet=false
> maven.multiModuleProjectDirectory=/Users/do/Downloads/maven-MNG-6003-196234a
> java.vm.vendor=Oracle Corporation
> java.vendor.url=http://java.oracle.com/
> guice.disable.misplaced.annotation.check=true
> path.separator=:
> java.vm.name=Java HotSpot(TM) 64-Bit Server VM
> file.encoding.pkg=sun.io
> user.country=DE
> sun.java.launcher=SUN_STANDARD
> sun.os.patch.level=unknown
> java.vm.specification.name=Java Virtual Machine Specification
> user.dir=/Users/do/Downloads/maven-MNG-6003-196234a
> java.runtime.version=1.8.0_92-b14
> java.awt.graphicsenv=sun.awt.CGraphicsEnvironment
> java.endorsed.dirs=/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/endorsed
> os.arch=x86_64
> java.io.tmpdir=/var/folders/w8/2p4kmj7n4xn51zf79swq4t6cgn/T/
> line.separator=
> 
> java.vm.specification.vendor=Oracle Corporation
> os.name=Mac OS X
> classworlds.conf=/Users/do/apache-maven-3.4.0-SNAPSHOT/bin/m2.conf
> sun.jnu.encoding=UTF-8
> java.library.path=/Users/do/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
> java.specification.name=Java Platform API Specification
> java.class.version=52.0
> sun.management.compiler=HotSpot 64-Bit Tiered Compilers
> os.version=10.7.5
> http.nonProxyHosts=local|*.local|169.254/16|*.169.254/16
> user.home=/Users/do
> user.timezone=Europe/Berlin
> java.awt.printerjob=sun.lwawt.macosx.CPrinterJob
> file.encoding=UTF-8
> java.specification.version=1.8
> java.class.path=/Users/do/apache-maven-3.4.0-SNAPSHOT/boot/plexus-classworlds-2.5.2.jar
> user.name=do
> java.vm.specification.version=1.8
> sun.java.command=org.codehaus.plexus.classworlds.launcher.Launcher help:system
> java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre
> sun.arch.data.model=64
> user.language=de
> java.specification.vendor=Oracle Corporation
> awt.toolkit=sun.lwawt.macosx.LWCToolkit
> java.vm.info=mixed mode
> java.version=1.8.0_92
> java.ext.dirs=/Users/do/Library/Java/Extensions:/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
> 

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Michael Osipov]

Am 2016-04-15 um 22:34 schrieb Michael Osipov:

Hi folks,

we all know that people once in a while complain that my JAVA_HOME is
not properly discovered on $PLATFORM, etc. Surprisingly, we require
JAVA_HOME to be set in the installation documentation, yet we discover
it anyway. This is a contradiction. Moreover, our discovery mechanism
can never be complete and won't. It bloats.

In MNG-6003 [1], I propose to throw away all of this code and solely
rely on the dev's input. If he/she it not able to set it properly,
he/she shouldn't write code at all. Most of the time, on Unix/Linux,
this isn't even necessary because a JDK is installed by default.

I have created a feature branch [1] for this. If no one objects, I will
merge this into master.

The change have been tested with, without JAVA_HOME and invalid
JAVA_HOME on

* Windows 10
* Cygwin (Git Bash)
* Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from
/usr/local/bin)
* FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with
symlinks from /usr/local/bin)


Verified to work on OS X 10.7.x with latest Oracle JDK 1.8.0_92.

Compiled from branch snapshot with Maven 3.3.9 and then ran Maven 
3.4-SNAPSHOT to compile itself:
MacPro:maven-MNG-6003-196234a do$ 
/Users/do/apache-maven-3.4.0-SNAPSHOT/bin/mvn -v
Apache Maven 3.4.0-SNAPSHOT (NON-CANONICAL_2016-04-23T13:05:55+02:00_do; 
2016-04-23T13:05:55+02:00)

Maven home: /Users/do/apache-maven-3.4.0-SNAPSHOT
Java version: 1.8.0_92, vendor: Oracle Corporation
Java home: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre

Default locale: de_DE, platform encoding: UTF-8
OS name: "Mac OS X", version: "10.7.5", arch: "x86_64", family: "Unix"

and help:system says:
===
= Platform Properties Details 
=

===

===
System Properties
===

java.runtime.name=Java(TM) SE Runtime Environment
sun.boot.library.path=/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib
java.vm.version=25.92-b14
gopherProxySet=false
maven.multiModuleProjectDirectory=/Users/do/Downloads/maven-MNG-6003-196234a
java.vm.vendor=Oracle Corporation
java.vendor.url=http://java.oracle.com/
guice.disable.misplaced.annotation.check=true
path.separator=:
java.vm.name=Java HotSpot(TM) 64-Bit Server VM
file.encoding.pkg=sun.io
user.country=DE
sun.java.launcher=SUN_STANDARD
sun.os.patch.level=unknown
java.vm.specification.name=Java Virtual Machine Specification
user.dir=/Users/do/Downloads/maven-MNG-6003-196234a
java.runtime.version=1.8.0_92-b14
java.awt.graphicsenv=sun.awt.CGraphicsEnvironment
java.endorsed.dirs=/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/endorsed
os.arch=x86_64
java.io.tmpdir=/var/folders/w8/2p4kmj7n4xn51zf79swq4t6cgn/T/
line.separator=

java.vm.specification.vendor=Oracle Corporation
os.name=Mac OS X
classworlds.conf=/Users/do/apache-maven-3.4.0-SNAPSHOT/bin/m2.conf
sun.jnu.encoding=UTF-8
java.library.path=/Users/do/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
java.specification.name=Java Platform API Specification
java.class.version=52.0
sun.management.compiler=HotSpot 64-Bit Tiered Compilers
os.version=10.7.5
http.nonProxyHosts=local|*.local|169.254/16|*.169.254/16
user.home=/Users/do
user.timezone=Europe/Berlin
java.awt.printerjob=sun.lwawt.macosx.CPrinterJob
file.encoding=UTF-8
java.specification.version=1.8
java.class.path=/Users/do/apache-maven-3.4.0-SNAPSHOT/boot/plexus-classworlds-2.5.2.jar
user.name=do
java.vm.specification.version=1.8
sun.java.command=org.codehaus.plexus.classworlds.launcher.Launcher 
help:system

java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre
sun.arch.data.model=64
user.language=de
java.specification.vendor=Oracle Corporation
awt.toolkit=sun.lwawt.macosx.LWCToolkit
java.vm.info=mixed mode
java.version=1.8.0_92
java.ext.dirs=/Users/do/Library/Java/Extensions:/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Andreas Sewe]

Hi,

>> FYI, Hudson 3.2.2 (in use for most builds at the Eclipse Foundation)
>> does use the mvn script:

BTW, this is the same with the latest Hudson (version 3.3.3) as well, so
this seems to be a place where it diverged from Jenkins.

>>> [INFO] Using Maven 3 installation: apache-maven-latest
>>> [INFO] Checking Maven 3 installation environment
>>> [JavaSE-1.8] $ /shared/common/apache-maven-latest/bin/mvn --help
>>> [INFO] Checking Maven 3 installation version
>>> [INFO] Detected Maven 3 installation version: 3.3.9
>>> [JavaSE-1.8] $ /shared/common/apache-maven-latest/bin/mvn ...
>>> [DEBUG] Waiting for connection on port: 52641
>>> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>>> 2015-11-10T11:41:47-05:00)
>>> Maven home: /shared/common/apache-maven-latest
>>> Java version: 1.8.0_51, vendor: Oracle Corporation
>>> Java home: /opt/public/common/jdk1.8.0_51.x64/jre
>>> Default locale: en_US, platform encoding: UTF-8
>>> OS name: "linux", version: "3.0.101-0.47.71-default", arch: "amd64",
>>> family: "unix"
> 
> Ah ok, what about JAVA_HOME? Set or from PATH?

I am not the admin of our Hudson instance (it's managed by the Eclipse
Foundation), but I think JAVA_HOME is set. See [1] for the intricacies
of our project's particular setup.

That being said, we specifically requested a change to the setup; I
don't know what Hudson instances at Eclipse do by *default*; AFAIK, they
just use the Java install Hudson runs on, but if Hudson itself requires
JAVA_HOME to be set or if it also allows for Java to be autodiscovered I
don't know.

Hope this helps.

Andreas

[1] 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Michael Osipov]

Am 2016-04-17 um 20:53 schrieb Andreas Sewe:

Hi,


Please go ahead and test it.

Jenkins does not use the script as it seems:
[maven-3.x] $
/home/jenkins/jenkins-slave/tools/hudson.model.JDK/jdk-1.7u51/bin/java
-Xmx2g -Xms256m -XX:MaxPermSize=512m -cp
/home/jenkins/jenkins-slave/maven3-agent.jar:/home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5/boot/plexus-classworlds-2.4.jar
org.jvnet.hudson.maven3.agent.Maven3Main
/home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5
/home/jenkins/jenkins-slave/slave.jar
/home/jenkins/jenkins-slave/maven3-interceptor.jar
/home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 36465


FYI, Hudson 3.2.2 (in use for most builds at the Eclipse Foundation)
does use the mvn script:


[INFO] Using Maven 3 installation: apache-maven-latest
[INFO] Checking Maven 3 installation environment
[JavaSE-1.8] $ /shared/common/apache-maven-latest/bin/mvn --help
[INFO] Checking Maven 3 installation version
[INFO] Detected Maven 3 installation version: 3.3.9
[JavaSE-1.8] $ /shared/common/apache-maven-latest/bin/mvn ...
[DEBUG] Waiting for connection on port: 52641
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T11:41:47-05:00)
Maven home: /shared/common/apache-maven-latest
Java version: 1.8.0_51, vendor: Oracle Corporation
Java home: /opt/public/common/jdk1.8.0_51.x64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.0.101-0.47.71-default", arch: "amd64", family: 
"unix"


Ah ok, what about JAVA_HOME? Set or from PATH?


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Arnaud Héritier]

>
> Please go ahead and test it.
>

I'll do it on my side but not before 1 week


>
> Jenkins does not use the script as it seems:
> [maven-3.x] $
> /home/jenkins/jenkins-slave/tools/hudson.model.JDK/jdk-1.7u51/bin/java
> -Xmx2g -Xms256m -XX:MaxPermSize=512m -cp
> /home/jenkins/jenkins-slave/maven3-agent.jar:/home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5/boot/plexus-classworlds-2.4.jar
> org.jvnet.hudson.maven3.agent.Maven3Main
> /home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5
> /home/jenkins/jenkins-slave/slave.jar
> /home/jenkins/jenkins-slave/maven3-interceptor.jar
> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 36465
>
>
Take care this is the command line for a Maven Job (which isn't
use/appreciated by everyone). If you call Maven from a build step in a
Maven job it will use the real maven script to start (AFAIR) and I don't
remember if we setup the JAVA_HOME environment variable


Cheers


> Michael
>
>
> On Apr 17, 2016, at 8:37 AM, Michael Osipov 
>>> wrote:
>>>
>>> Am 2016-04-17 um 17:24 schrieb Jason van Zyl:
>>>
 So will the proposed behavior be I upgrade Maven, I don’t have
 JAVA_HOME set manually and Maven will error out?

>>>
>>> No, if Java in PATH is a JDK, it will continue to work as usual.
>>> This is probably the case on most dev machines.
>>>
>>> Michael
>>>
>>> On Apr 15, 2016, at 1:34 PM, Michael Osipov
>  wrote:
>
> Hi folks,
>
> we all know that people once in a while complain that my
> JAVA_HOME is not properly discovered on $PLATFORM, etc.
> Surprisingly, we require JAVA_HOME to be set in the
> installation documentation, yet we discover it anyway. This is
> a contradiction. Moreover, our discovery mechanism can never be
> complete and won't. It bloats.
>
> In MNG-6003 [1], I propose to throw away all of this code and
> solely rely on the dev's input. If he/she it not able to set it
> properly, he/she shouldn't write code at all. Most of the time,
> on Unix/Linux, this isn't even necessary because a JDK is
> installed by default.
>
> I have created a feature branch [1] for this. If no one
> objects, I will merge this into master.
>
> The change have been tested with, without JAVA_HOME and invalid
> JAVA_HOME on
>
> * Windows 10 * Cygwin (Git Bash) * Ubuntu 14.04 LTS (from /home
> as well as /opt and with symlinks from /usr/local/bin) *
> FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and
> with symlinks from /usr/local/bin)
>
> Please have a look especially on your platform.
>
> Michael
>
> [1] https://issues.apache.org/jira/browse/MNG-6003 [2]
>
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=196234a95f7d5ade0b0b905308c2083e856cd121
>
>
>
> -
>
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
> additional commands, e-mail: dev-h...@maven.apache.org
>
>
 Thanks,

 Jason

 -- Jason
 van Zyl Founder, Takari and Apache Maven
 http://twitter.com/jvanzyl http://twitter.com/takari_io
 -



 -


 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
>> For additional commands, e-mail: dev-h...@maven.apache.org



>>>
>>>
>>> -
>>>
>>>
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> -- Jason van
>> Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>>
>>
>>
>> -
>>
>>
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Andreas Sewe]

Hi,

> Please go ahead and test it.
> 
> Jenkins does not use the script as it seems:
> [maven-3.x] $
> /home/jenkins/jenkins-slave/tools/hudson.model.JDK/jdk-1.7u51/bin/java
> -Xmx2g -Xms256m -XX:MaxPermSize=512m -cp
> /home/jenkins/jenkins-slave/maven3-agent.jar:/home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5/boot/plexus-classworlds-2.4.jar
> org.jvnet.hudson.maven3.agent.Maven3Main
> /home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5
> /home/jenkins/jenkins-slave/slave.jar
> /home/jenkins/jenkins-slave/maven3-interceptor.jar
> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 36465

FYI, Hudson 3.2.2 (in use for most builds at the Eclipse Foundation)
does use the mvn script:

> [INFO] Using Maven 3 installation: apache-maven-latest
> [INFO] Checking Maven 3 installation environment
> [JavaSE-1.8] $ /shared/common/apache-maven-latest/bin/mvn --help
> [INFO] Checking Maven 3 installation version
> [INFO] Detected Maven 3 installation version: 3.3.9
> [JavaSE-1.8] $ /shared/common/apache-maven-latest/bin/mvn ...
> [DEBUG] Waiting for connection on port: 52641
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T11:41:47-05:00)
> Maven home: /shared/common/apache-maven-latest
> Java version: 1.8.0_51, vendor: Oracle Corporation
> Java home: /opt/public/common/jdk1.8.0_51.x64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.0.101-0.47.71-default", arch: "amd64", family: 
> "unix"

Hope that helps.

Andreas

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Michael Osipov]

Am 2016-04-17 um 18:19 schrieb Jason van Zyl:

You answered with a condition and an assumption. I’ll be more
specific.

On a Mac where discovery works well, a new user installs Java, brew
installs Maven and it works. Does this still work?


I have requested everyone to test the branch as I do not have access to 
all types of platforms. Ultimately, if we perform an auto-discovery it 
is a lie that we require JAVA_HOME to be set. Either docs are wrong or 
our script is.


It seems like brew sets JAVA_HOME for you: 
https://github.com/Homebrew/homebrew-core/blob/fb81645562f7e495a49561065912788af2d1f14f/Formula/maven.rb#L27



I will check our CI servers, but if those stop working after an
upgrade I would be an unhappy user as would the thousands of people
using our CI cluster if their jobs broke. I don’t really want to
change 400 slaves. I’d have to double check how Java and Maven
interact in Jenkins. I’m actually not sure what it does exactly
insofar as relying on something set in a plugin, paths or discovery.
If you broke how Maven works in CI servers that would not be nice.


Please go ahead and test it.

Jenkins does not use the script as it seems:
[maven-3.x] $ 
/home/jenkins/jenkins-slave/tools/hudson.model.JDK/jdk-1.7u51/bin/java 
-Xmx2g -Xms256m -XX:MaxPermSize=512m -cp 
/home/jenkins/jenkins-slave/maven3-agent.jar:/home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5/boot/plexus-classworlds-2.4.jar 
org.jvnet.hudson.maven3.agent.Maven3Main 
/home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5 
/home/jenkins/jenkins-slave/slave.jar 
/home/jenkins/jenkins-slave/maven3-interceptor.jar 
/home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 36465


Michael


On Apr 17, 2016, at 8:37 AM, Michael Osipov 
wrote:

Am 2016-04-17 um 17:24 schrieb Jason van Zyl:

So will the proposed behavior be I upgrade Maven, I don’t have
JAVA_HOME set manually and Maven will error out?


No, if Java in PATH is a JDK, it will continue to work as usual.
This is probably the case on most dev machines.

Michael


On Apr 15, 2016, at 1:34 PM, Michael Osipov
 wrote:

Hi folks,

we all know that people once in a while complain that my
JAVA_HOME is not properly discovered on $PLATFORM, etc.
Surprisingly, we require JAVA_HOME to be set in the
installation documentation, yet we discover it anyway. This is
a contradiction. Moreover, our discovery mechanism can never be
complete and won't. It bloats.

In MNG-6003 [1], I propose to throw away all of this code and
solely rely on the dev's input. If he/she it not able to set it
properly, he/she shouldn't write code at all. Most of the time,
on Unix/Linux, this isn't even necessary because a JDK is
installed by default.

I have created a feature branch [1] for this. If no one
objects, I will merge this into master.

The change have been tested with, without JAVA_HOME and invalid
JAVA_HOME on

* Windows 10 * Cygwin (Git Bash) * Ubuntu 14.04 LTS (from /home
as well as /opt and with symlinks from /usr/local/bin) *
FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and
with symlinks from /usr/local/bin)

Please have a look especially on your platform.

Michael

[1] https://issues.apache.org/jira/browse/MNG-6003 [2]
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=196234a95f7d5ade0b0b905308c2083e856cd121




-

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
additional commands, e-mail: dev-h...@maven.apache.org



Thanks,

Jason

-- Jason
van Zyl Founder, Takari and Apache Maven
http://twitter.com/jvanzyl http://twitter.com/takari_io
-



-



To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For additional commands, e-mail: dev-h...@maven.apache.org






-



To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For additional commands, e-mail: dev-h...@maven.apache.org


Thanks,

Jason

-- Jason van
Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



-



To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For additional commands, e-mail: dev-h...@maven.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Jason van Zyl]

You answered with a condition and an assumption. I’ll be more specific.

On a Mac where discovery works well, a new user installs Java, brew installs 
Maven and it works. Does this still work?

I will check our CI servers, but if those stop working after an upgrade I would 
be an unhappy user as would the thousands of people using our CI cluster if 
their jobs broke. I don’t really want to change 400 slaves. I’d have to double 
check how Java and Maven interact in Jenkins. I’m actually not sure what it 
does exactly insofar as relying on something set in a plugin, paths or 
discovery. If you broke how Maven works in CI servers that would not be nice.

> On Apr 17, 2016, at 8:37 AM, Michael Osipov  wrote:
> 
> Am 2016-04-17 um 17:24 schrieb Jason van Zyl:
>> So will the proposed behavior be I upgrade Maven, I don’t have JAVA_HOME set 
>> manually and Maven will error out?
> 
> No, if Java in PATH is a JDK, it will continue to work as usual. This is 
> probably the case on most dev machines.
> 
> Michael
> 
>>> On Apr 15, 2016, at 1:34 PM, Michael Osipov  wrote:
>>> 
>>> Hi folks,
>>> 
>>> we all know that people once in a while complain that my JAVA_HOME is not 
>>> properly discovered on $PLATFORM, etc. Surprisingly, we require JAVA_HOME 
>>> to be set in the installation documentation, yet we discover it anyway. 
>>> This is a contradiction. Moreover, our discovery mechanism can never be 
>>> complete and won't. It bloats.
>>> 
>>> In MNG-6003 [1], I propose to throw away all of this code and solely rely 
>>> on the dev's input. If he/she it not able to set it properly, he/she 
>>> shouldn't write code at all. Most of the time, on Unix/Linux, this isn't 
>>> even necessary because a JDK is installed by default.
>>> 
>>> I have created a feature branch [1] for this. If no one objects, I will 
>>> merge this into master.
>>> 
>>> The change have been tested with, without JAVA_HOME and invalid JAVA_HOME on
>>> 
>>> * Windows 10
>>> * Cygwin (Git Bash)
>>> * Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from 
>>> /usr/local/bin)
>>> * FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with 
>>> symlinks from /usr/local/bin)
>>> 
>>> Please have a look especially on your platform.
>>> 
>>> Michael
>>> 
>>> [1] https://issues.apache.org/jira/browse/MNG-6003
>>> [2] 
>>> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=196234a95f7d5ade0b0b905308c2083e856cd121
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Michael Osipov]

Am 2016-04-17 um 17:24 schrieb Jason van Zyl:

So will the proposed behavior be I upgrade Maven, I don’t have JAVA_HOME set 
manually and Maven will error out?


No, if Java in PATH is a JDK, it will continue to work as usual. This is 
probably the case on most dev machines.


Michael


On Apr 15, 2016, at 1:34 PM, Michael Osipov  wrote:

Hi folks,

we all know that people once in a while complain that my JAVA_HOME is not 
properly discovered on $PLATFORM, etc. Surprisingly, we require JAVA_HOME to be 
set in the installation documentation, yet we discover it anyway. This is a 
contradiction. Moreover, our discovery mechanism can never be complete and 
won't. It bloats.

In MNG-6003 [1], I propose to throw away all of this code and solely rely on 
the dev's input. If he/she it not able to set it properly, he/she shouldn't 
write code at all. Most of the time, on Unix/Linux, this isn't even necessary 
because a JDK is installed by default.

I have created a feature branch [1] for this. If no one objects, I will merge 
this into master.

The change have been tested with, without JAVA_HOME and invalid JAVA_HOME on

* Windows 10
* Cygwin (Git Bash)
* Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from 
/usr/local/bin)
* FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with symlinks 
from /usr/local/bin)

Please have a look especially on your platform.

Michael

[1] https://issues.apache.org/jira/browse/MNG-6003
[2] 
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=196234a95f7d5ade0b0b905308c2083e856cd121

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Jason van Zyl]

So will the proposed behavior be I upgrade Maven, I don’t have JAVA_HOME set 
manually and Maven will error out?

> On Apr 15, 2016, at 1:34 PM, Michael Osipov  wrote:
> 
> Hi folks,
> 
> we all know that people once in a while complain that my JAVA_HOME is not 
> properly discovered on $PLATFORM, etc. Surprisingly, we require JAVA_HOME to 
> be set in the installation documentation, yet we discover it anyway. This is 
> a contradiction. Moreover, our discovery mechanism can never be complete and 
> won't. It bloats.
> 
> In MNG-6003 [1], I propose to throw away all of this code and solely rely on 
> the dev's input. If he/she it not able to set it properly, he/she shouldn't 
> write code at all. Most of the time, on Unix/Linux, this isn't even necessary 
> because a JDK is installed by default.
> 
> I have created a feature branch [1] for this. If no one objects, I will merge 
> this into master.
> 
> The change have been tested with, without JAVA_HOME and invalid JAVA_HOME on
> 
> * Windows 10
> * Cygwin (Git Bash)
> * Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from 
> /usr/local/bin)
> * FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with 
> symlinks from /usr/local/bin)
> 
> Please have a look especially on your platform.
> 
> Michael
> 
> [1] https://issues.apache.org/jira/browse/MNG-6003
> [2] 
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=196234a95f7d5ade0b0b905308c2083e856cd121
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Arnaud Héritier]

On MacOS I'using JENV which wraps tools calls like maven to setup
accordingly the JAVA_HOME based on the global/local/session setting

http://www.jenv.be

As a developper I have exactly the liberty I need and I can switch to any
version of java

On Sat, Apr 16, 2016 at 8:55 PM, Michael Osipov  wrote:

> Am 2016-04-16 um 17:07 schrieb Robert Scholte:
>
>> On Sat, 16 Apr 2016 16:48:42 +0200, Michael Osipov 
>> wrote:
>>
>> Am 2016-04-16 um 14:38 schrieb Robert Scholte:
>>>
 Hi,

 Maybe this is also the right moment to introduce a Maven specific
 JAVA_HOME, e.g. maven.JAVA_HOME
 The reason: there are other tools which depend on the JAVA_HOME variable
 as well, but that's not necessary the same JAVA_HOME you want to use for
 Maven.

>>>
>>> Which are?
>>>
>>
>> My first hits with Google are Glassfish and Confluence, but there are
>> many more.
>> IIRC SoapUI too and I know quite a lot of projects using this tool.
>>
>
> I thought you were refering anything inside Maven. Most of those tools
> start with the system and PATH is mostly naked...
>
>
>>> So it is best to fail when JAVA_HOME isn't set/valid?
>>>
>>
>> not sure, but I suggest to check for a Maven specific JAVA_HOME first,
>> next the (global) JAVA_HOME and finally installed version or fail.
>>
>
> This makes the stuff more compicated than I have intended. I wanted it to
> be as simple as possible. The rest is the dev's responsibility.
>
>
>
> On Fri, 15 Apr 2016 22:34:29 +0200, Michael Osipov 
 wrote:

 Hi folks,
>
> we all know that people once in a while complain that my JAVA_HOME is
> not properly discovered on $PLATFORM, etc. Surprisingly, we require
> JAVA_HOME to be set in the installation documentation, yet we discover
> it anyway. This is a contradiction. Moreover, our discovery mechanism
> can never be complete and won't. It bloats.
>
> In MNG-6003 [1], I propose to throw away all of this code and solely
> rely on the dev's input. If he/she it not able to set it properly,
> he/she shouldn't write code at all. Most of the time, on Unix/Linux,
> this isn't even necessary because a JDK is installed by default.
>
> I have created a feature branch [1] for this. If no one objects, I
> will merge this into master.
>
> The change have been tested with, without JAVA_HOME and invalid
> JAVA_HOME on
>
> * Windows 10
> * Cygwin (Git Bash)
> * Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from
> /usr/local/bin)
> * FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with
> symlinks from /usr/local/bin)
>
> Please have a look especially on your platform.
>
> Michael
>
> [1] https://issues.apache.org/jira/browse/MNG-6003
> [2]
>
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=196234a95f7d5ade0b0b905308c2083e856cd121
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Michael Osipov]

Am 2016-04-16 um 17:07 schrieb Robert Scholte:

On Sat, 16 Apr 2016 16:48:42 +0200, Michael Osipov 
wrote:


Am 2016-04-16 um 14:38 schrieb Robert Scholte:

Hi,

Maybe this is also the right moment to introduce a Maven specific
JAVA_HOME, e.g. maven.JAVA_HOME
The reason: there are other tools which depend on the JAVA_HOME variable
as well, but that's not necessary the same JAVA_HOME you want to use for
Maven.


Which are?


My first hits with Google are Glassfish and Confluence, but there are
many more.
IIRC SoapUI too and I know quite a lot of projects using this tool.


I thought you were refering anything inside Maven. Most of those tools 
start with the system and PATH is mostly naked...




So it is best to fail when JAVA_HOME isn't set/valid?


not sure, but I suggest to check for a Maven specific JAVA_HOME first,
next the (global) JAVA_HOME and finally installed version or fail.


This makes the stuff more compicated than I have intended. I wanted it 
to be as simple as possible. The rest is the dev's responsibility.




On Fri, 15 Apr 2016 22:34:29 +0200, Michael Osipov 
wrote:


Hi folks,

we all know that people once in a while complain that my JAVA_HOME is
not properly discovered on $PLATFORM, etc. Surprisingly, we require
JAVA_HOME to be set in the installation documentation, yet we discover
it anyway. This is a contradiction. Moreover, our discovery mechanism
can never be complete and won't. It bloats.

In MNG-6003 [1], I propose to throw away all of this code and solely
rely on the dev's input. If he/she it not able to set it properly,
he/she shouldn't write code at all. Most of the time, on Unix/Linux,
this isn't even necessary because a JDK is installed by default.

I have created a feature branch [1] for this. If no one objects, I
will merge this into master.

The change have been tested with, without JAVA_HOME and invalid
JAVA_HOME on

* Windows 10
* Cygwin (Git Bash)
* Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from
/usr/local/bin)
* FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with
symlinks from /usr/local/bin)

Please have a look especially on your platform.

Michael

[1] https://issues.apache.org/jira/browse/MNG-6003
[2]
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=196234a95f7d5ade0b0b905308c2083e856cd121



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Robert Scholte]

On Sat, 16 Apr 2016 16:48:42 +0200, Michael Osipov   
wrote:



Am 2016-04-16 um 14:38 schrieb Robert Scholte:

Hi,

Maybe this is also the right moment to introduce a Maven specific
JAVA_HOME, e.g. maven.JAVA_HOME
The reason: there are other tools which depend on the JAVA_HOME variable
as well, but that's not necessary the same JAVA_HOME you want to use for
Maven.


Which are?


My first hits with Google are Glassfish and Confluence, but there are many  
more.

IIRC SoapUI too and I know quite a lot of projects using this tool.

In general tools will probably work fine if JAVA_HOME is recent enough,  
but once developers need control over it they're stuck.




So it is best to fail when JAVA_HOME isn't set/valid?


not sure, but I suggest to check for a Maven specific JAVA_HOME first,  
next the (global) JAVA_HOME and finally installed version or fail.


Robert




On Fri, 15 Apr 2016 22:34:29 +0200, Michael Osipov 
wrote:


Hi folks,

we all know that people once in a while complain that my JAVA_HOME is
not properly discovered on $PLATFORM, etc. Surprisingly, we require
JAVA_HOME to be set in the installation documentation, yet we discover
it anyway. This is a contradiction. Moreover, our discovery mechanism
can never be complete and won't. It bloats.

In MNG-6003 [1], I propose to throw away all of this code and solely
rely on the dev's input. If he/she it not able to set it properly,
he/she shouldn't write code at all. Most of the time, on Unix/Linux,
this isn't even necessary because a JDK is installed by default.

I have created a feature branch [1] for this. If no one objects, I
will merge this into master.

The change have been tested with, without JAVA_HOME and invalid
JAVA_HOME on

* Windows 10
* Cygwin (Git Bash)
* Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from
/usr/local/bin)
* FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with
symlinks from /usr/local/bin)

Please have a look especially on your platform.

Michael

[1] https://issues.apache.org/jira/browse/MNG-6003
[2]
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=196234a95f7d5ade0b0b905308c2083e856cd121


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Michael Osipov]

Am 2016-04-16 um 14:38 schrieb Robert Scholte:

Hi,

Maybe this is also the right moment to introduce a Maven specific
JAVA_HOME, e.g. maven.JAVA_HOME
The reason: there are other tools which depend on the JAVA_HOME variable
as well, but that's not necessary the same JAVA_HOME you want to use for
Maven.


Which are?

So it is best to fail when JAVA_HOME isn't set/valid?


On Fri, 15 Apr 2016 22:34:29 +0200, Michael Osipov 
wrote:


Hi folks,

we all know that people once in a while complain that my JAVA_HOME is
not properly discovered on $PLATFORM, etc. Surprisingly, we require
JAVA_HOME to be set in the installation documentation, yet we discover
it anyway. This is a contradiction. Moreover, our discovery mechanism
can never be complete and won't. It bloats.

In MNG-6003 [1], I propose to throw away all of this code and solely
rely on the dev's input. If he/she it not able to set it properly,
he/she shouldn't write code at all. Most of the time, on Unix/Linux,
this isn't even necessary because a JDK is installed by default.

I have created a feature branch [1] for this. If no one objects, I
will merge this into master.

The change have been tested with, without JAVA_HOME and invalid
JAVA_HOME on

* Windows 10
* Cygwin (Git Bash)
* Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from
/usr/local/bin)
* FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with
symlinks from /usr/local/bin)

Please have a look especially on your platform.

Michael

[1] https://issues.apache.org/jira/browse/MNG-6003
[2]
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=196234a95f7d5ade0b0b905308c2083e856cd121


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Robert Scholte]

Hi,

Maybe this is also the right moment to introduce a Maven specific  
JAVA_HOME, e.g. maven.JAVA_HOME
The reason: there are other tools which depend on the JAVA_HOME variable  
as well, but that's not necessary the same JAVA_HOME you want to use for  
Maven.


Robert

On Fri, 15 Apr 2016 22:34:29 +0200, Michael Osipov   
wrote:



Hi folks,

we all know that people once in a while complain that my JAVA_HOME is  
not properly discovered on $PLATFORM, etc. Surprisingly, we require  
JAVA_HOME to be set in the installation documentation, yet we discover  
it anyway. This is a contradiction. Moreover, our discovery mechanism  
can never be complete and won't. It bloats.


In MNG-6003 [1], I propose to throw away all of this code and solely  
rely on the dev's input. If he/she it not able to set it properly,  
he/she shouldn't write code at all. Most of the time, on Unix/Linux,  
this isn't even necessary because a JDK is installed by default.


I have created a feature branch [1] for this. If no one objects, I will  
merge this into master.


The change have been tested with, without JAVA_HOME and invalid  
JAVA_HOME on


* Windows 10
* Cygwin (Git Bash)
* Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from  
/usr/local/bin)
* FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with  
symlinks from /usr/local/bin)


Please have a look especially on your platform.

Michael

[1] https://issues.apache.org/jira/browse/MNG-6003
[2]  
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=196234a95f7d5ade0b0b905308c2083e856cd121


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Michael Osipov]

Am 2016-04-15 um 22:34 schrieb Michael Osipov:

Hi folks,

we all know that people once in a while complain that my JAVA_HOME is
not properly discovered on $PLATFORM, etc. Surprisingly, we require
JAVA_HOME to be set in the installation documentation, yet we discover
it anyway. This is a contradiction. Moreover, our discovery mechanism
can never be complete and won't. It bloats.

In MNG-6003 [1], I propose to throw away all of this code and solely
rely on the dev's input. If he/she it not able to set it properly,
he/she shouldn't write code at all. Most of the time, on Unix/Linux,
this isn't even necessary because a JDK is installed by default.

I have created a feature branch [1] for this. If no one objects, I will
merge this into master.

The change have been tested with, without JAVA_HOME and invalid
JAVA_HOME on

* Windows 10
* Cygwin (Git Bash)
* Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from
/usr/local/bin)
* FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with
symlinks from /usr/local/bin)


Just wanted to add that I took the Tomcat startup scripts as examples 
and for decades Tomcat does not intentionally perform any magic to find 
the runtime. You either have set or you fail. It is that simple.


M


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Michael Osipov]

Am 2016-04-16 um 02:42 schrieb Dan Tran:

the discovery of java home at Linux is a  fantastic feature.


There is too much magic involved and there are too many distros to make 
it right.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Michael Osipov]

Am 2016-04-16 um 01:43 schrieb Christian Schulte:

And I do have seen systems installing some shell script at
'/usr/bin/java' not even beeing a Java launcher at all.


This is the case with FreeBSD.


+1 for the branch
-∞ for `which java`


Still no problem if you point to a JDK in PATH.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Michael Osipov]

Am 2016-04-16 um 01:27 schrieb Christian Schulte:

Am 04/15/16 um 22:34 schrieb Michael Osipov:

In MNG-6003 [1], I propose to throw away all of this code and solely
rely on the dev's input. If he/she it not able to set it properly,
he/she shouldn't write code at all. Most of the time, on Unix/Linux,
this isn't even necessary because a JDK is installed by default.


+1

I would go even further. Just error out if JAVA_HOME is not defined. In
my opinion discovery of the 'java' launcher to use based on `which java`
should also go away. Just make the scripts require JAVA_HOME to be
defined and not try to discover anything automatically. On my machine I
have

/usr/local/jdk-1.7.0
/usr/local/jre-1.7.0
/usr/local/jdk-1.8.0
/usr/local/jre-1.8.0

The PATH contains /usr/local/jre-1.8.0/bin. The JRE directories have the
java jurisdiction policy files installed. The JDK directories do not.
The JDK keystores contain certificates the JRE directories do not
contain etc. With my setup, `which java` points to a JRE launcher, not a
JDK launcher. JAVA_HOME always points to a JDK. So `which java` is
useless here and somehow error prone if I screw up JAVA_HOME.


In this case, you can simply set JAVA_HOME as instructed by the install 
docs. `which java` is an assumption which works mostly on Unix.


The keystore problem is solely your distro problem.

Is there a reason why you did install the JRE at all? I haven't done 
this on Linux, FreeBSD and HP-UX becuase I see no reason to waste 
duplicate space.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Christian Schulte]

Am 04/16/16 um 02:42 schrieb Dan Tran:
> the discovery of java home at Linux is a  fantastic feature.

Depends on what packages you install. Install a JRE and a JDK and things
get messed up. Gave up on all Linux almost a decade ago. So maybe things
have changed recently. So

+1 for the discovery of java home at Linux being a fantastic feature
(until the other day)

\,,/(-_-)\,,/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Dan Tran]

the discovery of java home at Linux is a  fantastic feature.



On Fri, Apr 15, 2016 at 4:43 PM, Christian Schulte  wrote:

> And I do have seen systems installing some shell script at
> '/usr/bin/java' not even beeing a Java launcher at all.
>
> So,
>
> +1 for the branch
> -∞ for `which java`
>
> Regards,
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Christian Schulte]

And I do have seen systems installing some shell script at
'/usr/bin/java' not even beeing a Java launcher at all.

So,

+1 for the branch
-∞ for `which java`

Regards,


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Christian Schulte]

Am 04/15/16 um 22:34 schrieb Michael Osipov:
> In MNG-6003 [1], I propose to throw away all of this code and solely 
> rely on the dev's input. If he/she it not able to set it properly, 
> he/she shouldn't write code at all. Most of the time, on Unix/Linux, 
> this isn't even necessary because a JDK is installed by default.

+1

I would go even further. Just error out if JAVA_HOME is not defined. In
my opinion discovery of the 'java' launcher to use based on `which java`
should also go away. Just make the scripts require JAVA_HOME to be
defined and not try to discover anything automatically. On my machine I
have

/usr/local/jdk-1.7.0
/usr/local/jre-1.7.0
/usr/local/jdk-1.8.0
/usr/local/jre-1.8.0

The PATH contains /usr/local/jre-1.8.0/bin. The JRE directories have the
java jurisdiction policy files installed. The JDK directories do not.
The JDK keystores contain certificates the JRE directories do not
contain etc. With my setup, `which java` points to a JRE launcher, not a
JDK launcher. JAVA_HOME always points to a JDK. So `which java` is
useless here and somehow error prone if I screw up JAVA_HOME.

Regards,


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org