I believe that the error comes from the fact that there is nothing in the repo (pom/sha-1 or otherwise) for the maven GAV
com.sun:tools:jar:1.7.0_65 It's weird since the dependency states a systemPath. I would expect maven to simply ignore the GAV resolution and use the file found at the systemPath, but clearly there is something more going on here. 2014-09-09 22:35 GMT+02:00 Robert Scholte <codeh...@sourcegrounds.com>: > Just quoting the ajdoc-ref[1] > > "ajdoc currently requires the tools.jar from J2SE 1.3 to be on the > classpath. Normally the scripts set this up, assuming that your JAVA_HOME > variable points to an appropriate installation of Java. You may need to > provide this jar when using a different version of Java or a JRE." > > They say "currently", which suggest they're thinking of a tools-less > solution. > Based on the rest of the text, it's indeed the plugin itself to locate the > tools.jar. We know that this is not a constant file relative to the > JAVA_HOME, there are different tastes. > > So Oracle is thinking to remove the tools.jar > The Apache Maven team is considering to drop the system scope. > For now the profile option seems to be the best solution, although I > wonder where the error is coming from. > > Robert > > [1] https://www.eclipse.org/aspectj/doc/next/devguide/ajdoc-ref.html > > Op Tue, 09 Sep 2014 06:21:49 +0200 schreef Lennart Jörelid < > lennart.jore...@gmail.com>: > > > Hello all, >> >> I wonder what the recommended way to include tools.jar (or any other JAR >> packaged with the JDK but not normally included in the classpath) would >> be. >> >> Typically, I would define a dependency on the form: >> >> <dependency> >> <groupId>com.sun</groupId> >> <artifactId>tools</artifactId> >> <version>${java.version}</version> >> <scope>system</scope> >> <systemPath>${toolsjarSystemPath}</systemPath> >> </dependency> >> >> ... and then use a set of profiles to define the actual >> toolsjarSystemPath, >> to cope with the fact that different JDKs could (or still can(?)) use >> different packaging for the tools.jar: >> >> <profile> >> <id>standardToolsJar-profile</id> >> <activation> >> <activeByDefault>true</activeByDefault> >> <file> >> <exists>${java.home}/../lib/tools.jar</exists> >> </file> >> </activation> >> <properties> >> >> <toolsjarSystemPath>${java.home}/../lib/tools.jar</toolsjarSystemPath> >> </properties> >> </profile> >> <profile> >> <id>appleJdkToolsJar-profile</id> >> <activation> >> <activeByDefault>false</activeByDefault> >> <file> >> <exists>${java.home}/../Classes/classes.jar</exists> >> </file> >> </activation> >> <properties> >> >> <toolsjarSystemPath>${java.home}/../Classes/classes.jar</ >> toolsjarSystemPath> >> </properties> >> </profile> >> >> While the approach above works, it tends to produce the following error >> message when maven is run: >> >> [ERROR] Artifact: com.sun:tools:jar:1.7.0_65 has no file. >> >> So ... is there a better approach? (Not counting JDK 9 just yet). >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- -- +==============================+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+
