[
http://jira.codehaus.org/browse/MNG-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231271#action_231271
]
Brett Porter commented on MNG-4752:
-----------------------------------
I can't find a corresponding JIRA issue, but there was significant discussion
on this last year: http://markmail.org/message/nzzwg4tt6w4n42wm
> <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
