[ 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)