[jira] Commented: (MJAVADOC-206) use ${project.reporting.outputEncoding} as default value for "docencoding" and "charset" parameter and default to UTF-8
[
http://jira.codehaus.org/browse/MJAVADOC-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143934#action_143934
]
Benjamin Bentmann commented on MJAVADOC-206:
Revised the default value of {{charset}} in
[r681940|http://svn.apache.org/viewvc?view=rev&revision=681940]: To ensure the
HTML charset is in sync with the actual file encoding given by {{docencoding}},
the effective value for {{docencoding}} is now used as the default value for
{{charset}}.
> use ${project.reporting.outputEncoding} as default value for "docencoding"
> and "charset" parameter and default to UTF-8
> ---
>
> Key: MJAVADOC-206
> URL: http://jira.codehaus.org/browse/MJAVADOC-206
> Project: Maven 2.x Javadoc Plugin
> Issue Type: New Feature
>Affects Versions: 2.4
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.5
>
>
> see [Reporting Encoding
> Configuration|http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration]
> proposal
--
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: (MJAVADOC-206) use ${project.reporting.outputEncoding} as default value for "docencoding" and "charset" parameter and default to UTF-8
[
http://jira.codehaus.org/browse/MJAVADOC-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143941#action_143941
]
Vincent Siveton commented on MJAVADOC-206:
--
revised in [r681961|http://svn.apache.org/viewvc?rev=681961&view=rev] according
http://maven.markmail.org/message/zwswglatlchvx2fq?q=
> use ${project.reporting.outputEncoding} as default value for "docencoding"
> and "charset" parameter and default to UTF-8
> ---
>
> Key: MJAVADOC-206
> URL: http://jira.codehaus.org/browse/MJAVADOC-206
> Project: Maven 2.x Javadoc Plugin
> Issue Type: New Feature
>Affects Versions: 2.4
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.5
>
>
> see [Reporting Encoding
> Configuration|http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration]
> proposal
--
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] Closed: (MPH-41) help:effective-pom should optionally output an XML document wihout the non-XML header and footer
[ http://jira.codehaus.org/browse/MPH-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPH-41. -- Resolution: Duplicate > help:effective-pom should optionally output an XML document wihout the > non-XML header and footer > > > Key: MPH-41 > URL: http://jira.codehaus.org/browse/MPH-41 > Project: Maven 2.x Help Plugin > Issue Type: Improvement >Reporter: Ben Tomasini > > I am looking to read in the pom with an ant script using xmlproperty after > running mvn -Doutput=mypom.xml help:effective-pom. This would be easier if > the output file was simply XML without the comment header and footer. -- 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: (MPH-40) help:effective-pom emits invalid XML to output file
[
http://jira.codehaus.org/browse/MPH-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143943#action_143943
]
Vincent Siveton commented on MPH-40:
We could make xml comments only if reactorProjects is empty.
If reactorProjects is not empty, the output file appends all effective poms in
one file and thus it is an invalid xml file.
> help:effective-pom emits invalid XML to output file
> ---
>
> Key: MPH-40
> URL: http://jira.codehaus.org/browse/MPH-40
> Project: Maven 2.x Help Plugin
> Issue Type: Improvement
>Reporter: Jürgen Hermann
>
> Currently, this fragile post-processing is needed to make the content in a
> file generated with -Doutput=... parseable:
> tofile="${deploy.effective.pom.xml.file}">
>
> replace='
\1' />
>
>
>
> Solution: Either add XML comments in the generation markup, or only output
> the XML proper to the output file, leaving the text out of it.
--
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] Updated: (MRESOURCES-20) Filtering ${foo.file} evaluates to in full path to pom.xml
[
http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll updated MRESOURCES-20:
--
Priority: Critical (was: Minor)
> Filtering ${foo.file} evaluates to in full path to pom.xml
> --
>
> Key: MRESOURCES-20
> URL: http://jira.codehaus.org/browse/MRESOURCES-20
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP, Maven 2.0.2
>Reporter: Martin Onis
>Priority: Critical
> Attachments: MRESOURCES-20.patch
>
>
> If an unresolved variable is encountered, the plugin simply does not replace
> the variable in the target file.
> If this unresolved variable however ends in ".file}" it will evaluate to a
> file object that targets the current pom. This results in the replacement
> being the complete path to that pom (in the 2.1 version of the plugin this
> results in a ClassCastException).
> The workaround is, of course, not to filter the affected files.
> Though this will not work if other variables in the affected files do need to
> be replaced.
--
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] Updated: (MWAR-133) Filtering issue: wrong replacement of properties by values from MavenProject object
[
http://jira.codehaus.org/browse/MWAR-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll updated MWAR-133:
-
Fix Version/s: 2.1-alpha-2
> Filtering issue: wrong replacement of properties by values from MavenProject
> object
>
>
> Key: MWAR-133
> URL: http://jira.codehaus.org/browse/MWAR-133
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Thomas Winterschlade
>Assignee: Stephane Nicoll
> Fix For: 2.1-alpha-2
>
> Attachments: MWAR-133-maven-war-plugin.patch
>
>
> When the filter option is enabled in the war plugin, the plugin searches in
> the affected files for the pattern @...@ and ${...}. If such a pattern is
> found, the plugin tries to replace the found value. Therefore the
> ReflectionValueExtractor is used which removes the first part before the dot
> of the given value; e.g. "node.version" becomes "version". Then the
> ReflectionValueExtractor tries to find a get- or is-method in the given
> object (a MavenProject object).
> That means: if the 2nd part of the ${}-property can be found as getter in the
> MavenProject class, the plugin always uses the maven plugin values.
> The value extractor should only remove the 1st part from the property if the
> property begins with "project.".
> There is a similar bug report for the resource plugin (date june 2006!!!)
> which is not yet assigned (title: Filtering ${foo.file} evaluates to in full
> path to pom.xml).
--
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] Work started: (MWAR-133) Filtering issue: wrong replacement of properties by values from MavenProject object
[
http://jira.codehaus.org/browse/MWAR-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MWAR-133 started by Stephane Nicoll.
> Filtering issue: wrong replacement of properties by values from MavenProject
> object
>
>
> Key: MWAR-133
> URL: http://jira.codehaus.org/browse/MWAR-133
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Thomas Winterschlade
>Assignee: Stephane Nicoll
> Fix For: 2.1-alpha-2
>
> Attachments: MWAR-133-maven-war-plugin.patch
>
>
> When the filter option is enabled in the war plugin, the plugin searches in
> the affected files for the pattern @...@ and ${...}. If such a pattern is
> found, the plugin tries to replace the found value. Therefore the
> ReflectionValueExtractor is used which removes the first part before the dot
> of the given value; e.g. "node.version" becomes "version". Then the
> ReflectionValueExtractor tries to find a get- or is-method in the given
> object (a MavenProject object).
> That means: if the 2nd part of the ${}-property can be found as getter in the
> MavenProject class, the plugin always uses the maven plugin values.
> The value extractor should only remove the 1st part from the property if the
> property begins with "project.".
> There is a similar bug report for the resource plugin (date june 2006!!!)
> which is not yet assigned (title: Filtering ${foo.file} evaluates to in full
> path to pom.xml).
--
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] Closed: (MWAR-133) Filtering issue: wrong replacement of properties by values from MavenProject object
[
http://jira.codehaus.org/browse/MWAR-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll closed MWAR-133.
Resolution: Fixed
Maven filtering component is handling this scenario properly. Added an it to
validate it.
Note that it will work with webResources only. Standard maven resources are
still handled by the resources plugin, refer to the linked issue for more
information.
> Filtering issue: wrong replacement of properties by values from MavenProject
> object
>
>
> Key: MWAR-133
> URL: http://jira.codehaus.org/browse/MWAR-133
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Thomas Winterschlade
>Assignee: Stephane Nicoll
> Fix For: 2.1-alpha-2
>
> Attachments: MWAR-133-maven-war-plugin.patch
>
>
> When the filter option is enabled in the war plugin, the plugin searches in
> the affected files for the pattern @...@ and ${...}. If such a pattern is
> found, the plugin tries to replace the found value. Therefore the
> ReflectionValueExtractor is used which removes the first part before the dot
> of the given value; e.g. "node.version" becomes "version". Then the
> ReflectionValueExtractor tries to find a get- or is-method in the given
> object (a MavenProject object).
> That means: if the 2nd part of the ${}-property can be found as getter in the
> MavenProject class, the plugin always uses the maven plugin values.
> The value extractor should only remove the 1st part from the property if the
> property begins with "project.".
> There is a similar bug report for the resource plugin (date june 2006!!!)
> which is not yet assigned (title: Filtering ${foo.file} evaluates to in full
> path to pom.xml).
--
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] Created: (MPH-42) Active profiles recursively growing
Active profiles recursively growing --- Key: MPH-42 URL: http://jira.codehaus.org/browse/MPH-42 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.0.2, 2.1 Reporter: Sander Verhagen Priority: Critical Attachments: Active-profiles-recursively-growing.diff.txt Running the active-profiles goal in a project where parents introduce profiles, any sub-modules of these parents will report a number of duplicates of these profiles that grows each time the goal is invoked. This is caused by the plugin (recursively) retrieving profiles from subsequent parents, and adding them to the project on which the goal is invoked. The plugin means to add the profiles that it finds so that it can give an aggregated listing of profiles over the full inheritance tree of the project on which the goal is invoked (which is okay), it is mistaken in actually adding them to the project on which the goal is invoked. It changes the project on which the goal is invoked, rather than merely observing it. Because the plugin keeps on adding the same profiles from parent projects, every time it is invoked, to the same project on which the goal is invoked, the aggregated listing keeps on growing and growing during execution. Rated this Critical since on large projects this renders the plugin useless; the output will become booming; well, you know how that goes with recursion. Fix is attached as unified diff. -- 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
