New jre layout broke Maven and Ant

[Phil Race]

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 ?
>>>>>>
>>>>
>>>
>>
>