What I mean is: let us get rid of system-scoped dependency completely, because it is unreliable and potentially disruptive. Let us introduce some logic in the code of the plugin itself to try an locate the tools.jar (or equivalent) using the configured java environment and then fork a new java process for ajdoc, passing the generated classpath on the command line.
See exec-maven-plugin:java mojo for an example of forking a new java process with a proper support for toolchains. Or, I guess, the standard javadoc-maven-plugin does a similar thing. -- Sergei Ivanov Wed, 10 Sep 2014 00:27:54 +0200 от Lennart Jörelid <lennart.jore...@gmail.com>: >I guess we could change the way we invoke the ajdoc if we feel there is a >better way to do it. > >However, for creating a classpath containing the tools.jar there is a simple >mechanism for this in maven - by using the systemPath property on a dependency. > >2014-09-10 0:23 GMT+02:00 Sergei Ivanov < sergei_iva...@mail.ru > : >>Somehow I feel that we've got the wrong end of the stick here. I don't think >>invoking ajdoc in-process is the right thing to do, and it also defeats maven >>toolchains mechanism. I reckon the plugin should instead encapsulate some >>logic to build the classpath and detect where the tools.jar (or equivalent) >>is, taking java toolchain into account if present. Then it could simply fork >>an ajdoc process with the newly built classpath using the right java >>executable (again taken from a java toolchain if present). >>-- >>Sergei Ivanov >> >>Tue, 9 Sep 2014 23:42:05 +0200 от Lennart Jörelid < lennart.jore...@gmail.com >>>: >> >>>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 +==============================+ > > > >-- >-- +==============================+ | 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 +==============================+
