You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "John Casey (JIRA)" <ji...@codehaus.org> on 2005/08/09 19:04:57 UTC
[jira] Created: (MNG-715) find a scalable way to add deprecation information to parameter expressions
find a scalable way to add deprecation information to parameter expressions
---------------------------------------------------------------------------
Key: MNG-715
URL: http://jira.codehaus.org/browse/MNG-715
Project: Maven 2
Type: Improvement
Components: maven-plugin-descriptor, maven-core
Versions: 2.0-alpha-3
Reporter: John Casey
Fix For: 2.0-beta-1
Currently, most aspects of mojo development accommodate some sort of deprecation process. Methods can be deprecated using standard Java language support, and any given mojo can declare one of its parameters as deprecated. However, we do not currently support deprecation of the parameters available to mojo developers.
A case in point is ${project.build.resources}. Ideally, we should not be modifying the underlying Model at runtime; doing so will compromise our ability to write a fully resolved POM to disk (which should not encompass runtime additions, which could be dependent on a profile's activation) and similar functionality. Instead, to add resources and then access them, a mojo should use ${project.resources} and MavenProject.addResource(..) (both new). The most graceful way to encourage this switch would be to deprecate ${project.build.resources} from the parameter evaluator, and remove it later. Currently, this requires case-by-case exceptions to be coded directly into the PluginParameterExpressionEvaluator, which is not very elegant.
One possible solution might be to simply put a list of deprecated expressions into the evaluator, and also maybe a list of banned expressions. First step in evaluation could be to check vs. these lists, and give appropriate warnings/errors when detected.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-715) find a scalable way to add deprecation information to parameter expressions
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-715?page=all ]
John Casey closed MNG-715:
--------------------------
Resolution: Fixed
> find a scalable way to add deprecation information to parameter expressions
> ---------------------------------------------------------------------------
>
> Key: MNG-715
> URL: http://jira.codehaus.org/browse/MNG-715
> Project: Maven 2
> Type: Improvement
> Components: maven-plugin-descriptor, maven-core
> Versions: 2.0-alpha-3
> Reporter: John Casey
> Assignee: John Casey
> Fix For: 2.0-beta-1
>
>
> Currently, most aspects of mojo development accommodate some sort of deprecation process. Methods can be deprecated using standard Java language support, and any given mojo can declare one of its parameters as deprecated. However, we do not currently support deprecation of the parameters available to mojo developers.
> A case in point is ${project.build.resources}. Ideally, we should not be modifying the underlying Model at runtime; doing so will compromise our ability to write a fully resolved POM to disk (which should not encompass runtime additions, which could be dependent on a profile's activation) and similar functionality. Instead, to add resources and then access them, a mojo should use ${project.resources} and MavenProject.addResource(..) (both new). The most graceful way to encourage this switch would be to deprecate ${project.build.resources} from the parameter evaluator, and remove it later. Currently, this requires case-by-case exceptions to be coded directly into the PluginParameterExpressionEvaluator, which is not very elegant.
> One possible solution might be to simply put a list of deprecated expressions into the evaluator, and also maybe a list of banned expressions. First step in evaluation could be to check vs. these lists, and give appropriate warnings/errors when detected.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org