New jre layout broke Maven and Ant

[Phil Race]

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