You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Jesse Glick (JIRA)" <ji...@codehaus.org> on 2010/08/06 19:01:32 UTC
[jira] Created: (MNG-4752) endorsed
<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
[jira] Commented: (MNG-4752) endorsed
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] (MNG-4752) endorsed
Posted by "Stevo Slavic (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293135#comment-293135 ]
Stevo Slavic commented on MNG-4752:
-----------------------------------
Spotted some workarounds like [this|http://www.mindbug.org/2009/02/adding-endorsements-to-mavens-plugins.html] where combination of maven-dependency-plugin:copy and maven-compiler-plugin are used to copy endorsed artifacts in target/endorsed, and configure compiler to use that dir as endorsed libs dir.
Native support for endorsed scope is preferred - compared to native support, workaround is ugly, and it's even uglier if one is using Eclipse IDE and m2e.
> <scope>endorsed</scope>
> -----------------------
>
> Key: MNG-4752
> URL: https://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
> Fix For: Issues to be reviewed for 3.x
>
>
> 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, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4752) endorsed
Posted by "Jesse Glick (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231905#action_231905 ]
Jesse Glick commented on MNG-4752:
----------------------------------
Should perhaps be added to "Design, Patterns & Best Practices" component?
> <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
[jira] (MNG-4752) endorsed
Posted by "Jesse Glick (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293222#comment-293222 ]
Jesse Glick commented on MNG-4752:
----------------------------------
Some of the Mojo archetypes for Java EE use a similar idiom, copying dependencies to {{target/endorsed}} (though not using a special profile to do so); see https://svn.codehaus.org/mojo/trunk/mojo/mojo-archetypes/webapp-javaee6/src/main/resources/archetype-resources/pom.xml for example.
The NetBeans IDE will check for a directory of this name, and if encountered, prepend any JARs found there to the Java editor's notion of the "boot" classpath. That enables the editor to understand APIs added or overridden by endorsed JARs, such as {{javax.annotation.Resource.lookup}} available in EE 6 but not SE 6; otherwise compilation of projects using such APIs would succeed but the editor would display them as erroneous.
Obviously a standardized means of marking endorsed libraries would be much better since it would both simplify POMs, and make IDE integration more predictable (e.g. not requiring the project to have been built to at least the {{validate}} phase).
> <scope>endorsed</scope>
> -----------------------
>
> Key: MNG-4752
> URL: https://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
> Fix For: Issues to be reviewed for 3.x
>
>
> 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, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4752) endorsed
Posted by "Jesse Glick (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=232183#action_232183 ]
Jesse Glick commented on MNG-4752:
----------------------------------
Workaround: MARCHETYPES-35
> <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