New jre layout broke Maven and Ant

[Jonathan Gibbons]

The separation between JDK and JRE will become blurred with Jigsaw -- 
you'll have a JRE + installed modules, and Jigsaw will locate and use 
the modules your app depends on.

Jigsaw is relevant because it will supersede the use of jar files going 
forward for JDK 8 and beyond, including, in particular, tools.jar, which 
was the origin of this thread.  In JDK 8, there will be no tools.jar.

-- Jon


On 09/30/2011 07:52 PM, Phil Race wrote:
>
> I honestly don't see how jigsaw is relevant. It might have a side 
> effect of providing a way of expressing
> a dependency, but it sounds like we already provide jars but no 
> standard way to even find them. Please
> tell me why this is so hard or unimportant ...
>
> -phil.
>
> On 9/30/11 6:58 PM, Jonathan Gibbons wrote:
>> Phil,
>>
>> Your questions are about N years out of date, where N is somewhere 
>> between 5 and 15 :-(
>>
>> Originally, the only clients of tools.jar were JDK tools like javac, 
>> javah, etc, and they had launcher support so there was no issue. It's 
>> only with the advent of additional tools that want to get direct API 
>> access to tools like javac that we have an issue with folk wanting 
>> direct access to tools.jar. And even then, it was easier for such 
>> tools to deal with the existing layout of existing JDK installations 
>> than to propose and deal with different ways to access everything.
>>
>> Going forward, JDK 8 will have Jigsaw, which will fix issues like 
>> this. And that will be fun :-)
>>
>> -- Jon
>>
>> On 09/30/2011 05:42 PM, Phil Race wrote:
>>> So we make people who need to use the code in tools.jar jump through 
>>> fragile hoops to
>>> find the classes there ? Why would you *not* add the jars and native 
>>> libs to the paths
>>> used by "java" in the JDK directory ?
>>>
>>> If tools.jar (and others) are needed by apps, they should be 
>>> available to them without
>>> knowing the directory structure of the JDK.
>>>
>>> -phil.
>>>
>>> On 9/30/11 5:26 PM, Jonathan Gibbons wrote:
>>>> Phil,
>>>>
>>>> If you invoke $JDK/bin/java, you simply end up in $JDK/jre/bin/java.
>>>>
>>>> Tools like javac are handled by the launcher and have thier own magic.
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 09/30/2011 09:23 AM, Phil Race wrote:
>>>>> I suppose I'm not seeing how this just now arises since I've 
>>>>> always assumed that apps that need tools.jar -
>>>>> or the other stuff in the JDK/lib directory should be using 
>>>>> $JDK/bin/java, not $JDK/jre/bin/java.
>>>>> I've further supposed that tools.jar is then automatically on the 
>>>>> classpath.
>>>>> I assume that "javac" works .. and $JDK/bin, and is finding rt.jar 
>>>>> is in the JRE subdirectory.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 9/30/11 4:01 PM, Eric Richardson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Some time back, Michael Franz and I experimented with compiling
>>>>>> Icetea/bsd-port/zero on Mac OSX PowerPC. We ran into the fact 
>>>>>> that the
>>>>>> Icetea harness expected a standard JDK/JRE layout on the file 
>>>>>> system.
>>>>>> We managed to create a script to symlink and copy some things about
>>>>>> and Michael managed to make it so the Mac OSX Java 5 could bootstrap
>>>>>> the system.
>>>>>>
>>>>>> Anyway, to make this short, I think it is a good idea if the 
>>>>>> layout is
>>>>>> the same across OS platforms if possible - it really reduces
>>>>>> relearning when moving from one OS to the other.
>>>>>>
>>>>>> Just my 2 cents,
>>>>>> Eric
>>>>>>
>>>>>> On Fri, Sep 30, 2011 at 9:21 AM, Henri 
>>>>>> Gomez<henri.gomez at gmail.com>  wrote:
>>>>>>>> Yes. the assumption is that you can always walk up one 
>>>>>>>> directory and find the JDK, but that's no longer true, because 
>>>>>>>> the 1.7.0.jre bundle has to be an atomic Mac OS X bundle that 
>>>>>>>> can be placed inside of another app bundle. Ideally, and IDE 
>>>>>>>> which contains a 1.7.0.jdk bundle will contain all it needs 
>>>>>>>> inside of itself to generate .jre based app bundles, or whole 
>>>>>>>> new copy of itself with a .jdk bundle.
>>>>>>>>
>>>>>>>> My usual trick would be to make a "jdk" symlink to ../../../ 
>>>>>>>> inside of 1.7.0.jre/Contents/Home, and have the tools just look 
>>>>>>>> for a "jdk" directory, but my experience with adding backwards 
>>>>>>>> pointing symlinks has not been popular with some folks that are 
>>>>>>>> dependent on zip-based archiving. So, is there a better 
>>>>>>>> alternative?
>>>>>>> I understand and commented JIRA.
>>>>>>>
>>>>>>> First proposal :
>>>>>>>
>>>>>>> Packaging it differently
>>>>>>>
>>>>>>> * OpenJDK 7 OSX atomic bundle (specific package, ie a plain 
>>>>>>> zip/tarball)
>>>>>>> * OpenJDK 7 OSX JDK runtime (same layout Windows or Linux)
>>>>>>>
>>>>>>> Packagers/Bundlers will more than likely prefer to use .zip/tarball
>>>>>>> file, not something mounted from DMG/PKG (I got one issue one
>>>>>>> openjdk-osx-build).
>>>>>>>
>>>>>>> So OpenJDK 7 OSX will contains a standard OpenJDK layout + a
>>>>>>> zip/tarballcontaining atomic Mac OS X bundle ready to use for
>>>>>>> packagers.
>>>>>>>
>>>>>>> Second proposal :
>>>>>>>
>>>>>>> Why not just copying 1.7.0.jre content into jre for now ?
>>>>>>>
>>>>>
>>>>
>>>
>>
>