[
https://issues.apache.org/jira/browse/MNG-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032063#comment-15032063
]
Robert Scholte commented on MNG-5732:
-------------------------------------
The problem lies in your own
[pom.xml|https://svn.java.net/svn/glassfish~svn/trunk/main/appserver/tests/quicklook/pom.xml].
Line 248 describes:
{code:xml|title=pom.xml#L248}
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools-jar</artifactId>
<version>1</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
{code}
These are solutions I can think of:
- try to replace these ant-scripts.
- Assuming you don't need this dependency anymore with Java9, you could use a
profile with java activation, e.g.
{code:xml}
<profiles>
<profile>
<activation>
<jdk>(,1.9)</jdk>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools-jar</artifactId>
<version>1</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
</profiles>
{code}
> Java 9 completely changes JDK directory layout and drops tools.jar
> ------------------------------------------------------------------
>
> Key: MNG-5732
> URL: https://issues.apache.org/jira/browse/MNG-5732
> Project: Maven
> Issue Type: Improvement
> Components: General
> Environment: JDK 9
> Reporter: Markus Karg
>
> Oracle published plans to drop the existence of tools.jar and totally
> restructure the directory layout of the JDK beginning with JDK 9, including
> changes in the extensions mechanism and location of rt.jar. As a side effect,
> all plugins relying on a particular layout structure and / or the existence
> of tools.jar won't work on JDK 9.
> The intention is to move from a histrically grown infrastructure to a layout
> which is clearly documented by JEP 220, hence it can be considered consistent
> on all future JDKs, which is a positive thing, but imposes problems for many
> tool vendors.
> As this is a cross-plugin concern, all plugins have to be checked and
> possibly fixed.
> For more information see http://openjdk.java.net/jeps/220.
> A pre-release of JDK 9 can be downloaded from https://jdk9.java.net/download/.
> Oracle is interested to get in touch with projects being currently dependend
> of the existing pre-9 JDK structure. Such projects shall report on the
> jigsaw-dev mailing list.
> Some effects in short:
> ââ¬Â¢ JRE and JDK images now have identical structures. Previously a
> JDK image embedded the JRE in a jre subdirectory; now a JDK image is simply a
> run-time image that happens to contain the full set of development tools and
> other items historically found in the JDK.
> ââ¬Â¢ User-editable configuration files previously located in the lib
> directory are now in the new 'conf' directory. The files that remain in the
> lib directory are private implementation details of the run-time system, and
> should never be opened or modified.
> ââ¬Â¢ The endorsed-standards override mechanism has been removed.
> Applications that rely upon this mechanism, either by setting the system
> property java.endorsed.dirs or by placing jar files into the lib/endorsed
> directory of a JRE, will not work. We expect to provide similar functionality
> later in JDK 9 in the form of upgradeable modules.
> ââ¬Â¢ The extension mechanism has been removed. Applications that
> rely upon this mechanism, either by setting the system property java.ext.dirs
> or by placing jar files into the lib/ext directory of a JRE, will not work.
> In most cases, jar files that were previously installed as extensions can
> simply be placed at the front of the class path.
> ââ¬Â¢ The internal files rt.jar, tools.jar, and dt.jar have been
> removed. The content of these files is now stored in a more efficient format
> in implementation-private files in the lib directory. Class and resource
> files previously in tools.jar and dt.jar are now always visible via the
> bootstrap or application class loaders in a JDK image.
> ââ¬Â¢ A new, built-in NIO file-system provider can be used to access
> the class and resource files stored in a run-time image. Tools that
> previously read rt.jar and other internal jar files directly should be
> updated to use this file system.
> (Source: December Oracle Java CAP Program Newsletter)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)