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
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 :
>
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 eq
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 systemPa
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
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:
com.sun
tools
${java.version}
