[jira] Moved: (MENFORCER-51) build failure in case of available updates
[ http://jira.codehaus.org/browse/MENFORCER-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly moved MVERSIONS-4 to MENFORCER-51: --- Key: MENFORCER-51 (was: MVERSIONS-4) Project: Maven 2.x Enforcer Plugin (was: Maven 2.x Versions Plugin) build failure in case of available updates -- Key: MENFORCER-51 URL: http://jira.codehaus.org/browse/MENFORCER-51 Project: Maven 2.x Enforcer Plugin Issue Type: Wish Reporter: Tomasz Pik It would be useful to have a possibility to fail build if there's an update of given dependency. In some way it would 'solve' problem of 'how to depend of latest stable version of my company parent pom' problem - build would just not pass if there's an update. -- 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: (MRESOURCES-39) Filtering fails for command line properties
[ http://jira.codehaus.org/browse/MRESOURCES-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=147190#action_147190 ] Olivier Lamy commented on MRESOURCES-39: As the plugin now use the maven filtering component, this should be fixed. Have a look at the order defined here http://maven.apache.org/shared/maven-filtering. Can you try it a snapshot has deployed. I leave this issue open until a it has been written for this. Filtering fails for command line properties --- Key: MRESOURCES-39 URL: http://jira.codehaus.org/browse/MRESOURCES-39 Project: Maven 2.x Resources Plugin Issue Type: Bug Affects Versions: 2.2 Environment: maven-2.0.4 and maven-2.0.5 Mac OS X Reporter: Matt Brozowski Priority: Critical Fix For: 2.3 Attachments: filtering-bug.tar, maven-resources-plugin-prop-filtering-r630241.patch When passing a property on the command line to maven using -D it does not properly override values passed to filters. I have attached a sample project that defines a property in the pom.xml called 'filtered' This property is used as a filter in the filtered.properties file in src/main/filtered/filtered.properties. I have also included a test that gets passed the filtered property as a System property via the surefire plugin. It then loaded the filtered.properties file and tests to ensure the filters match. The tests pass when run as mvn test BUT if I run as mvn -Dfiltered=from-cmd-line teset They fail. I have also included the antrun plugin print its perspective on the value of the property. -- 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: (MRESOURCES-72) More debug output in maven filtering
More debug output in maven filtering Key: MRESOURCES-72 URL: http://jira.codehaus.org/browse/MRESOURCES-72 Project: Maven 2.x Resources Plugin Issue Type: Wish Affects Versions: 2.2 Reporter: Olivier Lamy Fix For: 2.3 It would be helpful if the resources mojos were more verbose with the -X flag. In version 2.2, they don't provide any extra information. Useful info might include the Resource which is being processed, the source and target of each file copy, etc. -- 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-41) More debug output
[ http://jira.codehaus.org/browse/MRESOURCES-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MRESOURCES-41: --- As now the plugin use the maven filtering component this issue need to be resolved in this component More debug output - Key: MRESOURCES-41 URL: http://jira.codehaus.org/browse/MRESOURCES-41 Project: Maven 2.x Resources Plugin Issue Type: Wish Affects Versions: 2.2 Reporter: Rhett Sutphin Fix For: 2.3 It would be helpful if the resources mojos were more verbose with the -X flag. In version 2.2, they don't provide any extra information. Useful info might include the Resource which is being processed, the source and target of each file copy, etc. -- 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] Moved: (MSHARED-59) More debug output in maven filtering
[ http://jira.codehaus.org/browse/MSHARED-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy moved MRESOURCES-72 to MSHARED-59: --- Affects Version/s: (was: 2.2) maven-filtering-1.0-beta-1 Fix Version/s: (was: 2.3) maven-filtering-1.0-beta-2 Key: MSHARED-59 (was: MRESOURCES-72) Project: Maven Shared Components (was: Maven 2.x Resources Plugin) More debug output in maven filtering Key: MSHARED-59 URL: http://jira.codehaus.org/browse/MSHARED-59 Project: Maven Shared Components Issue Type: Wish Affects Versions: maven-filtering-1.0-beta-1 Reporter: Olivier Lamy Fix For: maven-filtering-1.0-beta-2 It would be helpful if the resources mojos were more verbose with the -X flag. In version 2.2, they don't provide any extra information. Useful info might include the Resource which is being processed, the source and target of each file copy, etc. -- 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: (MSITE-352) L10n Status Report
[ http://jira.codehaus.org/browse/MSITE-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=147193#action_147193 ] Dennis Lundberg commented on MSITE-352: --- The Project Info Reports Plugin is included in the Supported Languages table. L10n Status Report -- Key: MSITE-352 URL: http://jira.codehaus.org/browse/MSITE-352 Project: Maven 2.x Site Plugin Issue Type: Improvement Reporter: Samuel Santos A new report should be included below the Supported Languages table, at http://maven.apache.org/plugins/maven-site-plugin/i18n.html, for the Project Info Reports Plugin properties file so we can check his current level of localization. -- 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: (MSHARED-59) More debug output in maven filtering
[ http://jira.codehaus.org/browse/MSHARED-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSHARED-59: --- Component/s: maven-filtering Set component More debug output in maven filtering Key: MSHARED-59 URL: http://jira.codehaus.org/browse/MSHARED-59 Project: Maven Shared Components Issue Type: Wish Components: maven-filtering Affects Versions: maven-filtering-1.0-beta-1 Reporter: Olivier Lamy Fix For: maven-filtering-1.0-beta-2 It would be helpful if the resources mojos were more verbose with the -X flag. In version 2.2, they don't provide any extra information. Useful info might include the Resource which is being processed, the source and target of each file copy, etc. -- 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: (MINVOKER-62) Change the default value for the projectsDirectory parameter
Change the default value for the projectsDirectory parameter
Key: MINVOKER-62
URL: http://jira.codehaus.org/browse/MINVOKER-62
Project: Maven 2.x Invoker Plugin
Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Dennis Lundberg
The current default value is ${basedir}/src/projects but all uses I have seen
put the IT projects in ${basedir}/src/it so it might be a good idea to change
the default value to that.
--
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: (MENFORCER-51) build failure in case of available updates
[ http://jira.codehaus.org/browse/MENFORCER-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=147195#action_147195 ] Stephen Connolly commented on MENFORCER-51: --- I moved this to enforcer from versions-maven-plugin because fundamentally I believe this wisk to beout of scope for the versions maven plugin. The enforcer plugin is responsible for failing the build if things need to be enforced. I may be able to write a patch to implement this in the standard rules in the next couple of days if nobody else writes one first! build failure in case of available updates -- Key: MENFORCER-51 URL: http://jira.codehaus.org/browse/MENFORCER-51 Project: Maven 2.x Enforcer Plugin Issue Type: Wish Reporter: Tomasz Pik It would be useful to have a possibility to fail build if there's an update of given dependency. In some way it would 'solve' problem of 'how to depend of latest stable version of my company parent pom' problem - build would just not pass if there's an update. -- 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: (MINVOKER-62) Change the default value for the projectsDirectory parameter
[
http://jira.codehaus.org/browse/MINVOKER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MINVOKER-62:
-
Fix Version/s: 1.3
Change the default value for the projectsDirectory parameter
Key: MINVOKER-62
URL: http://jira.codehaus.org/browse/MINVOKER-62
Project: Maven 2.x Invoker Plugin
Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Dennis Lundberg
Fix For: 1.3
The current default value is ${basedir}/src/projects but all uses I have seen
put the IT projects in ${basedir}/src/it so it might be a good idea to change
the default value to that.
--
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: (MSITE-352) Link to L10n Status Report for Project Info Reports Plugin
[ http://jira.codehaus.org/browse/MSITE-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-352: -- Assignee: Dennis Lundberg Affects Version/s: 2.0-beta-7 Fix Version/s: 2.0-beta-8 Summary: Link to L10n Status Report for Project Info Reports Plugin (was: L10n Status Report) Link to L10n Status Report for Project Info Reports Plugin -- Key: MSITE-352 URL: http://jira.codehaus.org/browse/MSITE-352 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.0-beta-7 Reporter: Samuel Santos Assignee: Dennis Lundberg Fix For: 2.0-beta-8 A new report should be included below the Supported Languages table, at http://maven.apache.org/plugins/maven-site-plugin/i18n.html, for the Project Info Reports Plugin properties file so we can check his current level of localization. -- 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: (MSITE-352) Link to L10n Status Report for Project Info Reports Plugin
[ http://jira.codehaus.org/browse/MSITE-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-352. - Resolution: Fixed Sorry, I misunderstood it when I first read the issue. Fixed in [r692637|http://svn.apache.org/viewvc?view=revrevision=692637]. Link to L10n Status Report for Project Info Reports Plugin -- Key: MSITE-352 URL: http://jira.codehaus.org/browse/MSITE-352 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.0-beta-7 Reporter: Samuel Santos Assignee: Dennis Lundberg Fix For: 2.0-beta-8 A new report should be included below the Supported Languages table, at http://maven.apache.org/plugins/maven-site-plugin/i18n.html, for the Project Info Reports Plugin properties file so we can check his current level of localization. -- 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: (MINVOKER-62) Change the default value for the projectsDirectory parameter
[
http://jira.codehaus.org/browse/MINVOKER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=147202#action_147202
]
Benjamin Bentmann commented on MINVOKER-62:
---
While we are at breaking with backward-compat, we could also consider to change
the default values for the hook scripts to {{prebuild}} and {{postbuild}}
respectively, i.e. remove the file extensions from the values. In combination
with MINVOKER-7, this allows to easily use/mix BeanShell and Groovy scripts.
Change the default value for the projectsDirectory parameter
Key: MINVOKER-62
URL: http://jira.codehaus.org/browse/MINVOKER-62
Project: Maven 2.x Invoker Plugin
Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Dennis Lundberg
Fix For: 1.3
The current default value is ${basedir}/src/projects but all uses I have seen
put the IT projects in ${basedir}/src/it so it might be a good idea to change
the default value to that.
--
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: (MSITE-351) New language - Portuguese (Portugal)
[ http://jira.codehaus.org/browse/MSITE-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=147204#action_147204 ] Dennis Lundberg commented on MSITE-351: --- Thanks for the patches! Fixed in [r692629|http://svn.apache.org/viewvc?view=revrevision=692629], [r692641|http://svn.apache.org/viewvc?view=revrevision=692641] and [r692643|http://svn.apache.org/viewvc?view=revrevision=692643]. New SNAPSHOTs have been deployed. New language - Portuguese (Portugal) Key: MSITE-351 URL: http://jira.codehaus.org/browse/MSITE-351 Project: Maven 2.x Site Plugin Issue Type: Improvement Components: internationalization Reporter: Samuel Santos Assignee: Dennis Lundberg Fix For: 2.0-beta-8 Attachments: project-info-report_pt.properties, site-plugin_pt.properties, site-tool_pt.properties A new translation to Portuguese (Portugal). -- 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: (MSITE-351) New language - Portuguese (Portugal)
[ http://jira.codehaus.org/browse/MSITE-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-351. - Resolution: Fixed Fix Version/s: 2.0-beta-8 New language - Portuguese (Portugal) Key: MSITE-351 URL: http://jira.codehaus.org/browse/MSITE-351 Project: Maven 2.x Site Plugin Issue Type: Improvement Components: internationalization Reporter: Samuel Santos Assignee: Dennis Lundberg Fix For: 2.0-beta-8 Attachments: project-info-report_pt.properties, site-plugin_pt.properties, site-tool_pt.properties A new translation to Portuguese (Portugal). -- 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: (MSITE-287) Clarify/fix documentation about encoding for translated resource bundles.
[ http://jira.codehaus.org/browse/MSITE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-287. - Resolution: Fixed Fixed in [r692645|http://svn.apache.org/viewvc?view=revrevision=692645]. Please review it so that we agree. Clarify/fix documentation about encoding for translated resource bundles. - Key: MSITE-287 URL: http://jira.codehaus.org/browse/MSITE-287 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.0-beta-6 Reporter: Benjamin Bentmann Assignee: Dennis Lundberg Priority: Minor Fix For: 2.0-beta-8 According to http://maven.apache.org/plugins/maven-site-plugin/i18n.html translators are expected to provide their properties files in UTF-8 encoding. However, the JRE reads properties files using ISO-8859-1 encoding (see [class javadoc for PropertyResourceBundle|http://java.sun.com/javase/6/docs/api/java/util/PropertyResourceBundle.html]). Either the documentation should be fixed to state ISO-8859-1 or it should be made clear why Maven requires another encoding than usual. -- 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: (MINVOKER-62) Change the default value for the projectsDirectory parameter
[
http://jira.codehaus.org/browse/MINVOKER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=147206#action_147206
]
Dennis Lundberg commented on MINVOKER-62:
-
I wonder why we use files called {{verify.bsh}} as postBuildHookScript in our
ITs instead of the default value {{postbuild.bsh}}?
The reason for this issue is that I find the configuration for ITs rather
verbose, and I went looking for ways to make it less verbose by using default
values where possible.
Change the default value for the projectsDirectory parameter
Key: MINVOKER-62
URL: http://jira.codehaus.org/browse/MINVOKER-62
Project: Maven 2.x Invoker Plugin
Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Dennis Lundberg
Fix For: 1.3
The current default value is ${basedir}/src/projects but all uses I have seen
put the IT projects in ${basedir}/src/it so it might be a good idea to change
the default value to that.
--
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: (MINVOKER-62) Change the default value for the projectsDirectory parameter
[
http://jira.codehaus.org/browse/MINVOKER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=147207#action_147207
]
Benjamin Bentmann commented on MINVOKER-62:
---
Might just be that {{verify.bsh}} is giving a better sense of the file's
purpose. Also keep in mind that AFAIK the Invoker was intended to run Maven
builds in general, using that for integration testing is only one example use
case.
Change the default value for the projectsDirectory parameter
Key: MINVOKER-62
URL: http://jira.codehaus.org/browse/MINVOKER-62
Project: Maven 2.x Invoker Plugin
Issue Type: Improvement
Affects Versions: 1.2.1
Reporter: Dennis Lundberg
Fix For: 1.3
The current default value is ${basedir}/src/projects but all uses I have seen
put the IT projects in ${basedir}/src/it so it might be a good idea to change
the default value to that.
--
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: (MSITE-353) Remove the workaround for MSITE-289 when we upgrade to Doxia Sitetools 1.0-beta-1
Remove the workaround for MSITE-289 when we upgrade to Doxia Sitetools 1.0-beta-1 - Key: MSITE-353 URL: http://jira.codehaus.org/browse/MSITE-353 Project: Maven 2.x Site Plugin Issue Type: Task Components: doxia integration Affects Versions: 2.0-beta-7 Reporter: Dennis Lundberg -- 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: (MSITE-289) site:run in maven's site/trunk doesn't show certain apt files
[ http://jira.codehaus.org/browse/MSITE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-289. - Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: (was: 2.0-beta-8) 2.0-beta-7 This was fixed in 2.0-beta-7 with the help of a workaround. The workaround should be removed when we upgrade to Doxia Sitetools 1.0-beta-1, see MSITE-353. site:run in maven's site/trunk doesn't show certain apt files - Key: MSITE-289 URL: http://jira.codehaus.org/browse/MSITE-289 Project: Maven 2.x Site Plugin Issue Type: Bug Components: site:run Affects Versions: 2.0-beta-6 Reporter: Dan Fabulich Assignee: Vincent Siveton Fix For: 2.0-beta-7 Pull down https://svn.apache.org/repos/asf/maven/site/trunk at revision 612559 and do mvn site:run. Now examine http://localhost:8080/guides/introduction/introduction-to-dependency-mechanism.html You'll get a 404 error. But the apt file is clearly there, and it works fine if you mvn site and then navigate to target/site/guides/introduction/introduction-to-dependency-mechanism.html. -- 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] Issue Comment Edited: (MSITE-300) Using maven-shade-plugin instead of forking plexus-utils
[ http://jira.codehaus.org/browse/MSITE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=123985#action_123985 ] dennislundberg edited comment on MSITE-300 at 9/6/08 8:58 AM: --- We have to decide which way to go here. Only one of MSITE-242 or MSITE-300 should be done. was (Author: dennislundberg): We have to decide which way to go here. Only one of MSITE-242 ot MSITE-300 should be done. Using maven-shade-plugin instead of forking plexus-utils Key: MSITE-300 URL: http://jira.codehaus.org/browse/MSITE-300 Project: Maven 2.x Site Plugin Issue Type: Sub-task Affects Versions: 2.0-beta-6 Reporter: Vincent Siveton Fix For: 2.0-beta-8 -- 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: (MSITE-242) remove copy of plexus-utils sources from site plugin sources since it is a dependency
[ http://jira.codehaus.org/browse/MSITE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-242. - Resolution: Fixed Fixed in [r692655|http://svn.apache.org/viewvc?view=revrevision=692655]. remove copy of plexus-utils sources from site plugin sources since it is a dependency - Key: MSITE-242 URL: http://jira.codehaus.org/browse/MSITE-242 Project: Maven 2.x Site Plugin Issue Type: Task Affects Versions: 2.0-beta-6 Reporter: Herve Boutemy Assignee: Dennis Lundberg Fix For: 2.0-beta-8 the dependency has been uncommented, but the source code copy hasn't been removed classes copied are: - o.c.p.u.cli - o.c.p.u.interpolation - o.c.p.u.introspection - o.c.p.u.xml (partial: XML encoding support) -- 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: (MSITE-300) Using maven-shade-plugin instead of forking plexus-utils
[ http://jira.codehaus.org/browse/MSITE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-300. - Resolution: Won't Fix Fix Version/s: (was: 2.0-beta-8) I fixed MSITE-242 instead. Using maven-shade-plugin instead of forking plexus-utils Key: MSITE-300 URL: http://jira.codehaus.org/browse/MSITE-300 Project: Maven 2.x Site Plugin Issue Type: Sub-task Affects Versions: 2.0-beta-6 Reporter: Vincent Siveton -- 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: (MSITE-163) The modules menu is not inherited if the parent project has no modules of its own
[ http://jira.codehaus.org/browse/MSITE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-163: -- Summary: The modules menu is not inherited if the parent project has no modules of its own (was: The modules menu is not inherited) The modules menu is not inherited if the parent project has no modules of its own - Key: MSITE-163 URL: http://jira.codehaus.org/browse/MSITE-163 Project: Maven 2.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 2.0-beta-4 Environment: ubuntu linux / debian linux Reporter: Andrew Williams Fix For: 2.0-beta-8 if I have a site.xml in a parent project that contains the line menu ref=modules inherit=top / it is not inherited by child projects. menu ref=reports inherit=top / works, as does parent. This happens when the parent project has no modules of its own. -- 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: (MAVENUPLOAD-2199) Please upload DynamicJasper 2.1.0
Please upload DynamicJasper 2.1.0 - Key: MAVENUPLOAD-2199 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2199 Project: Maven Upload Requests Issue Type: Task Reporter: Juan Manuel Alvarez I am DynamicJasper's project leader, please upload. DynamicJasper (DJ) is an API that hides the complexity of Jasper Reports, it helps developers to save time when designing simple/medium complexity reports generating the layout of the report elements automatically. It creates reports dynamically, defining at runtime the columns, column width (auto width), groups, variables, fonts, charts, crosstabs, sub reports (that can also be dynamic), page size and everything else that you can define at design time. -- 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: (MCLEAN-20) pom packaged (aggregtor) project files shouldn't activate clean to delete /target
[
http://jira.codehaus.org/browse/MCLEAN-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MCLEAN-20.
---
Assignee: Benjamin Bentmann
Resolution: Won't Fix
As said, excluding {{clean}} from the lifecycle is in general not appropriate
for projects with packaging pom. You can however use the plugin parameter
{{[skip|http://maven.apache.org/plugins/maven-clean-plugin/clean-mojo.html#skip]}}
introduced in version 2.2 to selectively disabled cleaning for certain
projects.
pom packaged (aggregtor) project files shouldn't activate clean to delete
/target
---
Key: MCLEAN-20
URL: http://jira.codehaus.org/browse/MCLEAN-20
Project: Maven 2.x Clean Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: David Boden
Assignee: Benjamin Bentmann
If you have projects with the following layout:
cds_adapter/pom.xml
cds_adapter/pom-complete.xml - an aggregator
deriv_adapter/pom.xml
Then when you do:
mvn -f pom-complete.xml clean install
what you want is for deriv_adapter's jar to be built and installed followed
by cds_adapter's jar.
This happens. However, unfortunately the last thing to run is the clean
install task on the pom-complete.xml project. This deletes the
cds_adapter/target directory. The desired behaviour would be for the
aggregator pom not to result in the deletion of the /target directory.
Aggregator poms do not install anything into target and should not take
part in the clean workflow.
The workaround is to issue the commands separately:
mvn -f pom-complete.xml clean
mvn -f pom-complete.xml install
--
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: (MCLEAN-35) Upgrade plexus-utils to a new version
[ http://jira.codehaus.org/browse/MCLEAN-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MCLEAN-35. --- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.3 Done in [r692711|http://svn.apache.org/viewvc?view=revrevision=692711] by updating to plexus-utils:1.5.6. Upgrade plexus-utils to a new version - Key: MCLEAN-35 URL: http://jira.codehaus.org/browse/MCLEAN-35 Project: Maven 2.x Clean Plugin Issue Type: Sub-task Affects Versions: 2.3 Reporter: Vincent Siveton Assignee: Benjamin Bentmann Fix For: 2.3 -- 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: (MCLEAN-34) NPE when forcing delete of directory
[ http://jira.codehaus.org/browse/MCLEAN-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MCLEAN-34. --- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.3 Fixed in [r692711|http://svn.apache.org/viewvc?view=revrevision=692711] by updating to plexus-utils:1.5.6. NPE when forcing delete of directory Key: MCLEAN-34 URL: http://jira.codehaus.org/browse/MCLEAN-34 Project: Maven 2.x Clean Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Maven 2.0.9, JDK 1.6.05 Reporter: Paul Benedict Assignee: Benjamin Bentmann Fix For: 2.3 I ran clean site:site and ended up with this error. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.codehaus.plexus.util.FileUtils.cleanDirectory(FileUtils.java:1263) at org.codehaus.plexus.util.FileUtils.deleteDirectory(FileUtils.java:1224) at org.codehaus.plexus.util.FileUtils.forceDelete(FileUtils.java:1087) at org.apache.maven.shared.model.fileset.util.FileSetManager.delete(FileSetManager.java:618) at org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:594) at org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574) at org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574) at org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574) at org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574) at org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574) at org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574) at org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574) at org.apache.maven.shared.model.fileset.util.FileSetManager.delete(FileSetManager.java:309) at org.apache.maven.plugin.clean.CleanMojo.removeDirectory(CleanMojo.java:261) at org.apache.maven.plugin.clean.CleanMojo.execute(CleanMojo.java:173) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 20 seconds [INFO] Finished at: Mon Jun 30 22:00:11 CDT 2008 [INFO] Final Memory: 4M/9M [INFO] -- 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: (MCLEAN-28) maven-clean-plugin doesn't delete directories with symlinks in them
[ http://jira.codehaus.org/browse/MCLEAN-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MCLEAN-28. --- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.3 Fixed in [r692711|http://svn.apache.org/viewvc?view=revrevision=692711] by updating to plexus-utils:1.5.6, added test in [r692725|http://svn.apache.org/viewvc?view=revrevision=692725]. maven-clean-plugin doesn't delete directories with symlinks in them --- Key: MCLEAN-28 URL: http://jira.codehaus.org/browse/MCLEAN-28 Project: Maven 2.x Clean Plugin Issue Type: Bug Affects Versions: 2.2 Environment: maven 2.0.7, Ubuntu 7.10, Intel Pentium M Reporter: Steinar Bang Assignee: Benjamin Bentmann Fix For: 2.3 Note: this issue did not happen with maven-2.0.4 and maven-clean-plugin 2.1.1. I have a maven project for a JNI library wrapping several shared libs. For testing, the shared libs are unpacked into target/tmplib, and the maven-surefire-plugin gets a LD_LIBRARY_PATH enviroment variable setting pointing to this directory. The shared libs are unpacked in a manner that preserves their symbolic links, eg. lrwxrwxrwx 1 sb sb 17 Dec 23 22:00 libxml2.so - libxml2.so.2.6.23 lrwxrwxrwx 1 sb sb 17 Dec 23 22:00 libxml2.so.2 - libxml2.so.2.6.23 -rwxr-x--- 1 sb sb 3104024 Nov 28 13:23 libxml2.so.2.6.23 lrwxrwxrwx 1 sb sb 13 Dec 23 22:00 libz.so - libz.so.1.2.3 lrwxrwxrwx 1 sb sb 13 Dec 23 22:00 libz.so.1 - libz.so.1.2.3 -rwxr-x--- 1 sb sb 168053 Nov 28 13:08 libz.so.1.2.3 When doing mvn clean it refuses to delete target/tmplib (see the error message with stack trace below), and when I inspect the target/tmplib directory, it contains only symlinks. The files they point to have been removed. Using the example above, it now looks like: lrwxrwxrwx 1 sb sb 17 Dec 23 22:00 libxml2.so - libxml2.so.2.6.23 lrwxrwxrwx 1 sb sb 17 Dec 23 22:00 libxml2.so.2 - libxml2.so.2.6.23 lrwxrwxrwx 1 sb sb 13 Dec 23 22:00 libz.so - libz.so.1.2.3 lrwxrwxrwx 1 sb sb 13 Dec 23 22:00 libz.so.1 - libz.so.1.2.3 The error message with stack trace, looks like this: [INFO] [clean:clean] [INFO] Deleting directory /home/sb/p4/depot/someproj/MAIN/com.somecompany.someproj.somejnilib/target [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to delete directory: /home/sb/p4/depot/someproj/MAIN/com.somecompany.someproj.somejnilib/target. Reason: Unable to delete directory /home/sb/p4/depot/someproj/MAIN/com.somecompany.someproj.somejnilib/target/tmplib [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to delete directory: /home/sb/p4/depot/someproj/MAIN/com.somecompany.someproj.somejnilib/target. Reason: Unable to delete directory /home/sb/p4/depot/someproj/MAIN/com.somecompany.someproj.somejnilib/target/tmplib at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to delete directory:
[jira] Reopened: (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
]
Olivier Lamy reopened MRESOURCES-20:
The issue was marked fixed only because maven-filtering component fixes the
ClassCastException.
But if you have a property
{code}
fileValue=${foo.file}
{code}
If this is not found in properties files, project.build.filters,
project.properties and mavenSession.executionProperties, you will have
${foo.file} interpolated with the pom full path.
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
Assignee: Olivier Lamy
Priority: Critical
Fix For: 2.3
Attachments: MRESOURCES-20.patch, ReflectionProperties.java
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] Created: (MRESOURCES-73) Filtering ${foo.file} evaluates to in full path to pom.xml
Filtering ${foo.file} evaluates to in full path to pom.xml
--
Key: MRESOURCES-73
URL: http://jira.codehaus.org/browse/MRESOURCES-73
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows XP, Maven 2.0.2
Reporter: Olivier Lamy
Assignee: Olivier Lamy
Priority: Critical
Fix For: 2.3
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] Moved: (MSHARED-60) Filtering ${foo.file} evaluates to in full path to pom.xml
[
http://jira.codehaus.org/browse/MSHARED-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy moved MRESOURCES-73 to MSHARED-60:
---
Affects Version/s: (was: 2.2)
maven-filtering-1.0-beta-1
Fix Version/s: (was: 2.3)
maven-filtering-1.0-beta-2
Key: MSHARED-60 (was: MRESOURCES-73)
Project: Maven Shared Components (was: Maven 2.x Resources
Plugin)
Filtering ${foo.file} evaluates to in full path to pom.xml
--
Key: MSHARED-60
URL: http://jira.codehaus.org/browse/MSHARED-60
Project: Maven Shared Components
Issue Type: Bug
Affects Versions: maven-filtering-1.0-beta-1
Environment: Windows XP, Maven 2.0.2
Reporter: Olivier Lamy
Assignee: Olivier Lamy
Priority: Critical
Fix For: maven-filtering-1.0-beta-2
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] Commented: (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:comment-tabpanelfocusedCommentId=147229#action_147229
]
Stephane Nicoll commented on MRESOURCES-20:
---
I can't reproduce this with the war plugin and a filtered web resource. What am
I missing?
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
Assignee: Olivier Lamy
Priority: Critical
Fix For: 2.3
Attachments: MRESOURCES-20.patch, ReflectionProperties.java
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] Commented: (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:comment-tabpanelfocusedCommentId=147230#action_147230
]
Olivier Lamy commented on MRESOURCES-20:
IMHO the it MWAR-133 is false.
There is a file filtered.properties which contains app.version=${node.version}.
The it pom has a property called node.version but if you remone this property
the result file will have the value : app.version= the pom version
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
Assignee: Olivier Lamy
Priority: Critical
Fix For: 2.3
Attachments: MRESOURCES-20.patch, ReflectionProperties.java
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] Reopened: (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
]
Olivier Lamy reopened MWAR-133:
---
see comment in MRESOURCES-20
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] Commented: (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:comment-tabpanelfocusedCommentId=147232#action_147232
]
Benjamin Bentmann commented on MRESOURCES-20:
-
Shouldn't we change {{MavenProjectValueSource}} to only filter POM values if
the expression starts with {{pom.}} or {{project.}}? It's currently aliasing
all of the following expressions
- version
- pom.version
- foo.version
to the POM version which doesn't seem right to me.
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
Assignee: Olivier Lamy
Priority: Critical
Fix For: 2.3
Attachments: MRESOURCES-20.patch, ReflectionProperties.java
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] Commented: (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:comment-tabpanelfocusedCommentId=147233#action_147233
]
Olivier Lamy commented on MRESOURCES-20:
Yup that's what I'm doing. :-) to fix MSHARED-60.
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
Assignee: Olivier Lamy
Priority: Critical
Fix For: 2.3
Attachments: MRESOURCES-20.patch, ReflectionProperties.java
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] Closed: (MSHARED-60) Filtering ${foo.file} evaluates to in full path to pom.xml
[
http://jira.codehaus.org/browse/MSHARED-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MSHARED-60.
---
Resolution: Fixed
fixed in rev [692742|http://svn.apache.org/viewvc?view=revrevision=692742]
Filtering ${foo.file} evaluates to in full path to pom.xml
--
Key: MSHARED-60
URL: http://jira.codehaus.org/browse/MSHARED-60
Project: Maven Shared Components
Issue Type: Bug
Affects Versions: maven-filtering-1.0-beta-1
Environment: Windows XP, Maven 2.0.2
Reporter: Olivier Lamy
Assignee: Olivier Lamy
Priority: Critical
Fix For: maven-filtering-1.0-beta-2
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
]
Olivier Lamy updated MWAR-133:
--
Assignee: Olivier Lamy (was: Stephane Nicoll)
Fix Version/s: (was: 2.1-alpha-2)
2.1
fix in rev [692743|http://svn.apache.org/viewvc?rev=692743view=rev]
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: Olivier Lamy
Fix For: 2.1
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
]
Olivier Lamy closed MWAR-133.
-
Resolution: Fixed
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: Olivier Lamy
Fix For: 2.1
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: (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
]
Olivier Lamy closed MRESOURCES-20.
--
Resolution: Fixed
fixed in rev [692744|http://svn.apache.org/viewvc?rev=692744view=rev]
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
Assignee: Olivier Lamy
Priority: Critical
Fix For: 2.3
Attachments: MRESOURCES-20.patch, ReflectionProperties.java
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] Closed: (MSHARED-59) More debug output in maven filtering
[ http://jira.codehaus.org/browse/MSHARED-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHARED-59. --- Assignee: Olivier Lamy Resolution: Fixed Fixed in rev [692749|http://svn.apache.org/viewvc?rev=692749view=rev] Debug display : - copying/filtering from to - all properties collected - if a file extension can be filtered or not More debug output in maven filtering Key: MSHARED-59 URL: http://jira.codehaus.org/browse/MSHARED-59 Project: Maven Shared Components Issue Type: Wish Components: maven-filtering Affects Versions: maven-filtering-1.0-beta-1 Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: maven-filtering-1.0-beta-2 It would be helpful if the resources mojos were more verbose with the -X flag. In version 2.2, they don't provide any extra information. Useful info might include the Resource which is being processed, the source and target of each file copy, etc. -- 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: (MRESOURCES-42) Filtering properties that contain ${basedir} for property files doesn't escape backslashes
[
http://jira.codehaus.org/browse/MRESOURCES-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MRESOURCES-42.
--
Assignee: Olivier Lamy
Resolution: Fixed
fix by using maven-filtering component
Filtering properties that contain ${basedir} for property files doesn't
escape backslashes
---
Key: MRESOURCES-42
URL: http://jira.codehaus.org/browse/MRESOURCES-42
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.2, 2.3
Environment: OS: Windows XP; Maven: 2.0.5, 2.0.6;
Reporter: Jérémy Soula
Assignee: Olivier Lamy
Fix For: 2.3
Attachments: MRESOURCES-42-maven-resources-plugin-2.3-SNAPSHOT.patch
For exemple consider this in a filtered property files
application.propertyOne=${pom.build.directory}
application.propertyTwo=${basedir}
which generates after filtering:
application.propertyOne=D\:\\ProjectsDirectory\\project\\target
application.propertyTwo=D:\ProjectsDirectory\project\
Behavior are different and causes a second property bad value when reading
the properties file.
--
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: (MPIR-139) Generation of project-info.html cannot be omitted
Generation of project-info.html cannot be omitted - Key: MPIR-139 URL: http://jira.codehaus.org/browse/MPIR-139 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: index Affects Versions: 2.1 Reporter: Michael Osipov There is no option to prevent the MPIR to generate the project-info.html. Please fix this. -- 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: (MRESOURCES-39) Filtering fails for command line properties
[ http://jira.codehaus.org/browse/MRESOURCES-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRESOURCES-39. -- Resolution: Fixed it added in rev [692758|http://svn.apache.org/viewvc?rev=692758view=rev] Filtering fails for command line properties --- Key: MRESOURCES-39 URL: http://jira.codehaus.org/browse/MRESOURCES-39 Project: Maven 2.x Resources Plugin Issue Type: Bug Affects Versions: 2.2 Environment: maven-2.0.4 and maven-2.0.5 Mac OS X Reporter: Matt Brozowski Assignee: Olivier Lamy Priority: Critical Fix For: 2.3 Attachments: filtering-bug.tar, maven-resources-plugin-prop-filtering-r630241.patch When passing a property on the command line to maven using -D it does not properly override values passed to filters. I have attached a sample project that defines a property in the pom.xml called 'filtered' This property is used as a filter in the filtered.properties file in src/main/filtered/filtered.properties. I have also included a test that gets passed the filtered property as a System property via the surefire plugin. It then loaded the filtered.properties file and tests to ensure the filters match. The tests pass when run as mvn test BUT if I run as mvn -Dfiltered=from-cmd-line teset They fail. I have also included the antrun plugin print its perspective on the value of the property. -- 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: (MRESOURCES-65) filtered resources contains incorrect content
[
http://jira.codehaus.org/browse/MRESOURCES-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MRESOURCES-65.
--
Assignee: Olivier Lamy
Resolution: Fixed
Fix Version/s: 2.3
fix with using last maven-filtering version
filtered resources contains incorrect content
-
Key: MRESOURCES-65
URL: http://jira.codehaus.org/browse/MRESOURCES-65
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Pappy Razvan STANESCU
Assignee: Olivier Lamy
Fix For: 2.3
Attachments: filtres.tar.gz
A project contains as resource the following Velocity template
\\
{code:none|title=src/main/resources/App.txt|borderStyle=solid}
${url}
${id}
${version}
${anotherProperty}
${infoBean.url}
${infoBean.id}
${infoBean.anotherProperty}
${infoBean.version}
${infoBean.myUrl}
${infoBean.myId}
${pom.version}
{code}
When filtering is set for this file the resulted output is wrong
{code:none|title=target/classes/App.txt|borderStyle=solid}
http://maven.apache.org
maven.bugs:filtres:jar:1.0-SNAPSHOT
1.0-SNAPSHOT
anotherValue
http://maven.apache.org
maven.bugs:filtres:jar:1.0-SNAPSHOT
${infoBean.anotherProperty}
1.0-SNAPSHOT
${infoBean.myUrl}
${infoBean.myId}
1.0-SNAPSHOT
{code}
\\
While it is acceptable to have ${pom.version} replaced or even ${id} or
${version}, the ${infoBean.*} lines should be left untouched as long as such
properties are not defined for the project.
A sample project is attached...
--
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-29) An escape mechanism for property interpolation is missing.
[
http://jira.codehaus.org/browse/MRESOURCES-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MRESOURCES-29:
---
Assignee: Olivier Lamy
Fix Version/s: 2.3
An escape mechanism for property interpolation is missing.
--
Key: MRESOURCES-29
URL: http://jira.codehaus.org/browse/MRESOURCES-29
Project: Maven 2.x Resources Plugin
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Hendrik Schreiber
Assignee: Olivier Lamy
Fix For: 2.3
It would be great, if there was a mechanism that let's you escape a property
so that it is not replaced by the filtering machism. E.g. in a log4j.xml
configuration file you might want to preserve ${user.home}, but replace some
other property like ${log.dir}. Currently there is no convenient way to
achieve that.
Alternatively to escaping, it would be helpful, if one could choose the token
format. So, if one could say, only honor @token@ and not ${token} (or the
other way around) one could easily work around the escape problem.
Workaround for the problem mentioned above:
replace the ${user.home} in log4j.xml with @[EMAIL PROTECTED]@end@ and define
start=${and end=$} in the property file
--
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: (MRESOURCES-59) filtering with @property@
[ http://jira.codehaus.org/browse/MRESOURCES-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRESOURCES-59. -- Assignee: Olivier Lamy Resolution: Fixed Fix Version/s: 2.3 fix with using maven-filtering component. it added for this token in rev 692760. filtering with @property@ - Key: MRESOURCES-59 URL: http://jira.codehaus.org/browse/MRESOURCES-59 Project: Maven 2.x Resources Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Stefano Fornari Assignee: Olivier Lamy Fix For: 2.3 From the source code, it looks like @property@ should be expanded as well. It does not work with the tests I've done -- 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: (MRESOURCES-69) Filtering with POM.xml elements
[
http://jira.codehaus.org/browse/MRESOURCES-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MRESOURCES-69.
--
Assignee: Olivier Lamy
Resolution: Fixed
Fix Version/s: 2.3
fixed with using maven-filtering component.
Filtering with POM.xml elements
---
Key: MRESOURCES-69
URL: http://jira.codehaus.org/browse/MRESOURCES-69
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Reporter: Zach Legein
Assignee: Olivier Lamy
Fix For: 2.3
Attachments: maven-bug.tar.gz
I have this weird error where if I have a project like the one attached. It
appears that when filtering is set to _true_ and you have an file that has a
reference to a 'name' value, like so:
{code:xml}
html
head
title${something.name}/title
/head
/html
{code}
The pom.xml _name_ element will be used when filtering this file.
So if your pom.xml is written like so:
{code:xml}
project
nameLook at Me!/name
/project
{code}
This _name_ value will be used to do filtering if turned on.
Granted you would want to set up your project like this, but this is not
expected behavior, right?
--
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-8) maven-resources-plugin ignores configuration/resources property
[
http://jira.codehaus.org/browse/MRESOURCES-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MRESOURCES-8:
--
Assignee: Olivier Lamy (was: Brett Porter)
Affects Version/s: 2.1
2.2
Fix Version/s: 2.3
Issue Type: New Feature (was: Bug)
maven-resources-plugin ignores configuration/resources property
---
Key: MRESOURCES-8
URL: http://jira.codehaus.org/browse/MRESOURCES-8
Project: Maven 2.x Resources Plugin
Issue Type: New Feature
Affects Versions: 2.1, 2.2
Reporter: Leszek Gawron
Assignee: Olivier Lamy
Fix For: 2.3
Attachments: example.zip, MRESOURCES-8-workaround.patch, pom.xml
I am evaluating maven + eclipse combo. In a trivial POM filtered resources
exist only in target/classes. If one executes Project - Clean under eclipse
this information is lost. If filtered resources would appear as source folder
they would survive cleaning and not got overriden by unfiltered ones.
I have been trying to implement a scenario which would allow filtered
resources to appear as static source folder under eclipse.
The POM explains it best:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.mobilebox.squash.client/groupId
artifactIdsquash-client/artifactId
packagingjar/packaging
version1.0-SNAPSHOT/version
nameMaven Quick Start Archetype/name
urlhttp://maven.apache.org/url
build
plugins
plugin
artifactIdmaven-resources-plugin/artifactId
executions
execution
idprefilter-resources/id
phasegenerate-resources/phase
goals
goalresources/goal
/goals
configuration
outputDirectorytarget/generated-resources/outputDirectory
resources
resource
directorysrc/main/resource-templates/directory
filteringtrue/filtering
/resource
/resources
/configuration
/execution
/executions
/plugin
/plugins
filters
filter${ffile}/filter
/filters
resources
resource
directorysrc/main/resources/directory
/resource
resource
directorytarget/generated-resources/directory
/resource
/resources
/build
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
/dependencies
properties
ffilefilter.properties/ffile
/properties
/project
thing is this part:
resources
resource
directorysrc/main/properties/directory
filteringtrue/filtering
/resource
/resources
is completely ignored. Instead for both maven-resource-plugin executions (the
one in generate-resources phase and the default one) this config is used:
resources
resource
directorysrc/main/resources/directory
/resource
resource
directorytarget/generated-resources/directory
/resource
/resources
which of course breaks the whole idea.
Is this a bug or a design decision. In latter case is there any equivalent
approach I might take?
--
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: (MSITE-150) Inconsistent navigational mechanisms: If project defines its own index page (e.g. apt/index.apt) the Project Information-About link is missing.
[ http://jira.codehaus.org/browse/MSITE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-150. - Assignee: Dennis Lundberg Resolution: Fixed Fixed in [r692763|http://svn.apache.org/viewvc?view=revrevision=692763]. New SNAPSHOT deployed. Inconsistent navigational mechanisms: If project defines its own index page (e.g. apt/index.apt) the Project Information-About link is missing. Key: MSITE-150 URL: http://jira.codehaus.org/browse/MSITE-150 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: 2.0.4, JDK14, XP Reporter: John Allen Assignee: Dennis Lundberg Fix For: 2.0-beta-8 If project defines its own index page (e.g. apt/index.apt) the Project Information-About link is removed. I can see the argument that states 'if youve developed your own front page you can define the index to it yourself' but this just results in inconsistencies in the navigational mechanisms used in maven generated sites. If one of my projects provides its own index page then you will have to browse to it via some new menu based link and for all the other projects you can get to it via the About link. I think About should always link to index.apt. Note: apologies if this is a MPIR issue, its manifested by running site so ive raised it in site. -- 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: (MSITE-47) validate input format of docs
[ http://jira.codehaus.org/browse/MSITE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-47: - Issue Type: New Feature (was: Bug) validate input format of docs - Key: MSITE-47 URL: http://jira.codehaus.org/browse/MSITE-47 Project: Maven 2.x Site Plugin Issue Type: New Feature Reporter: Brett Porter Fix For: 2.0-beta-8 valid: - xdoc - apt (done on the fly) - fml - site.xml (most should be on the fly, verify that it handles appropriately). Perhaps make whether this is an error or ignored should be configurable -- 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: (MSITE-30) site:deploy incompatibilities with m1.02
[ http://jira.codehaus.org/browse/MSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-30: - Issue Type: Improvement (was: Bug) site:deploy incompatibilities with m1.02 Key: MSITE-30 URL: http://jira.codehaus.org/browse/MSITE-30 Project: Maven 2.x Site Plugin Issue Type: Improvement Components: site:deploy Environment: All Reporter: Paul Spencer Fix For: 2.0-beta-8 Deploying a site in m2 has changed since m1. 1) m1 used the tar and gunzip command on the remote site, where m2 uses the unzip command. This poses a problem for be since my remote site does not support the unzip command, thus making the priority of this issue major 1.1) Their may be desire to deploy without the use of tools like tar and zip on some site. The deploy would esentailly be a recersive copy 2) No equivelent to m1 property maven.site.chmod.mode. I use this to allow other member is the group update and delete permission 3) No equivelent to m1 property maven.site.publish.clean Their are other properties for the m1.02 not mentioned above, but I suspect the they can be calculated from m2 files, i.e. pom.xml and settings.xml. Paul Spencer -- 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
