tools.jar needs to be supported as a normal dependency

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.0-beta-1
  • Component/s: None
  • Labels:
    None
  • Environment:
    sun sdk
  • Complexity:
    Intermediate

Description

Sun SDKs have a tools.jar that provides API for extending the Sun java tools. This includes APT and Javadoc. There is no mechanism in maven for loading in tools.jar as a dependency. It can be added to the classpath before maven is launched, or manually loaded into the local repository. However, neither of these solutions are very satisfactory.

Could we have some smarts in the dependency loading that understands a magical jdk groupId that resolves to the current JDK being used for compilation? This would let JDK-dependent stuff be linked in. In the case of tools.jar, the dependency snippet would look something like this:

<dependency>
<groupId>sun.jdk</groupId>
<artifactId>tools</artifactId>
<type>jar</type>
<scope>provided</scope>
</dependency>

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

John is working on a related fix.

Show
Brett Porter added a comment - John is working on a related fix.
Hide
Permalink
John Casey added a comment -

I've added a new type of dependency to the mix: scope == system.

This new dependency has the potential to break portability, but is used to incorporate dependencies that are assumed to be on the system already at build time...for instance, tools.jar. To use this for the tools.jar, specify:

<dependency>
<groupId>sun.jdk</groupId>
<artifactId>tools</artifactId>
<version>1.4.2_08</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>

HOWEVER, this path specification will lead to failure of the build when run on OS X or any non-Sun JDK...hence the portability warning above. My suggestion is that these dependencies be used with the utmost care. Multiple profiles activated based on 'os.name' or similar might help to mitigate the breakage on non-Sun platforms. See it0063 for more information.

Show
John Casey added a comment - I've added a new type of dependency to the mix: scope == system. This new dependency has the potential to break portability, but is used to incorporate dependencies that are assumed to be on the system already at build time...for instance, tools.jar. To use this for the tools.jar, specify: <dependency> <groupId>sun.jdk</groupId> <artifactId>tools</artifactId> <version>1.4.2_08</version> <scope>system</scope> <systemPath>${java.home}/../lib/tools.jar</systemPath> </dependency> HOWEVER, this path specification will lead to failure of the build when run on OS X or any non-Sun JDK...hence the portability warning above. My suggestion is that these dependencies be used with the utmost care. Multiple profiles activated based on 'os.name' or similar might help to mitigate the breakage on non-Sun platforms. See it0063 for more information.
Hide
Permalink
Brett Porter added a comment -

fixing fix for

Show
Brett Porter added a comment - fixing fix for
Hide
Permalink
Matthew Pocock added a comment -

This is great. Adding dependencies to the profiles section would work arround the issue with osx, and possibly be generally useful, particularly if there was a library of profiles & dependencies for different platforms.

Show
Matthew Pocock added a comment - This is great. Adding dependencies to the profiles section would work arround the issue with osx, and possibly be generally useful, particularly if there was a library of profiles & dependencies for different platforms.

People

  • Assignee:
    John Casey
    Reporter:
    Matthew Pocock
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: