<scope>endorsed</scope>
-----------------------
Key: MNG-4752
URL: http://jira.codehaus.org/browse/MNG-4752
Project: Maven 2 & 3
Issue Type: New Feature
Components: Dependencies
Affects Versions: 2.2.1
Environment: An issue in 2.2.1 but I think the same issue applies also
to 3.0.
Reporter: Jesse Glick
There appears to be no official way to request usage of a particular Java
library (such as a new release of JAXB) using the Java "endorsed" mechanism.
The semantics would be very similar to provided scope except that the library
is expected to override the JRE's boot classpath, both at compile time (main or
test) and runtime ({{exec:exec}} and Surefire).
As investigated in https://netbeans.org/bugzilla/show_bug.cgi?id=185139#c8
there are various ways you can get this functionality to work in current Maven
releases if you Google long enough, but all seem hackish. Prepending arguments
to the bootclasspath directly is generally discouraged.
Manually configuring {{-endorseddirs}} (for {{javac}}) or
{{-Djava.endorsed.dirs}} (for {{java}} incl. Surefire) seems to work, but you
have to first download the endorsed libraries into some subdirectory of target,
where they could consume considerable disk space.
You could fix the disk space issue by passing dirs in the local repository, but
this requires hardcoding details of the {{~/.m2/repository/}} structure in the
POM which is very ugly, and also means duplicating information about
{{groupId}}, {{artifactId}}, and {{version}} (you still need to have artifacts
declared elsewhere so they will get downloaded if not initially present).
Anyway all these tricks obscure the relatively simple intent of the developer,
which is to use a given artifact in the project in preference to any equivalent
in the current JRE. It is important to have a standardized way of declaring
such dependencies, not just to make it easy to write and maintain {{pom.xml}},
but so that IDEs and other tools know what you intend to do and can (for
example) offer appropriate code completion without reverse engineering various
idioms.
Much preferable would be to simply declare these dependencies in the normal POM
section, but with {{<scope>endorsed</scope>}}. Then {{maven-compiler-plugin}},
{{maven-exec-plugin}}, {{maven-surefire-plugin}}, etc. would need to be
modified to understand these dependencies and use them appropriately when
calling JDK tools. Plugin code could be smart enough to work optimally in the
available environment; for example, if an artifact has only a single JAR in the
local repository (no extra classifiers), the containing directory could be
passed directly to JDK tools as an endorsed dir, but in other cases a
{{target/endorsed}} dir could be generated and used instead.
One concern is that the notion of an endorsed library is quite specific to the
JVM; Maven projects targeted at other platforms would presumably have no use
for this scope. Perhaps this is not an issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
