[jira] Closed: (DOXIA-213) There is no way to include images using relative urls
[ http://jira.codehaus.org/browse/DOXIA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-213. --- Assignee: Lukas Theussl Resolution: Duplicate > There is no way to include images using relative urls > - > > Key: DOXIA-213 > URL: http://jira.codehaus.org/browse/DOXIA-213 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Twiki >Affects Versions: 1.0-beta-1 >Reporter: Gabriel Falkenberg >Assignee: Lukas Theussl > Attachments: HTML_Image_Tag_support.patch > > > There is currently no way to have relative images in twiki-format. Reading > the twiki docs suggests that this should be implemented by adding > funtionality to parse ordinary img-tags (which could then be both relative > and absolute). For XHTML-output this would be something we get for free by > fixing DOXIA-153 but that wouldn't use sink.figure so it would probably not > work for PDF-output (please correct me if I'm wrong). -- 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: (MWAR-139) Wrong token replacement (@@ is replaced with [EMAIL PROTECTED])
[ http://jira.codehaus.org/browse/MWAR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122531 ] Stephane Nicoll commented on MWAR-139: -- I have added an IT in the war project. The shell script has a commented part for now. If you uncomment you can easily reproduce the problem. > Wrong token replacement (@@ is replaced with [EMAIL PROTECTED]) > > > Key: MWAR-139 > URL: http://jira.codehaus.org/browse/MWAR-139 > Project: Maven 2.x War Plugin > Issue Type: Bug > Environment: Linux 2.6 >Reporter: Jan Torben Heuer >Assignee: Olivier Lamy >Priority: Critical > Fix For: 2.1-alpha-2 > > Attachments: mavenbug.tar.gz > > > maven replaces the String @@ in resources with [EMAIL PROTECTED] > I enabled filtering for the resources and my variables are correctly replaced. > Jan -- 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-139) Wrong token replacement (@@ is replaced with [EMAIL PROTECTED])
[ http://jira.codehaus.org/browse/MWAR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MWAR-139: - Assignee: Olivier Lamy Fix Version/s: 2.1-alpha-2 Summary: Wrong token replacement (@@ is replaced with [EMAIL PROTECTED]) (was: maven replaces @@ with [EMAIL PROTECTED] in resources) Correct. Olivier, is this something that you can include in the maven-shared-filtering thingy before the first release? Is there a Jira project for this by the way? > Wrong token replacement (@@ is replaced with [EMAIL PROTECTED]) > > > Key: MWAR-139 > URL: http://jira.codehaus.org/browse/MWAR-139 > Project: Maven 2.x War Plugin > Issue Type: Bug > Environment: Linux 2.6 >Reporter: Jan Torben Heuer >Assignee: Olivier Lamy >Priority: Critical > Fix For: 2.1-alpha-2 > > Attachments: mavenbug.tar.gz > > > maven replaces the String @@ in resources with [EMAIL PROTECTED] > I enabled filtering for the resources and my variables are correctly replaced. > Jan -- 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-33) jars with differents versions can be in WEB-INF/lib with war as dependencies
[ http://jira.codehaus.org/browse/MWAR-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MWAR-33: Fix Version/s: (was: 2.1-alpha-2) 2.1 > jars with differents versions can be in WEB-INF/lib with war as dependencies > > > Key: MWAR-33 > URL: http://jira.codehaus.org/browse/MWAR-33 > Project: Maven 2.x War Plugin > Issue Type: Bug > Environment: all >Reporter: Olivier Lamy >Assignee: Stephane Nicoll > Fix For: 2.1 > > Original Estimate: 15 minutes > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > > My pom has the following dependencies : > - log4j:log4j:1.2.13 > - a war with log4j:log4j:1.2.11 included > Result the two jars are in WEB-INF/lib. -- 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: (MCHANGES-88) NoSuchMethodError with maven 2.0.8 when generating changes-report
[ http://jira.codehaus.org/browse/MCHANGES-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122520 ] niallp edited comment on MCHANGES-88 at 2/5/08 8:23 PM: - The problem seems to be that the createSink(File, String) method was removed from org.apache.maven.doxia.siterenderer.Renderer in revision 385559: - http://tinyurl.com/2wh8lr I checked out the "Project Info" reports to see if they could be run individually as well - which they can and looking at the maven-project-info-reports-plugin - it has its own execute() method in AbstractProjectInfoReport which all the reports in that plugin use. I'm attaching a patch which copies the AbstractProjectInfoReport into the changes plugin, renames it (to AbstractChangesReport) and modifies the changes and jira reports (confirmed this has the same issue) to use that abstract implementation. This seems resolves the issue. Running the JIRA report failed if the target directory didn't exist - so I also added code to fix that. In case my patch for the copied/modified AbstractProjectInfoReport doesn't work properly, I'm attaching a full copy of it as well (btw I copied the last 2.0.1 release version of AbstractProjectInfoReport) was (Author: niallp): The problem seems to be that the createSink(File, String) method was removed from org.apache.maven.doxia.siterenderer.Renderer in revision 358449: - http://tinyurl.com/2wh8lr I checked out the "Project Info" reports to see if they could be run individually as well - which they can and looking at the maven-project-info-reports-plugin - it has its own execute() method in AbstractProjectInfoReport which all the reports in that plugin use. I'm attaching a patch which copies the AbstractProjectInfoReport into the changes plugin, renames it (to AbstractChangesReport) and modifies the changes and jira reports (confirmed this has the same issue) to use that abstract implementation. This seems resolves the issue. Running the JIRA report failed if the target directory didn't exist - so I also added code to fix that. In case my patch for the copied/modified AbstractProjectInfoReport doesn't work properly, I'm attaching a full copy of it as well (btw I copied the last 2.0.1 release version of AbstractProjectInfoReport) > NoSuchMethodError with maven 2.0.8 when generating changes-report > - > > Key: MCHANGES-88 > URL: http://jira.codehaus.org/browse/MCHANGES-88 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes-report >Affects Versions: 2.0-beta-3 > Environment: [EMAIL PROTECTED]:/opt/nc/workspace/test_maven$ mvn > -version > Maven version: 2.0.8 > Java version: 1.6.0_03 > OS name: "linux" version: "2.6.18-5-686" arch: "i386" Family: "unix" >Reporter: Julien Graglia > Attachments: AbstractChangesReport.java, changes.log, changes.zip, > error.log, MCHANGES-88-Fix-NoSuchMethodError.patch, pom.xml, site.log > > > I create a simple maven2 project, but when i call > mvn -X -e changes:changes-report > I get an error (full log in attachment) > java.lang.NoSuchMethodError: > org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink; > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) -- 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: (MCHANGES-88) NoSuchMethodError with maven 2.0.8 when generating changes-report
[ http://jira.codehaus.org/browse/MCHANGES-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122520 ] niallp edited comment on MCHANGES-88 at 2/5/08 8:21 PM: - The problem seems to be that the createSink() method was removed from org.apache.maven.doxia.siterenderer.Renderer in revision 358449: - http://tinyurl.com/2wh8lr I checked out the "Project Info" reports to see if they could be run individually as well - which they can and looking at the maven-project-info-reports-plugin - it has its own execute() method in AbstractProjectInfoReport which all the reports in that plugin use. I'm attaching a patch which copies the AbstractProjectInfoReport into the changes plugin, renames it (to AbstractChangesReport) and modifies the changes and jira reports (confirmed this has the same issue) to use that abstract implementation. This seems resolves the issue. Running the JIRA report failed if the target directory didn't exist - so I also added code to fix that. In case my patch for the copied/modified AbstractProjectInfoReport doesn't work properly, I'm attaching a full copy of it as well (btw I copied the last 2.0.1 release version of AbstractProjectInfoReport) was (Author: niallp): The problem seems to be that the createSink() method was removed from org.apache.maven.doxia.siterenderer.Renderer in revision 358449: - http://tinyurl.com/38v6bg I checked out the "Project Info" reports to see if they could be run individually as well - which they can and looking at the maven-project-info-reports-plugin - it has its own execute() method in AbstractProjectInfoReport which all the reports in that plugin use. I'm attaching a patch which copies the AbstractProjectInfoReport into the changes plugin, renames it (to AbstractChangesReport) and modifies the changes and jira reports (confirmed this has the same issue) to use that abstract implementation. This seems resolves the issue. Running the JIRA report failed if the target directory didn't exist - so I also added code to fix that. In case my patch for the copied/modified AbstractProjectInfoReport doesn't work properly, I'm attaching a full copy of it as well (btw I copied the last 2.0.1 release version of AbstractProjectInfoReport) > NoSuchMethodError with maven 2.0.8 when generating changes-report > - > > Key: MCHANGES-88 > URL: http://jira.codehaus.org/browse/MCHANGES-88 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes-report >Affects Versions: 2.0-beta-3 > Environment: [EMAIL PROTECTED]:/opt/nc/workspace/test_maven$ mvn > -version > Maven version: 2.0.8 > Java version: 1.6.0_03 > OS name: "linux" version: "2.6.18-5-686" arch: "i386" Family: "unix" >Reporter: Julien Graglia > Attachments: AbstractChangesReport.java, changes.log, changes.zip, > error.log, MCHANGES-88-Fix-NoSuchMethodError.patch, pom.xml, site.log > > > I create a simple maven2 project, but when i call > mvn -X -e changes:changes-report > I get an error (full log in attachment) > java.lang.NoSuchMethodError: > org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink; > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) -- 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: (MCHANGES-88) NoSuchMethodError with maven 2.0.8 when generating changes-report
[ http://jira.codehaus.org/browse/MCHANGES-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122520 ] niallp edited comment on MCHANGES-88 at 2/5/08 8:21 PM: - The problem seems to be that the createSink(File, String) method was removed from org.apache.maven.doxia.siterenderer.Renderer in revision 358449: - http://tinyurl.com/2wh8lr I checked out the "Project Info" reports to see if they could be run individually as well - which they can and looking at the maven-project-info-reports-plugin - it has its own execute() method in AbstractProjectInfoReport which all the reports in that plugin use. I'm attaching a patch which copies the AbstractProjectInfoReport into the changes plugin, renames it (to AbstractChangesReport) and modifies the changes and jira reports (confirmed this has the same issue) to use that abstract implementation. This seems resolves the issue. Running the JIRA report failed if the target directory didn't exist - so I also added code to fix that. In case my patch for the copied/modified AbstractProjectInfoReport doesn't work properly, I'm attaching a full copy of it as well (btw I copied the last 2.0.1 release version of AbstractProjectInfoReport) was (Author: niallp): The problem seems to be that the createSink() method was removed from org.apache.maven.doxia.siterenderer.Renderer in revision 358449: - http://tinyurl.com/2wh8lr I checked out the "Project Info" reports to see if they could be run individually as well - which they can and looking at the maven-project-info-reports-plugin - it has its own execute() method in AbstractProjectInfoReport which all the reports in that plugin use. I'm attaching a patch which copies the AbstractProjectInfoReport into the changes plugin, renames it (to AbstractChangesReport) and modifies the changes and jira reports (confirmed this has the same issue) to use that abstract implementation. This seems resolves the issue. Running the JIRA report failed if the target directory didn't exist - so I also added code to fix that. In case my patch for the copied/modified AbstractProjectInfoReport doesn't work properly, I'm attaching a full copy of it as well (btw I copied the last 2.0.1 release version of AbstractProjectInfoReport) > NoSuchMethodError with maven 2.0.8 when generating changes-report > - > > Key: MCHANGES-88 > URL: http://jira.codehaus.org/browse/MCHANGES-88 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes-report >Affects Versions: 2.0-beta-3 > Environment: [EMAIL PROTECTED]:/opt/nc/workspace/test_maven$ mvn > -version > Maven version: 2.0.8 > Java version: 1.6.0_03 > OS name: "linux" version: "2.6.18-5-686" arch: "i386" Family: "unix" >Reporter: Julien Graglia > Attachments: AbstractChangesReport.java, changes.log, changes.zip, > error.log, MCHANGES-88-Fix-NoSuchMethodError.patch, pom.xml, site.log > > > I create a simple maven2 project, but when i call > mvn -X -e changes:changes-report > I get an error (full log in attachment) > java.lang.NoSuchMethodError: > org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink; > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) -- 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: (MCHANGES-88) NoSuchMethodError with maven 2.0.8 when generating changes-report
[ http://jira.codehaus.org/browse/MCHANGES-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated MCHANGES-88: Attachment: MCHANGES-88-Fix-NoSuchMethodError.patch AbstractChangesReport.java The problem seems to be that the createSink() method was removed from org.apache.maven.doxia.siterenderer.Renderer in revision 358449: - http://tinyurl.com/38v6bg I checked out the "Project Info" reports to see if they could be run individually as well - which they can and looking at the maven-project-info-reports-plugin - it has its own execute() method in AbstractProjectInfoReport which all the reports in that plugin use. I'm attaching a patch which copies the AbstractProjectInfoReport into the changes plugin, renames it (to AbstractChangesReport) and modifies the changes and jira reports (confirmed this has the same issue) to use that abstract implementation. This seems resolves the issue. Running the JIRA report failed if the target directory didn't exist - so I also added code to fix that. In case my patch for the copied/modified AbstractProjectInfoReport doesn't work properly, I'm attaching a full copy of it as well (btw I copied the last 2.0.1 release version of AbstractProjectInfoReport) > NoSuchMethodError with maven 2.0.8 when generating changes-report > - > > Key: MCHANGES-88 > URL: http://jira.codehaus.org/browse/MCHANGES-88 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes-report >Affects Versions: 2.0-beta-3 > Environment: [EMAIL PROTECTED]:/opt/nc/workspace/test_maven$ mvn > -version > Maven version: 2.0.8 > Java version: 1.6.0_03 > OS name: "linux" version: "2.6.18-5-686" arch: "i386" Family: "unix" >Reporter: Julien Graglia > Attachments: AbstractChangesReport.java, changes.log, changes.zip, > error.log, MCHANGES-88-Fix-NoSuchMethodError.patch, pom.xml, site.log > > > I create a simple maven2 project, but when i call > mvn -X -e changes:changes-report > I get an error (full log in attachment) > java.lang.NoSuchMethodError: > org.apache.maven.doxia.siterenderer.Renderer.createSink(Ljava/io/File;Ljava/lang/String;)Lorg/apache/maven/doxia/siterenderer/sink/SiteRendererSink; > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:63) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) -- 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: (MCHANGES-96) Change type of path parameters to java.io.File
[ http://jira.codehaus.org/browse/MCHANGES-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-96. --- Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.0-beta-4 The patch has been applied. Thank you! > Change type of path parameters to java.io.File > -- > > Key: MCHANGES-96 > URL: http://jira.codehaus.org/browse/MCHANGES-96 > Project: Maven 2.x Changes Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-3 >Reporter: Benjamin Bentmann >Assignee: Dennis Lundberg > Fix For: 2.0-beta-4 > > Attachments: file.patch > > > Please see [Common > Bugs|http://www.nabble.com/Common-Bugs-to14783703s177.html] for details. -- 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: (MRM-682) Archiva runs out of heap memory
Archiva runs out of heap memory --- Key: MRM-682 URL: http://jira.codehaus.org/browse/MRM-682 Project: Archiva Issue Type: Bug Affects Versions: 1.0.1, 1.0, 1.1 Reporter: James William Dumay Priority: Critical Attachments: m2proxy.20080204.tar.gz, maven.atlassian.com-log-20080203-0125.tgz, maven.atlassian.com-logs-20080203-0745.tgz Archiva appears to run out of heap memory frequently and the service crashes. 512mb should be more than enough. -- 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: (MRM-682) Archiva runs out of heap memory
[ http://jira.codehaus.org/browse/MRM-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James William Dumay updated MRM-682: Attachment: maven.atlassian.com-logs-20080203-0745.tgz maven.atlassian.com-log-20080203-0125.tgz > Archiva runs out of heap memory > --- > > Key: MRM-682 > URL: http://jira.codehaus.org/browse/MRM-682 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0, 1.0.1, 1.1 >Reporter: James William Dumay >Priority: Critical > Attachments: m2proxy.20080204.tar.gz, > maven.atlassian.com-log-20080203-0125.tgz, > maven.atlassian.com-logs-20080203-0745.tgz > > > Archiva appears to run out of heap memory frequently and the service crashes. > 512mb should be more than enough. -- 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: (SUREFIRE-449) In multi-module projects, all tests are run for each module in the module tree
[ http://jira.codehaus.org/browse/SUREFIRE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122513 ] Dan Fabulich commented on SUREFIRE-449: --- This is happening because I added @aggregator to surefire-report in order to fix SUREFIRE-268. I didn't really know what I was doing there, and I'm really not clear on why this causes the problem, but removing the line seems to help. I'll need to do more research to make sure this is safe. > In multi-module projects, all tests are run for each module in the module tree > -- > > Key: SUREFIRE-449 > URL: http://jira.codehaus.org/browse/SUREFIRE-449 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.4 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Priority: Blocker > Fix For: 2.4.2 > > Attachments: mvnexec.zip > > > In a multi-module project, since version 2.4, all tests of all modules are > run once for each module. This is *very* bad with many modules & many tests. > Attached is a sample project which contains a parent module and two child > modules. Each of the child modules contains one JUnit test. mvn clean site > runs each test three times (once for the parent and once for each of the two > submodules). When changing the surefire-report-plugin to version 2.3, each > test is run only once, as it is supposed to -- 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: (MCHANGES-97) Fix VTL errors
[
http://jira.codehaus.org/browse/MCHANGES-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHANGES-97.
---
Assignee: Dennis Lundberg
Resolution: Fixed
Fix Version/s: 2.0-beta-4
When I moved the configuration of the plugin to the element I managed
to reproduce the errors.
I have applied the patch. Thanks!
> Fix VTL errors
> --
>
> Key: MCHANGES-97
> URL: http://jira.codehaus.org/browse/MCHANGES-97
> Project: Maven 2.x Changes Plugin
> Issue Type: Improvement
> Components: announcement
>Affects Versions: 2.0-beta-3
>Reporter: Benjamin Bentmann
>Assignee: Dennis Lundberg
>Priority: Trivial
> Fix For: 2.0-beta-4
>
> Attachments: changes.xml, MCHANGES-97.zip, vtl-errors.patch
>
>
> When calling {{mvn changes:announcement-generate}} for the attached
> {{changes.xml}} VTL errors are logged due to the various null fields in the
> {{Action}} bean:
> {noformat}
> [INFO] [changes:announcement-generate]
> [INFO] Creating announcement file from changes.xml...
> [ERROR] RHS of #set statement is null. Context will not be modified.
> org/apache/maven/plugin/announcement/announcement.vm [line 30, column 1]
> [ERROR] RHS of #set statement is null. Context will not be modified.
> org/apache/maven/plugin/announcement/announcement.vm [line 31, column 1]
> [ERROR] Left side ($!issue) of '!=' operation has null value. Operation not
> possible. org/apache/maven/plugin/announcement/announcement.vm [line 32,
> column 27]
> [ERROR] Left side ($!dueto) of '!=' operation has null value. Operation not
> possible. org/apache/maven/plugin/announcement/announcement.vm [line 32,
> column 65]
> [ERROR] RHS of #set statement is null. Context will not be modified.
> org/apache/maven/plugin/announcement/announcement.vm [line 43, column 1]
> [ERROR] RHS of #set statement is null. Context will not be modified.
> org/apache/maven/plugin/announcement/announcement.vm [line 44, column 1]
> [ERROR] RHS of #set statement is null. Context will not be modified.
> org/apache/maven/plugin/announcement/announcement.vm [line 56, column 1]
> [ERROR] RHS of #set statement is null. Context will not be modified.
> org/apache/maven/plugin/announcement/announcement.vm [line 57, column 1]
> [ERROR] RHS of #set statement is null. Context will not be modified.
> org/apache/maven/plugin/announcement/announcement.vm [line 69, column 1]
> [ERROR] RHS of #set statement is null. Context will not be modified.
> org/apache/maven/plugin/announcement/announcement.vm [line 70, column 1]
> [INFO] File created...
> {noformat}
> The attached patch goes the hard way and improves the VTL template to check
> for nulls. Easier would be to establish an invariant for the bean properties
> stating that they are never null but maybe empty, i.e. change all the setters
> to convert null into an empty string.
--
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: (SUREFIRE-451) ManifestJarWriter should use java.util.jar.Manifest
[ http://jira.codehaus.org/browse/SUREFIRE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122501 ] Benjamin Bentmann commented on SUREFIRE-451: bq. so maybe there was a good reason for it...? The old story, where is documentation when one needs it ;-) ? bq. java.util.jar.Manifest creates a manifest with TWO final newlines Which is in conformance with the [Manifiest Specification|http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html#Manifest%20Specification] given the case, that the manifest contains no "individual-sections". > ManifestJarWriter should use java.util.jar.Manifest > --- > > Key: SUREFIRE-451 > URL: http://jira.codehaus.org/browse/SUREFIRE-451 > Project: Maven Surefire > Issue Type: Improvement > Components: process forking >Reporter: Dan Fabulich > Fix For: 2.x > > > ManifestJarWriter manages writing the manifest by hand, including wrapping > lines, etc. etc. This code was copied from plexus-archiver when we stopped > depending on plexus-archiver. > But AFAIK there's no reason to do that by hand; java.util.jar.Manifest can > take care of all of that for us. Still, it's creepy that they did all of > that work, so maybe there was a good reason for 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: (SUREFIRE-448) @Before, @After, @BeforeClass, @AfterClass do not seem to be functioning as of 2.4
[ http://jira.codehaus.org/browse/SUREFIRE-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-448: -- Attachment: surefire448.zip > @Before, @After, @BeforeClass, @AfterClass do not seem to be functioning as > of 2.4 > -- > > Key: SUREFIRE-448 > URL: http://jira.codehaus.org/browse/SUREFIRE-448 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.4 > Environment: Windows XP > maven 2.0.8 >Reporter: George Harp > Attachments: surefire448.zip, > WeatherMessageGeneratorCallableTest.java, > WeatherMessageGeneratorCallableTest.java > > > the attached class only outputs the testOne() message: -- 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: (SUREFIRE-448) @Before, @After, @BeforeClass, @AfterClass do not seem to be functioning as of 2.4
[ http://jira.codehaus.org/browse/SUREFIRE-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-448. - Resolution: Cannot Reproduce I can't reproduce this failure. I attached a sample minimal Maven project that attempts to reproduce the problem; when I run it, I see 5 distinct lines of error output. > @Before, @After, @BeforeClass, @AfterClass do not seem to be functioning as > of 2.4 > -- > > Key: SUREFIRE-448 > URL: http://jira.codehaus.org/browse/SUREFIRE-448 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.4 > Environment: Windows XP > maven 2.0.8 >Reporter: George Harp > Attachments: surefire448.zip, > WeatherMessageGeneratorCallableTest.java, > WeatherMessageGeneratorCallableTest.java > > > the attached class only outputs the testOne() message: -- 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: (SUREFIRE-445) Surefire-Booter Manifest not correct
[ http://jira.codehaus.org/browse/SUREFIRE-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-445. - Resolution: Fixed Fix Version/s: 2.4.2 > Surefire-Booter Manifest not correct > > > Key: SUREFIRE-445 > URL: http://jira.codehaus.org/browse/SUREFIRE-445 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Joerg Lauer > Fix For: 2.4.2 > > Attachments: sources.zip, surefire-booter-patch.diff > > > The manifest of the jar file created by the surefire-booter seems to be > written incorrectly. For one, it is missing the Manifest-Version, which > according to the spec is required. > I noticed because some tests were failing to be executed only for specific > users. I have so far been unable to find the exact problem. But after > patching the ManifestWriter to use the java.util.jar packages and the > ForkConfiguration and ManifestWriterTest to set the Manifest-Version it seems > to work fine. > I have attached the diff and the complete source code for the three patched > classes to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-451) ManifestJarWriter should use java.util.jar.Manifest
[ http://jira.codehaus.org/browse/SUREFIRE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-451: -- Fix Version/s: 2.x > ManifestJarWriter should use java.util.jar.Manifest > --- > > Key: SUREFIRE-451 > URL: http://jira.codehaus.org/browse/SUREFIRE-451 > Project: Maven Surefire > Issue Type: Improvement > Components: process forking >Reporter: Dan Fabulich > Fix For: 2.x > > > ManifestJarWriter manages writing the manifest by hand, including wrapping > lines, etc. etc. This code was copied from plexus-archiver when we stopped > depending on plexus-archiver. > But AFAIK there's no reason to do that by hand; java.util.jar.Manifest can > take care of all of that for us. Still, it's creepy that they did all of > that work, so maybe there was a good reason for 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] Commented: (SUREFIRE-451) ManifestJarWriter should use java.util.jar.Manifest
[ http://jira.codehaus.org/browse/SUREFIRE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122489 ] Dan Fabulich commented on SUREFIRE-451: --- Notably, I find that the difference between the two is that java.util.jar.Manifest creates a manifest with TWO final newlines; ManifestJarWriter as-is currently creates a manifest with just ONE final newline. > ManifestJarWriter should use java.util.jar.Manifest > --- > > Key: SUREFIRE-451 > URL: http://jira.codehaus.org/browse/SUREFIRE-451 > Project: Maven Surefire > Issue Type: Improvement > Components: process forking >Reporter: Dan Fabulich > > ManifestJarWriter manages writing the manifest by hand, including wrapping > lines, etc. etc. This code was copied from plexus-archiver when we stopped > depending on plexus-archiver. > But AFAIK there's no reason to do that by hand; java.util.jar.Manifest can > take care of all of that for us. Still, it's creepy that they did all of > that work, so maybe there was a good reason for 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] Closed: (MNG-2225) Classloader problem when adding jars to M2_HOME
[
http://jira.codehaus.org/browse/MNG-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-2225.
---
Assignee: John Casey
Resolution: Fixed
Fix Version/s: (was: 2.1)
2.1-alpha-1
You should be able to bring in any extras now using the build extension
mechanism, and only the extension components themselves will be added to the
core container realm. As long as these components implement interfaces already
present in the core realm, or (I suppose) represent themselves (i.e. they
aren't going to be referenced by some interface they bring along in their jar)
they should be available without problem.
Dependencies of these extension components are actually loaded into a
per-extension realm, and the ext. component classes are imported from that
realm into a project-specific realm that inherits from the core realm. This
means that the core realm is available, as are the ext. components. However,
the ext dependencies are isolated in their own realm, where only those ext
components have access to them.
There should be no need to modify the ${maven.home}/lib directory now, since
you can specify these extensions at the parent-pom level.
> Classloader problem when adding jars to M2_HOME
> ---
>
> Key: MNG-2225
> URL: http://jira.codehaus.org/browse/MNG-2225
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.4
>Reporter: Carlos Sanchez
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.1-alpha-1
>
> Attachments: testwagonscm.tgz
>
>
> Added these jars to M2_HOME/custom to allow using scm based remote repos
> http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-api/1.0-beta-2/maven-scm-api-1.0-beta-2.jar
> http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-manager-plexus/1.0-beta-2/maven-scm-manager-plexus-1.0-beta-2.jar
> http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-provider-svn/1.0-beta-2/maven-scm-provider-svn-1.0-beta-2.jar
> http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/wagon/wagon-scm/1.0-alpha-7-SNAPSHOT/wagon-scm-1.0-alpha-7-20060308.183410-3.jar
> bin/m2.conf
> main is org.apache.maven.cli.MavenCli from plexus.core.maven
> set maven.home default ${user.home}/m2
> [plexus.core]
> load ${maven.home}/core/*.jar
> [plexus.core.maven]
> load ${maven.home}/custom/*.jar
> load ${maven.home}/lib/*.jar
> When running "mvn install" and "mvn testwagonscm:test" in the attached test
> case you get a ClassCastException although the Class to assign to and the
> assigned one are the same. The problem seems to be that they come from
> different classloaders. This problem makes the project-info-report:scm goal
> fail.
--
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: (SUREFIRE-445) Surefire-Booter Manifest not correct
[ http://jira.codehaus.org/browse/SUREFIRE-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122487 ] Dan Fabulich commented on SUREFIRE-445: --- There's really two separate changes in here: one of them is to just add the Manifest-Version attribute, which is a one-line fix to ForkConfiguration. I've committed that line fix in revision 618784. The other change is to make ManifestJarWriter use java.util.jar.Manifest; that makes sense, but I find it a bit spooky, so I've filed it separately as bug SUREFIRE-451. If you find you're still having problems after just fixing the Manifest-Version, please comment on SUREFIRE-451. (Notably, I find that the difference between the two is that java.util.jar.Manifest creates a manifest with TWO final newlines; ManifestJarWriter as-is currently creates a manifest with just ONE final newline. > Surefire-Booter Manifest not correct > > > Key: SUREFIRE-445 > URL: http://jira.codehaus.org/browse/SUREFIRE-445 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Joerg Lauer > Attachments: sources.zip, surefire-booter-patch.diff > > > The manifest of the jar file created by the surefire-booter seems to be > written incorrectly. For one, it is missing the Manifest-Version, which > according to the spec is required. > I noticed because some tests were failing to be executed only for specific > users. I have so far been unable to find the exact problem. But after > patching the ManifestWriter to use the java.util.jar packages and the > ForkConfiguration and ManifestWriterTest to set the Manifest-Version it seems > to work fine. > I have attached the diff and the complete source code for the three patched > classes to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-451) ManifestJarWriter should use java.util.jar.Manifest
ManifestJarWriter should use java.util.jar.Manifest --- Key: SUREFIRE-451 URL: http://jira.codehaus.org/browse/SUREFIRE-451 Project: Maven Surefire Issue Type: Improvement Components: process forking Reporter: Dan Fabulich ManifestJarWriter manages writing the manifest by hand, including wrapping lines, etc. etc. This code was copied from plexus-archiver when we stopped depending on plexus-archiver. But AFAIK there's no reason to do that by hand; java.util.jar.Manifest can take care of all of that for us. Still, it's creepy that they did all of that work, so maybe there was a good reason for 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] Closed: (MNG-3068) Build extensions fail to load if not available locally and remote repo is defined in the same POM where the extension is defined
[
http://jira.codehaus.org/browse/MNG-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3068.
---
Resolution: Fixed
> Build extensions fail to load if not available locally and remote repo is
> defined in the same POM where the extension is defined
>
>
> Key: MNG-3068
> URL: http://jira.codehaus.org/browse/MNG-3068
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.1
>Reporter: Vincent Massol
>Assignee: John Casey
> Fix For: 2.1
>
>
> * If you define the remote repo in settings.xml it works
> * If you define it in the pom.xml file it doesn't work
> For example, this fails if xwiki-build-xar-handlers isn't available in the
> local repo:
> {noformat}
>
>
>
> com.xpn.xwiki.platform
> xwiki-build-xar-handlers
> 1.0-SNAPSHOT
>
>
>
>
>
> xwiki
> XWiki Maven2 Remote Repository
> http://maven.xwiki.org
>
> true
>
>
> true
>
>
>
>
> {noformat}
--
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: (MNG-1493) Support in multiproject environment modules with different named POMs
[ http://jira.codehaus.org/browse/MNG-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-1493. --- Resolution: Fixed applied patch, added integration test to verify the fix. Thanks. > Support in multiproject environment modules with different named POMs > - > > Key: MNG-1493 > URL: http://jira.codehaus.org/browse/MNG-1493 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0 >Reporter: Joerg Schaible >Assignee: John Casey >Priority: Minor > Fix For: 2.1 > > Attachments: DefaultMaven.diff > > > Command line version of Maven 2 supports POMs with a different name using the > -f option. Unfortunately such POMs cannot be used as modules, since the value > of the module tag is defined as a directory to another pom.xml instead of a > pathname to another POM. Only if the value is not already an existing file > the value should be treated as directory with a present pom.xml file. Similar > situation applies to the relativePath element of the parent tag. > This makes the generation of different artifacts from the same sources (with > some modifications) much more easy. Currently you will have to put the POMs > in separate directories and modify the sourec location into another module. -- 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: (DOXIA-125) Twiki module uses different HTML markup conventions to the other modules (e.g. apt)
[
http://jira.codehaus.org/browse/DOXIA-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Falkenberg updated DOXIA-125:
-
Attachment: site-test.zip
I don't experience this issue. There are differences in the html generated by
apt and twiki (as can be seen in the small test-project attached) but to me it
seems like it only has to do with the nesting of sections. While apt nests
sections like this:
{code:xml}
Section title
Sub-section title
...
{code}
the Twiki-module does not (but it does insert headers):
{code:xml}
Twiki Java Parser
Features
...
{code}
> Twiki module uses different HTML markup conventions to the other modules
> (e.g. apt)
> ---
>
> Key: DOXIA-125
> URL: http://jira.codehaus.org/browse/DOXIA-125
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Twiki
>Affects Versions: 1.0-alpha-9
>Reporter: Dave Syer
> Fix For: 1.0-beta-1
>
> Attachments: site-test.zip
>
>
> There are some inconsistencies between the way that the HTML is rendered from
> twiki and the other doxia formats - e.g. it uses
> instead of - so you need a different css to get the same result.
--
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: (MNG-1493) Support in multiproject environment modules with different named POMs
[ http://jira.codehaus.org/browse/MNG-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-1493: Assignee: John Casey (was: Milos Kleint) > Support in multiproject environment modules with different named POMs > - > > Key: MNG-1493 > URL: http://jira.codehaus.org/browse/MNG-1493 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0 >Reporter: Joerg Schaible >Assignee: John Casey >Priority: Minor > Fix For: 2.1 > > Attachments: DefaultMaven.diff > > > Command line version of Maven 2 supports POMs with a different name using the > -f option. Unfortunately such POMs cannot be used as modules, since the value > of the module tag is defined as a directory to another pom.xml instead of a > pathname to another POM. Only if the value is not already an existing file > the value should be treated as directory with a present pom.xml file. Similar > situation applies to the relativePath element of the parent tag. > This makes the generation of different artifacts from the same sources (with > some modifications) much more easy. Currently you will have to put the POMs > in separate directories and modify the sourec location into another module. -- 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: (MEAR-84) Ability to interpolate filenamemapping using regex.
[
http://jira.codehaus.org/browse/MEAR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tuomas Kiviaho updated MEAR-84:
---
Attachment: regex.patch
regex.patch contains modified test cases from EAR file name mapping and a
customized org.apache.maven.plugin.assembly.utils.AssemblyFormatUtilsTest.
There are references to maven-assembly-plugin which need to be solved.
Conversion from AssemblyFormatUtilsTest as RegexFileNameMappingTest is
basically just removal of project and model features that do not apply to
FileNameMapping since only the artifact is available.
With this patch I was already able to pull a static regex file name mapping...
${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}
...which distinguishes version from base version when snapshots are used
because current implementations are based on ${artifact.file.name} and they
both lose unique versions because file name is based on base version.
> Ability to interpolate filenamemapping using regex.
> ---
>
> Key: MEAR-84
> URL: http://jira.codehaus.org/browse/MEAR-84
> Project: Maven 2.x Ear Plugin
> Issue Type: Wish
>Reporter: Tuomas Kiviaho
>Priority: Minor
> Attachments: regex.patch
>
>
> I was trying to have an impact how artifact files would be mapped based on
> previous knowledge about assembly plugin but noticed that there's a
> fundamental difference in implementations.
> Both the 'stardard' and 'full' file name mapping of ear plugin could have
> been implemented using
> org.codehaus.plexus.util.interpolation.RegexBasedInterpolator quite
> identically to
> org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.evaluateFileNameMapping
> used in assembly plugin. The class name based pluggability is only available
> at EAR side.
> Regular expressions of the interpolator have a distinctive pattern separating
> them from classes and predefined mappings making it backwards compatible to
> extend the FileNameMappingFactory to match regular expressions.
--
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: (SUREFIRE-446) Surefire fails to capture TestNG results when forkMode=always
[
http://jira.codehaus.org/browse/SUREFIRE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich updated SUREFIRE-446:
--
Fix Version/s: 2.4.2
Repro'd.
> Surefire fails to capture TestNG results when forkMode=always
> -
>
> Key: SUREFIRE-446
> URL: http://jira.codehaus.org/browse/SUREFIRE-446
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.4
> Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP
>Reporter: Benjamin Bentmann
> Fix For: 2.4.2
>
> Attachments: testng-fork-mode-it.patch
>
>
> The interplay between {{surefire.Surefire}} and
> {{testng.TestNGDirectoryTestSuite}} does not properly notify the
> ReportManager such that it reports 0 executed tests after the end of the day.
> IT to reproduce attached.
> Also confirmed against 2.5-SNAPSHOT.
--
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: (SUREFIRE-449) In multi-module projects, all tests are run for each module in the module tree
[ http://jira.codehaus.org/browse/SUREFIRE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-449: -- Fix Version/s: 2.4.2 Thanks for filing this bug; I noticed it too but thought it was just SUREFIRE-257 (which is really a bug in core). But I'm able to reproduce your findings that this wasn't a problem in 2.3, so I'll happily take a crack at it. > In multi-module projects, all tests are run for each module in the module tree > -- > > Key: SUREFIRE-449 > URL: http://jira.codehaus.org/browse/SUREFIRE-449 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.4 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Priority: Blocker > Fix For: 2.4.2 > > Attachments: mvnexec.zip > > > In a multi-module project, since version 2.4, all tests of all modules are > run once for each module. This is *very* bad with many modules & many tests. > Attached is a sample project which contains a parent module and two child > modules. Each of the child modules contains one JUnit test. mvn clean site > runs each test three times (once for the parent and once for each of the two > submodules). When changing the surefire-report-plugin to version 2.3, each > test is run only once, as it is supposed to -- 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: (DOXIA-213) There is no way to include images using relative urls
[ http://jira.codehaus.org/browse/DOXIA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122464 ] Gabriel Falkenberg commented on DOXIA-213: -- It's a duplicate of DOXIA-212. I got an error on the first submit so I resubmitted, and got the same error, but the issues were both registered despite the errors. > There is no way to include images using relative urls > - > > Key: DOXIA-213 > URL: http://jira.codehaus.org/browse/DOXIA-213 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Twiki >Affects Versions: 1.0-beta-1 >Reporter: Gabriel Falkenberg > Attachments: HTML_Image_Tag_support.patch > > > There is currently no way to have relative images in twiki-format. Reading > the twiki docs suggests that this should be implemented by adding > funtionality to parse ordinary img-tags (which could then be both relative > and absolute). For XHTML-output this would be something we get for free by > fixing DOXIA-153 but that wouldn't use sink.figure so it would probably not > work for PDF-output (please correct me if I'm wrong). -- 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: (SUREFIRE-450) Verification test failure: Invalid mavenProfile entry. Missing one or more fields: {localRepository}
[
http://jira.codehaus.org/browse/SUREFIRE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122463
]
Dan Fabulich commented on SUREFIRE-450:
---
Notably, this stacktrace indicates that it's having problems reading your
settings.xml file. Try using a clean settings.xml file; if that's not
possible, please submit a minimal settings.xml file that reproduces the problem.
> Verification test failure: Invalid mavenProfile entry. Missing one or more
> fields: {localRepository}
>
>
> Key: SUREFIRE-450
> URL: http://jira.codehaus.org/browse/SUREFIRE-450
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.x
> Environment: java version "1.5.0_13"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
> Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)
>Reporter: Graham Leggett
>
> All tests in surefire-integration-tests fail like so:
> testTwoTestCases(org.apache.maven.surefire.its.TwoTestCasesTest) Time
> elapsed: 0.011 sec <<< ERROR!
> org.apache.maven.it.VerificationException: org.xml.sax.SAXException: Invalid
> mavenProfile entry. Missing one or more fields: {localRepository}.
> at
> org.apache.maven.it.Verifier$UserModelReader.parse(Verifier.java:1269)
> at org.apache.maven.it.Verifier.retrieveLocalRepo(Verifier.java:557)
> at org.apache.maven.it.Verifier.findLocalRepo(Verifier.java:1178)
> at org.apache.maven.it.Verifier.(Verifier.java:101)
> at org.apache.maven.it.Verifier.(Verifier.java:80)
> at org.apache.maven.it.Verifier.(Verifier.java:107)
> at
> org.apache.maven.surefire.its.TwoTestCasesTest.testTwoTestCases(TwoTestCasesTest.java:27)
> It looks like the localRepository setting is missing from a pom or config
> file somewhere.
--
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: (SUREFIRE-450) Verification test failure: Invalid mavenProfile entry. Missing one or more fields: {localRepository}
[
http://jira.codehaus.org/browse/SUREFIRE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-450.
-
Resolution: Cannot Reproduce
I don't reproduce this. What version of Maven are you using? What OS? I'm
running:
Maven version: 2.0.8
Java version: 1.5.0_12
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> Verification test failure: Invalid mavenProfile entry. Missing one or more
> fields: {localRepository}
>
>
> Key: SUREFIRE-450
> URL: http://jira.codehaus.org/browse/SUREFIRE-450
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.x
> Environment: java version "1.5.0_13"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
> Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)
>Reporter: Graham Leggett
>
> All tests in surefire-integration-tests fail like so:
> testTwoTestCases(org.apache.maven.surefire.its.TwoTestCasesTest) Time
> elapsed: 0.011 sec <<< ERROR!
> org.apache.maven.it.VerificationException: org.xml.sax.SAXException: Invalid
> mavenProfile entry. Missing one or more fields: {localRepository}.
> at
> org.apache.maven.it.Verifier$UserModelReader.parse(Verifier.java:1269)
> at org.apache.maven.it.Verifier.retrieveLocalRepo(Verifier.java:557)
> at org.apache.maven.it.Verifier.findLocalRepo(Verifier.java:1178)
> at org.apache.maven.it.Verifier.(Verifier.java:101)
> at org.apache.maven.it.Verifier.(Verifier.java:80)
> at org.apache.maven.it.Verifier.(Verifier.java:107)
> at
> org.apache.maven.surefire.its.TwoTestCasesTest.testTwoTestCases(TwoTestCasesTest.java:27)
> It looks like the localRepository setting is missing from a pom or config
> file somewhere.
--
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: (MNG-3331) Normalize paths to sub modules
[
http://jira.codehaus.org/browse/MNG-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3331.
---
Resolution: Fixed
fair enough. good catch.
> Normalize paths to sub modules
> --
>
> Key: MNG-3331
> URL: http://jira.codehaus.org/browse/MNG-3331
> Project: Maven 2
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
>Assignee: John Casey
> Fix For: 2.0.9, 2.1-alpha-1
>
> Attachments: normalized-module-file.patch
>
>
> When collecting the sub modules during a reactor build, the path to the
> module POMs should always be normalized. Currently, this happens only on a
> Windows platform via File.getCanonicalFile(). The attached patch adds
> normalization (but not canonicalization) for other platforms, too.
> The motivation: Consider a multi module project with the following directory
> structure:
> project/
> project-parent/
> project-module/
> such that the parent POM in project-parent will contain
>../project-module
> to reference the sub module. Simple string/path concatenation will therefore
> deliver a path like
>{SNIP}/project-parent/../project-module
> for the sub module. Having
> {SNIP}/project-module
> instead is surely better, and may it be just for nice log output.
> However, certain plugins/tools try to detect symlinks by comparing the
> canonicalized path with the absolute path of a file. While users of
> DirectoryScanner are usually fine because this class always canonicalizes the
> base directory before the check, code that does not know about a base
> directory but simply gets a single file will erroneously detect a symlink
> because ".." gets removed during canonicalization.
> This actually happens with the CpdReport of the maven-pmd-plugin. See
> [CPD.addFile(int,
> File)|http://pmd.svn.sourceforge.net/viewvc/pmd/trunk/pmd/src/net/sourceforge/pmd/cpd/CPD.java?view=markup]
> for the cause, i.e. the code near line 97 where it prints "Skipping {file}
> since it appears to be a symlink".
--
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: (MNG-3331) Normalize paths to sub modules
[
http://jira.codehaus.org/browse/MNG-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann reopened MNG-3331:
My patch intentionally performed {{URI.normalize()}} for Non-Windows and ONLY
for Non-Windows OS. Your recent commit r618708 now calls this method in all
cases which is
# unnecessary on a Windows platform since you already call
{{[File.getCanonicalFile()|http://java.sun.com/javase/6/docs/api/java/io/File.html#getCanonicalPath()]}}
here and is
# dangerous on a Windows platform since it destroys UNC paths (see [Sun Bug
4723726|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4723726]
> Normalize paths to sub modules
> --
>
> Key: MNG-3331
> URL: http://jira.codehaus.org/browse/MNG-3331
> Project: Maven 2
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
>Assignee: John Casey
> Fix For: 2.0.9, 2.1-alpha-1
>
> Attachments: normalized-module-file.patch
>
>
> When collecting the sub modules during a reactor build, the path to the
> module POMs should always be normalized. Currently, this happens only on a
> Windows platform via File.getCanonicalFile(). The attached patch adds
> normalization (but not canonicalization) for other platforms, too.
> The motivation: Consider a multi module project with the following directory
> structure:
> project/
> project-parent/
> project-module/
> such that the parent POM in project-parent will contain
>../project-module
> to reference the sub module. Simple string/path concatenation will therefore
> deliver a path like
>{SNIP}/project-parent/../project-module
> for the sub module. Having
> {SNIP}/project-module
> instead is surely better, and may it be just for nice log output.
> However, certain plugins/tools try to detect symlinks by comparing the
> canonicalized path with the absolute path of a file. While users of
> DirectoryScanner are usually fine because this class always canonicalizes the
> base directory before the check, code that does not know about a base
> directory but simply gets a single file will erroneously detect a symlink
> because ".." gets removed during canonicalization.
> This actually happens with the CpdReport of the maven-pmd-plugin. See
> [CPD.addFile(int,
> File)|http://pmd.svn.sourceforge.net/viewvc/pmd/trunk/pmd/src/net/sourceforge/pmd/cpd/CPD.java?view=markup]
> for the cause, i.e. the code near line 97 where it prints "Skipping {file}
> since it appears to be a symlink".
--
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: (DOXIA-213) There is no way to include images using relative urls
[ http://jira.codehaus.org/browse/DOXIA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl reopened DOXIA-213: - Did you mean to close this issue? Which issue does it duplicate? > There is no way to include images using relative urls > - > > Key: DOXIA-213 > URL: http://jira.codehaus.org/browse/DOXIA-213 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Twiki >Affects Versions: 1.0-beta-1 >Reporter: Gabriel Falkenberg > Attachments: HTML_Image_Tag_support.patch > > > There is currently no way to have relative images in twiki-format. Reading > the twiki docs suggests that this should be implemented by adding > funtionality to parse ordinary img-tags (which could then be both relative > and absolute). For XHTML-output this would be something we get for free by > fixing DOXIA-153 but that wouldn't use sink.figure so it would probably not > work for PDF-output (please correct me if I'm wrong). -- 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: (MNG-3331) Normalize paths to sub modules
[
http://jira.codehaus.org/browse/MNG-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3331.
---
Resolution: Fixed
Patch applied. Thanks!. Also, added integration tests to make sure that module
paths (with spaces and with relative directory references) don't cause problems
with basic maven functionality.
> Normalize paths to sub modules
> --
>
> Key: MNG-3331
> URL: http://jira.codehaus.org/browse/MNG-3331
> Project: Maven 2
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
>Assignee: John Casey
> Fix For: 2.0.9, 2.1-alpha-1
>
> Attachments: normalized-module-file.patch
>
>
> When collecting the sub modules during a reactor build, the path to the
> module POMs should always be normalized. Currently, this happens only on a
> Windows platform via File.getCanonicalFile(). The attached patch adds
> normalization (but not canonicalization) for other platforms, too.
> The motivation: Consider a multi module project with the following directory
> structure:
> project/
> project-parent/
> project-module/
> such that the parent POM in project-parent will contain
>../project-module
> to reference the sub module. Simple string/path concatenation will therefore
> deliver a path like
>{SNIP}/project-parent/../project-module
> for the sub module. Having
> {SNIP}/project-module
> instead is surely better, and may it be just for nice log output.
> However, certain plugins/tools try to detect symlinks by comparing the
> canonicalized path with the absolute path of a file. While users of
> DirectoryScanner are usually fine because this class always canonicalizes the
> base directory before the check, code that does not know about a base
> directory but simply gets a single file will erroneously detect a symlink
> because ".." gets removed during canonicalization.
> This actually happens with the CpdReport of the maven-pmd-plugin. See
> [CPD.addFile(int,
> File)|http://pmd.svn.sourceforge.net/viewvc/pmd/trunk/pmd/src/net/sourceforge/pmd/cpd/CPD.java?view=markup]
> for the cause, i.e. the code near line 97 where it prints "Skipping {file}
> since it appears to be a symlink".
--
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: (MNG-3331) Normalize paths to sub modules
[
http://jira.codehaus.org/browse/MNG-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-3331:
Assignee: John Casey (was: Milos Kleint)
> Normalize paths to sub modules
> --
>
> Key: MNG-3331
> URL: http://jira.codehaus.org/browse/MNG-3331
> Project: Maven 2
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
>Assignee: John Casey
> Fix For: 2.0.9, 2.1-alpha-1
>
> Attachments: normalized-module-file.patch
>
>
> When collecting the sub modules during a reactor build, the path to the
> module POMs should always be normalized. Currently, this happens only on a
> Windows platform via File.getCanonicalFile(). The attached patch adds
> normalization (but not canonicalization) for other platforms, too.
> The motivation: Consider a multi module project with the following directory
> structure:
> project/
> project-parent/
> project-module/
> such that the parent POM in project-parent will contain
>../project-module
> to reference the sub module. Simple string/path concatenation will therefore
> deliver a path like
>{SNIP}/project-parent/../project-module
> for the sub module. Having
> {SNIP}/project-module
> instead is surely better, and may it be just for nice log output.
> However, certain plugins/tools try to detect symlinks by comparing the
> canonicalized path with the absolute path of a file. While users of
> DirectoryScanner are usually fine because this class always canonicalizes the
> base directory before the check, code that does not know about a base
> directory but simply gets a single file will erroneously detect a symlink
> because ".." gets removed during canonicalization.
> This actually happens with the CpdReport of the maven-pmd-plugin. See
> [CPD.addFile(int,
> File)|http://pmd.svn.sourceforge.net/viewvc/pmd/trunk/pmd/src/net/sourceforge/pmd/cpd/CPD.java?view=markup]
> for the cause, i.e. the code near line 97 where it prints "Skipping {file}
> since it appears to be a symlink".
--
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: (MNG-3221) Infinite loop in DefaultLifecycleExecutor
[
http://jira.codehaus.org/browse/MNG-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-3221:
This patch looks like it will prevent any @execute phase="xxx" from running,
since the check is a truism...targetPhase is set to
mojoDescriptor.getExecutePhase(), then later, the forked execution won't run if
( mojoDescriptor.getExecutionPhase().equals( targetPhase) )...in other words,
nothing modifies targetPhase, and the only way the forked phase will run is if
targetPhase is modified...
Can you provide some tests that display this problem broken, then fixed with
the patch?
> Infinite loop in DefaultLifecycleExecutor
> -
>
> Key: MNG-3221
> URL: http://jira.codehaus.org/browse/MNG-3221
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.7
>Reporter: Vincent Siveton
> Fix For: 2.0.9
>
> Attachments: infinite-loop.diff
>
>
> Defining this following report:
> {code:title=MyReport.java|borderStyle=solid}
> /**
> * @goal mygoal
> * @execute phase="site"
> */
> public class MyReport
> extends AbstractMavenReport{}
> {code}
> I got this following loop:
> {noformat}
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(
[jira] Created: (DOXIA-213) There is no way to include images using relative urls
There is no way to include images using relative urls - Key: DOXIA-213 URL: http://jira.codehaus.org/browse/DOXIA-213 Project: Maven Doxia Issue Type: Bug Components: Module - Twiki Affects Versions: 1.0-beta-1 Reporter: Gabriel Falkenberg Attachments: HTML_Image_Tag_support.patch There is currently no way to have relative images in twiki-format. Reading the twiki docs suggests that this should be implemented by adding funtionality to parse ordinary img-tags (which could then be both relative and absolute). For XHTML-output this would be something we get for free by fixing DOXIA-153 but that wouldn't use sink.figure so it would probably not work for PDF-output (please correct me if I'm wrong). -- 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: (DOXIA-213) There is no way to include images using relative urls
[ http://jira.codehaus.org/browse/DOXIA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Falkenberg closed DOXIA-213. Resolution: Duplicate Got: --- 404 No view for result [error] exists for action [ViewIssue] /browse/DOXIA-213 was not found on this server. Resin Professional 3.0.23 (built Mon, 22 Jan 2007 02:25:17 PST) --- But the issue was created anyway > There is no way to include images using relative urls > - > > Key: DOXIA-213 > URL: http://jira.codehaus.org/browse/DOXIA-213 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Twiki >Affects Versions: 1.0-beta-1 >Reporter: Gabriel Falkenberg > Attachments: HTML_Image_Tag_support.patch > > > There is currently no way to have relative images in twiki-format. Reading > the twiki docs suggests that this should be implemented by adding > funtionality to parse ordinary img-tags (which could then be both relative > and absolute). For XHTML-output this would be something we get for free by > fixing DOXIA-153 but that wouldn't use sink.figure so it would probably not > work for PDF-output (please correct me if I'm wrong). -- 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: (DOXIA-212) There is no way to include images using relative urls
There is no way to include images using relative urls - Key: DOXIA-212 URL: http://jira.codehaus.org/browse/DOXIA-212 Project: Maven Doxia Issue Type: Bug Components: Module - Twiki Affects Versions: 1.0-beta-1 Reporter: Gabriel Falkenberg Attachments: HTML_Image_Tag_support.patch There is currently no way to have relative images in twiki-format. Reading the twiki docs suggests that this should be implemented by adding funtionality to parse ordinary img-tags (which could then be both relative and absolute). For XHTML-output this would be something we get for free by fixing DOXIA-153 but that wouldn't use sink.figure so it would probably not work for PDF-output (please correct me if I'm wrong). -- 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: (MASSEMBLY-279) Small improvement to error messages
[ http://jira.codehaus.org/browse/MASSEMBLY-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-279: - Assignee: John Casey Remaining Estimate: 0 minutes Original Estimate: 0 minutes > Small improvement to error messages > --- > > Key: MASSEMBLY-279 > URL: http://jira.codehaus.org/browse/MASSEMBLY-279 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 >Reporter: Paul Gier >Assignee: John Casey > Fix For: 2.2-beta-2 > > Attachments: maven-assembly-plugin-error-messages.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Currently if there is an exception thrown, for example with an empty archive, > the message does not specify which assembly is causing the problem. > The attached patch includes the assemblyId in the error message. -- 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: (MASSEMBLY-279) Small improvement to error messages
[ http://jira.codehaus.org/browse/MASSEMBLY-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-279. Resolution: Fixed Applied, thanks! > Small improvement to error messages > --- > > Key: MASSEMBLY-279 > URL: http://jira.codehaus.org/browse/MASSEMBLY-279 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 >Reporter: Paul Gier >Assignee: John Casey > Fix For: 2.2-beta-2 > > Attachments: maven-assembly-plugin-error-messages.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Currently if there is an exception thrown, for example with an empty archive, > the message does not specify which assembly is causing the problem. > The attached patch includes the assemblyId in the error message. -- 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-1925) please upload DynamicJasper 2.0.5
please upload DynamicJasper 2.0.5 - Key: MAVENUPLOAD-1925 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1925 Project: maven-upload-requests Issue Type: Wish Reporter: Juan Manuel Alvarez http://dynamicjasper.sourceforge.net/downloads/DynamicJasper-2.0.5-bundle.jar http://dynamicjasper.sourceforge.net/ http://dynamicjasper.sourceforge.net/team-list.html 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: (MASSEMBLY-261) Use plexus-archiver 1.0-alpha-10
[ http://jira.codehaus.org/browse/MASSEMBLY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-261. Resolution: Fixed > Use plexus-archiver 1.0-alpha-10 > > > Key: MASSEMBLY-261 > URL: http://jira.codehaus.org/browse/MASSEMBLY-261 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 >Reporter: Jochen Wiedmann >Assignee: John Casey > Fix For: 2.2-beta-2 > > Attachments: maven-assembly-plugin-resources.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Quoting PLXCOMP-88: > The handling of ArchivedFileSet is currently extremely slow: The archive is > extracted to a temporary directory where the usual archiver logic is being > applied. > A considerable speed improvement could be achieved by replacing the FileSet > internally with the PlexusIoResourceCollection. This would allow to select > files (aka resources) within the archive file. > Additionally, this setup would allow to include content filters and file name > mappers (see the respective Ant types), thus modifying the archive contents > on the fly. -- 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: (MASSEMBLY-261) Use plexus-archiver 1.0-alpha-10
[ http://jira.codehaus.org/browse/MASSEMBLY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-261: - Assignee: John Casey Description: Quoting PLXCOMP-88: The handling of ArchivedFileSet is currently extremely slow: The archive is extracted to a temporary directory where the usual archiver logic is being applied. A considerable speed improvement could be achieved by replacing the FileSet internally with the PlexusIoResourceCollection. This would allow to select files (aka resources) within the archive file. Additionally, this setup would allow to include content filters and file name mappers (see the respective Ant types), thus modifying the archive contents on the fly. was: Quoting PLXCOMP-88: The handling of ArchivedFileSet is currently extremely slow: The archive is extracted to a temporary directory where the usual archiver logic is being applied. A considerable speed improvement could be achieved by replacing the FileSet internally with the PlexusIoResourceCollection. This would allow to select files (aka resources) within the archive file. Additionally, this setup would allow to include content filters and file name mappers (see the respective Ant types), thus modifying the archive contents on the fly. Remaining Estimate: 0 minutes Original Estimate: 0 minutes > Use plexus-archiver 1.0-alpha-10 > > > Key: MASSEMBLY-261 > URL: http://jira.codehaus.org/browse/MASSEMBLY-261 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 >Reporter: Jochen Wiedmann >Assignee: John Casey > Fix For: 2.2-beta-2 > > Attachments: maven-assembly-plugin-resources.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Quoting PLXCOMP-88: > The handling of ArchivedFileSet is currently extremely slow: The archive is > extracted to a temporary directory where the usual archiver logic is being > applied. > A considerable speed improvement could be achieved by replacing the FileSet > internally with the PlexusIoResourceCollection. This would allow to select > files (aka resources) within the archive file. > Additionally, this setup would allow to include content filters and file name > mappers (see the respective Ant types), thus modifying the archive contents > on the fly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3382) Upload and download terminal output is not suitable for logging to a text file
[ http://jira.codehaus.org/browse/MNG-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122400 ] Matt Read commented on MNG-3382: Brilliant, thanks, apologies for not RTFM. > Upload and download terminal output is not suitable for logging to a text file > -- > > Key: MNG-3382 > URL: http://jira.codehaus.org/browse/MNG-3382 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.8 >Reporter: Matt Read >Assignee: Trygve Laugstol > > We are using Maven with Bamboo on Windows, the page used to display the build > log performs very badly when rendering large logs and we've discovered that > the single biggest contributor is the thousands of lines that record progress > on uploading and downloading dependencies. E.g. > 04-Feb-2008 14:50:22 592/2310K > 04-Feb-2008 14:50:22 596/2310K > 04-Feb-2008 14:50:22 600/2310K > 04-Feb-2008 14:50:22 604/2310K > 04-Feb-2008 14:50:22 608/2310K > 04-Feb-2008 14:50:22 612/2310K > 04-Feb-2008 14:50:22 616/2310K > 04-Feb-2008 14:50:22 620/2310K > 04-Feb-2008 14:50:22 624/2310K > What's a sensible way to switch this off or change the increment for each > line? If someone can suggest an approach and area of the code to focus on > I'll try to supply a patch. -- 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: (DOXIA-211) Linkcheck: ability to run more than one Validator
[ http://jira.codehaus.org/browse/DOXIA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl moved MSANDBOX-39 to DOXIA-211: - Component/s: (was: doxia) Doxia Tools Key: DOXIA-211 (was: MSANDBOX-39) Project: Maven Doxia (was: Maven 2.x Sandbox) > Linkcheck: ability to run more than one Validator > - > > Key: DOXIA-211 > URL: http://jira.codehaus.org/browse/DOXIA-211 > Project: Maven Doxia > Issue Type: Improvement > Components: Doxia Tools >Reporter: Lukas Theussl > > Currently every link is checked by exactly one Validator, eg > FileLinkValidator or HTTPLinkValidator. In a multiproject build some links > never exist locally but only after deployment. The basedir solution is not > ideal because it forces one to use absolute links. It would be better to be > able to (optionally) run other validators if a specific one fails. > See the discussion: http://www.mail-archive.com/[EMAIL > PROTECTED]/msg69705.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: (MJAR-66) Maven fails to include generated resources
[ http://jira.codehaus.org/browse/MJAR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122392 ] nodens2k edited comment on MJAR-66 at 2/5/08 7:26 AM: -- I am experiencing the same problem. AxisTools does add the resources. Its execute() method ends with: projectHelper.addResource( project, outputDirectory.getAbsolutePath(), Collections.singletonList( "**/*.wsdl" ), Collections.EMPTY_LIST ); I have added some logs in a local modification of AxisTools. The plugin is executed, and after the above line, project.getResources() includes this new set. However, the jar plugin seems to not include any resource outside of target/classes. Maybe the following will be of help if I execute: mvn clean compile axistools:java2wsdl package the resulting jar includes the wsdl file. If I just do: mvn clean package no wsdl is included into the jar. I have found two workarounds: 1. The one described above. Only useful if you have control over the command line 2. Set the axis-tools output directory to "target/classes" was (Author: nodens2k): I am experiencing the same problem. AxisTools does add the resources. Its execute() method ends with: projectHelper.addResource( project, outputDirectory.getAbsolutePath(), Collections.singletonList( "**/*.wsdl" ), Collections.EMPTY_LIST ); I have added some logs in a local modification of AxisTools. The plugin is executed, and after the above line, project.getResources() includes this new set. However, the jar plugin seems to not include any resource outside of target/classes. Maybe the following is a clue: if I execute: mvn clean compile axistools:java2wsdl package the resulting jar includes the wsdl file. If I just do: mvn package the jar does not have any wsdl file. > Maven fails to include generated resources > -- > > Key: MJAR-66 > URL: http://jira.codehaus.org/browse/MJAR-66 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Linux (not tested on windows) >Reporter: Leszek Ciesielski > Attachments: ConfigurationServerAPI.tar.gz > > > My project is generating a wsdl with axistools plugin. When maven is run with > mvn clean install (or after a checkout), the wsdl is not packaged into the > jar, although it is present when the jar is generated and included in > resources. On second run (mvn install) the wsdl file, is, as expected, > included. > A test project showing this behaviour 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] Created: (MRM-681) Unable to index test-sources.jar for given artifacts
Unable to index test-sources.jar for given artifacts Key: MRM-681 URL: http://jira.codehaus.org/browse/MRM-681 Project: Archiva Issue Type: Bug Components: indexing Affects Versions: 1.0.1 Environment: Windows XP SP2 / Running in Tomcat 6.0.14 Reporter: Jon SlinnHawkins Copied the existing artifacts from a Proximity repository. Rescanned the repository all other artifacts, jars, poms, src-jars have been indexed correctly. test-source.jars however throw the following exception 218109 [pool-2-thread-1] ERROR org.apache.maven.archiva.repository.scanner.RepositoryScanner:default - Consumer [metadata-updater] had an error when processing file [C:\apps\Tomcat 6.0\data\repositories\snapshots\com\elsevier\elslon\common\components\ecom\eCommerce\0.0.1-SNAPSHOT\eCommerce-0.0.1-20070219.171202-34-test-sources.jar]: Unable to convert to artifact reference: com\elsevier\elslon\common\components\ecom\eCommerce\0.0.1-SNAPSHOT\eCommerce-0.0.1-20070219.171202-34-test-sources.jar org.apache.maven.archiva.consumers.ConsumerException: Unable to convert to artifact reference: com\elsevier\elslon\common\components\ecom\eCommerce\0.0.1-SNAPSHOT\eCommerce-0.0.1-20070219.171202-34-test-sources.jar at org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.processFile(MetadataUpdaterConsumer.java:167) at org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessFileClosure.execute(ConsumerProcessFileClosure.java:57) at org.apache.commons.collections.functors.IfClosure.execute(IfClosure.java:117) at org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388) at org.apache.maven.archiva.repository.scanner.RepositoryScannerInstance.directoryWalkStep(RepositoryScannerInstance.java:138) at org.codehaus.plexus.util.DirectoryWalker.fireStep(DirectoryWalker.java:173) at org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:391) at org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385) at org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385) at org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385) at org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385) at org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385) at org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385) at org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385) at org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385) at org.codehaus.plexus.util.DirectoryWalker.scan(DirectoryWalker.java:344) at org.apache.maven.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultRepositoryScanner.java:120) at org.apache.maven.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultRepositoryScanner.java:64) at org.apache.maven.archiva.scheduled.executors.ArchivaRepositoryScanningTaskExecutor.executeTask(ArchivaRepositoryScanningTaskExecutor.java:106) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.maven.archiva.repository.layout.LayoutException: Invalid path to Artifact: filename format is invalid,expected timestamp format in filename. at org.apache.maven.archiva.repository.content.DefaultPathParser.toArtifactReference(DefaultPathParser.java:134) at org.apache.maven.archiva.repository.content.AbstractDefaultRepositoryContent.toArtifactReference(AbstractDefaultRepositoryContent.java:49) at org.apache.maven.archiva.repository.content.ManagedDefaultRepositoryContent.toArtifactReference(ManagedDefaultRepositoryContent.java:330) at org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.processFile(MetadataUpdaterConsumer.java:161) ... 24 more -- 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: (MJAR-66) Maven fails to include generated resources
[ http://jira.codehaus.org/browse/MJAR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122392 ] Rodrigo Ruiz commented on MJAR-66: -- I am experiencing the same problem. AxisTools does add the resources. Its execute() method ends with: projectHelper.addResource( project, outputDirectory.getAbsolutePath(), Collections.singletonList( "**/*.wsdl" ), Collections.EMPTY_LIST ); I have added some logs in a local modification of AxisTools. The plugin is executed, and after the above line, project.getResources() includes this new set. However, the jar plugin seems to not include any resource outside of target/classes. Maybe the following is a clue: if I execute: mvn clean compile axistools:java2wsdl package the resulting jar includes the wsdl file. If I just do: mvn package the jar does not have any wsdl file. > Maven fails to include generated resources > -- > > Key: MJAR-66 > URL: http://jira.codehaus.org/browse/MJAR-66 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Linux (not tested on windows) >Reporter: Leszek Ciesielski > Attachments: ConfigurationServerAPI.tar.gz > > > My project is generating a wsdl with axistools plugin. When maven is run with > mvn clean install (or after a checkout), the wsdl is not packaged into the > jar, although it is present when the jar is generated and included in > resources. On second run (mvn install) the wsdl file, is, as expected, > included. > A test project showing this behaviour 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] Created: (MAVENUPLOAD-1924) Sync com.exadel.flamingo repository
Sync com.exadel.flamingo repository --- Key: MAVENUPLOAD-1924 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1924 Project: maven-upload-requests Issue Type: Task Reporter: Artem Pleskatsevich Attachments: com.exadel.flamingo.sh Would like to synchronize the repository at http://repository.exadel.com/com/exadel/flamingo/ with the central maven repository. Access allowed from beaver.codehaus.org only. -- 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: (MECLIPSE-373) eclipse:to-maven cannot resolve Required-Bundle: system.bundle
[
http://jira.codehaus.org/browse/MECLIPSE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122389
]
Immo Huneke commented on MECLIPSE-373:
--
Suggested improvement to the maven-eclipse-plugin: when parsing the MANIFEST.MF
file during execution of the to-maven or create-artifacts goals, if a
Require-bundle includes "system.bundle", treat it as "org.eclipse.osgi"
implicitly. Everything else should then work as designed.
There may be additional OSGi bundle names that have conventional rather than
literal meanings. It will probably be best to set up a lookup table (e.g. a
static hash map).
> eclipse:to-maven cannot resolve Required-Bundle: system.bundle
> --
>
> Key: MECLIPSE-373
> URL: http://jira.codehaus.org/browse/MECLIPSE-373
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.4, 2.5
> Environment: Observed under MS Windows XP, probably affects all
> environments
>Reporter: Immo Huneke
>
> Install vanilla download of Eclipse RCP Developer (version 3.3.1.1, Europa).
> Try to install its plugins into the local Maven repository using
> mvn -DeclipseDir="/path/to/eclipse" eclipse:to-maven
> The error you get is:
> {code}[INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to resolve version range for dependency Dependency
> {groupId=system
> , artifactId=bundle, version=[0,), type=jar} in project org.apache.xerces
> [INFO]
> {code}
> My investigations have established that this can be worked around by (a)
> creating a Maven artifact called "system.bundle" using file:deploy-file, and
> (b) altering the manifest file to add the specific version number of that
> artifact to the above bundle requirement. You have to do this for every
> single Eclipse plugin that has a dependency on the OSGi system bundle. This
> is very laborious!
> I tried expressing the version number in the manifest as a range, but that
> didn't work. In other cases, where a version range is required, it seems to
> work fine, but not for system.bundle. See my blog at
> http://aspsp.blogspot.com/ for more details.
--
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: (MECLIPSE-373) eclipse:to-maven cannot resolve Required-Bundle: system.bundle
[
http://jira.codehaus.org/browse/MECLIPSE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121507
]
immohuneke edited comment on MECLIPSE-373 at 2/5/08 5:55 AM:
--
Simpler workaround: modify the MANIFEST.MF file of the affected plugins
(currently org.apache.xerces and org.apache.xml.resolver) to replace the
required-bundle system.bundle with org.eclipse.osgi. You do not have to specify
the precise version number. Remember to put back the original after you've run
the eclipse:to-maven goal!
This obviates the need to create a spurious system.bundle artifact in the Maven
repository.
was (Author: immohuneke):
Simpler workaround: modify the MANIFEST.MF file of the affected plugins
(currently org.apache.xerces and org.apache.xml.resolver) to replace the
required-bundle system.bundle with org.eclipse.osgi. You probably also have to
specify the precise version number. Remember to put back the original after
you've run the eclipse:to-maven goal!
This obviates the need to create a spurious system.bundle artifact in the Maven
repository.
> eclipse:to-maven cannot resolve Required-Bundle: system.bundle
> --
>
> Key: MECLIPSE-373
> URL: http://jira.codehaus.org/browse/MECLIPSE-373
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.4, 2.5
> Environment: Observed under MS Windows XP, probably affects all
> environments
>Reporter: Immo Huneke
>
> Install vanilla download of Eclipse RCP Developer (version 3.3.1.1, Europa).
> Try to install its plugins into the local Maven repository using
> mvn -DeclipseDir="/path/to/eclipse" eclipse:to-maven
> The error you get is:
> {code}[INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to resolve version range for dependency Dependency
> {groupId=system
> , artifactId=bundle, version=[0,), type=jar} in project org.apache.xerces
> [INFO]
> {code}
> My investigations have established that this can be worked around by (a)
> creating a Maven artifact called "system.bundle" using file:deploy-file, and
> (b) altering the manifest file to add the specific version number of that
> artifact to the above bundle requirement. You have to do this for every
> single Eclipse plugin that has a dependency on the OSGi system bundle. This
> is very laborious!
> I tried expressing the version number in the manifest as a range, but that
> didn't work. In other cases, where a version range is required, it seems to
> work fine, but not for system.bundle. See my blog at
> http://aspsp.blogspot.com/ for more details.
--
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: (MEAR-84) Ability to interpolate filenamemapping using regex.
Ability to interpolate filenamemapping using regex. --- Key: MEAR-84 URL: http://jira.codehaus.org/browse/MEAR-84 Project: Maven 2.x Ear Plugin Issue Type: Wish Reporter: Tuomas Kiviaho Priority: Minor I was trying to have an impact how artifact files would be mapped based on previous knowledge about assembly plugin but noticed that there's a fundamental difference in implementations. Both the 'stardard' and 'full' file name mapping of ear plugin could have been implemented using org.codehaus.plexus.util.interpolation.RegexBasedInterpolator quite identically to org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.evaluateFileNameMapping used in assembly plugin. The class name based pluggability is only available at EAR side. Regular expressions of the interpolator have a distinctive pattern separating them from classes and predefined mappings making it backwards compatible to extend the FileNameMappingFactory to match regular expressions. -- 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-1923) Please upload MessAdmin 4.1
Please upload MessAdmin 4.1 --- Key: MAVENUPLOAD-1923 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1923 Project: maven-upload-requests Issue Type: Wish Reporter: codehauser Attachments: MessAdmin-4.1-Bundles.zip http://messadmin.sourceforge.net/maven2/4.1/MessAdmin-Core-4.1-bundle.jar http://messadmin.sourceforge.net/maven2/4.1/MessAdmin-ClickStream-4.1-bundle.jar http://messadmin.sourceforge.net/maven2/4.1/MessAdmin-JMX-4.1-bundle.jar http://messadmin.sourceforge.net/maven2/4.1/MessAdmin-Serializable-4.1-bundle.jar http://messadmin.sourceforge.net/maven2/4.1/MessAdmin-ServletStats-4.1-bundle.jar http://messadmin.sourceforge.net/maven2/4.1/MessAdmin-SessionKiller-4.1-bundle.jar http://messadmin.sourceforge.net/ http://messadmin.sourceforge.net/#%5B%5BLicense%20%2F%20Contact%5D%5D MessAdmin is a light-weigth and non-intrusive tool for monitoring Java HttpSession. Please upload! -- 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: (MECLIPSE-387) download source should accept exclusion of artifact
[ http://jira.codehaus.org/browse/MECLIPSE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122386 ] Dominique Jean-Prost commented on MECLIPSE-387: --- Well I think there are 2 problems : first : MECLIPSE-332 which made me raise this feature because I thought it wasn't implemented at all. It is, but bug #MECLIPSE-332 is causing the problem. second : I agree that the cache should be shared among all artifact. So my need is that bug MECLIPSE-332 get fixed. I would be ok then to accept that the cache isn't shared between artifacts. > download source should accept exclusion of artifact > --- > > Key: MECLIPSE-387 > URL: http://jira.codehaus.org/browse/MECLIPSE-387 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Affects Versions: 2.4 >Reporter: Dominique Jean-Prost > > It would be nice to be possible to exclude specific group/artifact when > downloadSources is to true (in pom.xml for instance). > As the sources jar or the javadoc jar will never be available in repo, for > specific artifact, mvn eclipse:eclipse keep on trying to download them, and > it slows the process. -- 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: (MECLIPSE-387) download source should accept exclusion of artifact
[ http://jira.codehaus.org/browse/MECLIPSE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122384 ] Joerg Schaible commented on MECLIPSE-387: - Well, the Eclipse plugin already cached that, but unfortunately in the target directory of each artifact separately. I'd rather have a global cache for this e.g. in /.m2. Once the inavailability of a source artifact is listed there, it should not be requested again. > download source should accept exclusion of artifact > --- > > Key: MECLIPSE-387 > URL: http://jira.codehaus.org/browse/MECLIPSE-387 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Affects Versions: 2.4 >Reporter: Dominique Jean-Prost > > It would be nice to be possible to exclude specific group/artifact when > downloadSources is to true (in pom.xml for instance). > As the sources jar or the javadoc jar will never be available in repo, for > specific artifact, mvn eclipse:eclipse keep on trying to download them, and > it slows the process. -- 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: (MNG-3384) Repos defined in plugin are used to download dependencies
Repos defined in plugin are used to download dependencies - Key: MNG-3384 URL: http://jira.codehaus.org/browse/MNG-3384 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, Plugins and Lifecycle Affects Versions: 2.0.8 Reporter: Stefan Seidel When a plugin defines a repository, the dependencies declared to and by this plugin are being resolved within these repositories. While this might be easier, it introduces a number of problems, including the fact that it cannot be controlled which repos are being used, security concerns (internal artifact names might be sent to a remote repository, a malicious plugin could define a fake repo with malicious "more recent" versions of almost anything). If there is no intention to change the current behaviour, there should be at least an option to disable it. More unspecifically, I think the situation got worse in 2.1-SNAPSHOT (I use the m2eclipse plugin), because I see lookups of SNAPSHOT versions of dependencies occur much more often than with 2.0.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] Created: (MECLIPSE-387) download source should accept exclusion of artifact
download source should accept exclusion of artifact --- Key: MECLIPSE-387 URL: http://jira.codehaus.org/browse/MECLIPSE-387 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Affects Versions: 2.4 Reporter: Dominique Jean-Prost It would be nice to be possible to exclude specific group/artifact when downloadSources is to true (in pom.xml for instance). As the sources jar or the javadoc jar will never be available in repo, for specific artifact, mvn eclipse:eclipse keep on trying to download them, and it slows the process. -- 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: (MDEP-142) Path with space makes the dependency:unpack goal fail
Path with space makes the dependency:unpack goal fail
-
Key: MDEP-142
URL: http://jira.codehaus.org/browse/MDEP-142
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 2.0, 2.0-alpha-4
Environment: Mac OS X 10.5.1
Java 1.5.0_13-b05-237
Maven 2.0.8
Reporter: Pierre-Arnaud Marcelot
Assignee: Brian Fox
Priority: Blocker
Configuration in pom.xml file:
org.apache.maven.plugins
maven-dependency-plugin
launcher-macosx (unpack)
generate-resources
unpack
true
${project.build.directory}/dependency-maven-plugin-markers/macosx
org.apache.directory.studio
launcher-macosx
tar.gz
${studio-dir}-macosx
org.eclipse.equinox.launcher.carbon
macosx
tar.gz
${studio-dir}-macosx/Apache Directory
Studio.app/Contents/Resources/Java/plugins
Maven output:
[INFO]
[INFO] Building Apache Directory Studio Build
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/pajbam/Development/Apache/studio-maven/studio/target
[INFO] Deleting directory
/Users/pajbam/Development/Apache/studio-maven/studio/target/classes
[INFO] Deleting directory
/Users/pajbam/Development/Apache/studio-maven/studio/target/test-classes
[INFO] Deleting directory
/Users/pajbam/Development/Apache/studio-maven/studio/target/site
[INFO] [remote-resources:process {execution: default}]
[INFO] [dependency:unpack {execution: launcher-macosx (unpack)}]
[INFO] Configured Artifact: org.apache.directory.studio:launcher-macosx:?:tar.gz
[INFO] Configured Artifact: org.eclipse.equinox.launcher.carbon:macosx:?:tar.gz
[INFO] Unpacking
/Users/pajbam/.m2/repository/org/apache/directory/studio/launcher-macosx/1.1.0/launcher-macosx-1.1.0.tar.gzto
/Users/pajbam/Development/Apache/studio-maven/studio/target/ApacheDirectoryStudio-macosx
with Includes null and excludes:null
[INFO] Expanding
/Users/pajbam/.m2/repository/org/apache/directory/studio/launcher-macosx/1.1.0/launcher-macosx-1.1.0.tar.gz
to /tmp/tmp6522.tar
[INFO] Expanding: /tmp/tmp6522.tar into
/Users/pajbam/Development/Apache/studio-maven/studio/target/ApacheDirectoryStudio-macosx
[WARNING] ---
[WARNING] Standard error:
[WARNING] ---
[WARNING]
[WARNING] ---
[WARNING] Standard output:
[WARNING] ---
[WARNING] /bin/sh: line 0: cd:
/Users/pajbam/Development/Apache/studio-maven/studio/target/ApacheDirectoryStudio-macosx/Apache:
No such file or directory
[WARNING] ---
org.codehaus.plexus.archiver.ArchiverException: chmod exit code was: 1
at
org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:59)
at
org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.extractFile(AbstractZipUnArchiver.java:236)
at
org.codehaus.plexus.archiver.tar.TarUnArchiver.execute(TarUnArchiver.java:92)
at
org.codehaus.plexus.archiver.tar.TarGZipUnArchiver.execute(TarGZipUnArchiver.java:76)
at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:108)
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:266)
at
org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122)
at
org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
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(DefaultLife
[jira] Created: (MNG-3383) Downloaded plugin dependencies influence project dependencies
Downloaded plugin dependencies influence project dependencies
-
Key: MNG-3383
URL: http://jira.codehaus.org/browse/MNG-3383
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories, Dependencies, Plugins and
Lifecycle
Affects Versions: 2.0.8
Reporter: Stefan Seidel
Attachments: pom.xml
Currently, a plugin may define additional pluginRepositories, which are used to
resolve dependencies of that plugin.
This leads to the fact that a plugin might resolve a dependency which would
normally not be available to the project.
When it does that, it seems to write a metadata-central (although on the
central repo this artifact does not exist) and thus, the project will use that
dependency, too.
How to reproduce:
1. remove xstream from local repo:
{code}rm -Rf ~/.m2/repository/com/thoughtworks/xstream{code}
2. run mvn clean install on the attached pom.xml
-> the build should fail because the version 1.3.0-SNAPSHOT is not available at
repo1.maven.org
3. edit the pom.xml, uncomment the plugin definition (jspc used for
demonstration purposes only)
3. run mvn clean install again
-> the build succeeds and the 1.3.0-SNAPSHOT is being built into the artifact,
which is wrong.
--
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: (SUREFIRE-450) Verification test failure: Invalid mavenProfile entry. Missing one or more fields: {localRepository}
Verification test failure: Invalid mavenProfile entry. Missing one or more
fields: {localRepository}
Key: SUREFIRE-450
URL: http://jira.codehaus.org/browse/SUREFIRE-450
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.x
Environment: java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)
Reporter: Graham Leggett
All tests in surefire-integration-tests fail like so:
testTwoTestCases(org.apache.maven.surefire.its.TwoTestCasesTest) Time elapsed:
0.011 sec <<< ERROR!
org.apache.maven.it.VerificationException: org.xml.sax.SAXException: Invalid
mavenProfile entry. Missing one or more fields: {localRepository}.
at
org.apache.maven.it.Verifier$UserModelReader.parse(Verifier.java:1269)
at org.apache.maven.it.Verifier.retrieveLocalRepo(Verifier.java:557)
at org.apache.maven.it.Verifier.findLocalRepo(Verifier.java:1178)
at org.apache.maven.it.Verifier.(Verifier.java:101)
at org.apache.maven.it.Verifier.(Verifier.java:80)
at org.apache.maven.it.Verifier.(Verifier.java:107)
at
org.apache.maven.surefire.its.TwoTestCasesTest.testTwoTestCases(TwoTestCasesTest.java:27)
It looks like the localRepository setting is missing from a pom or config file
somewhere.
--
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: (MECLIPSE-386) Modified MANIFEST.MF file for eclipse jars packaged from folders with eclipse:to-maven
Modified MANIFEST.MF file for eclipse jars packaged from folders with eclipse:to-maven -- Key: MECLIPSE-386 URL: http://jira.codehaus.org/browse/MECLIPSE-386 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Reporter: Pierre-Arnaud Marcelot The MANIFEST.MF file of some Eclipse jars deployed on the http://repo1.maven.org/maven2 repository using the eclipse:to-maven goal has been modified. When using these jars within Eclipse, the jar signing verification fails. The line "Archiver-Version : Plexus Archiver" has been added to the original MANIFEST.MF. This issue seems to apply only on Eclipse jars that are packaged as folder in the 'plugins' folder of an Eclipse installation. The following (at least) packages fails verification with eclipse: * org.eclipse.core.runtime.compatibility.registry plugin, version 3.2.100-v20070316 * org.eclipse.ui.workbench.compatibility plugin, version 3.2.0.I20070319-0010 For instance in the org.eclipse.core.runtime.compatibility.registry plugin, version 3.2.100-v20070316 plugin, not only the MANIFEST.MF file is modified in the way I described earlier, but the SHA1-Digest of the runtime_registry_compatibilty.jar has been changed too (and thus the file itself). -- 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: (MRM-669) Test failure occurs when building the bundled sources of archiva
[
http://jira.codehaus.org/browse/MRM-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maria Odea Ching closed MRM-669.
Resolution: Duplicate
http://jira.codehaus.org/browse/MRM-605
> Test failure occurs when building the bundled sources of archiva
>
>
> Key: MRM-669
> URL: http://jira.codehaus.org/browse/MRM-669
> Project: Archiva
> Issue Type: Bug
> Components: build
>Affects Versions: 1.0
> Environment: Fedora 8, JDK 1.5, Maven 2.0.7
>Reporter: Napoleon Esmundo C. Ramirez
> Attachments: archiva.log
>
>
> I downloaded the bundled sources of archiva from
> http://maven.apache.org/archiva and extracted it in some directory. After
> that, I executed `mvn clean install` inside the extracted source directory,
> then I encountered a test failure somewhere in the archiva-repository-layer:
> {code}
> ---
> Test set: org.apache.maven.archiva.repository.scanner.RepositoryScannerTest
> ---
> Tests run: 8, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.535 sec <<<
> FAILURE!
> testDefaultRepositoryScanner(org.apache.maven.archiva.repository.scanner.RepositoryScannerTest)
> Time elapsed: 0.11 sec <<< FAILURE!
> junit.framework.AssertionFailedError: Processed Count (of invalid items)
> expected:<6> but was:<5>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at
> org.apache.maven.archiva.repository.scanner.RepositoryScannerTest.testDefaultRepositoryScanner(RepositoryScannerTest.java:219)
> {code}
> I attached my build log as well.
--
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-262) site.xml not inherited if build run from parent
[ http://jira.codehaus.org/browse/MSITE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122371 ] Stefan Seidel commented on MSITE-262: - This was still working in 2.0-beta-5 and is still not working in 2.0-beta-7-SNAPSHOT. > site.xml not inherited if build run from parent > --- > > Key: MSITE-262 > URL: http://jira.codehaus.org/browse/MSITE-262 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Cameron Jones > Attachments: MSITE-262.zip > > > I've seen that the site.xml is not being inherited in a module when the build > is run from the parent - when run from the module itself the inheritance > works correctly. -- 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: (DOXIASITETOOLS-9) PathDescriptor fails to create proper absolute paths from relative components, as expected by DefaultDecorationModelInheritanceAssembler.convertPaths
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIASITETOOLS-9.
--
Assignee: Lukas Theussl
Resolution: Won't Fix
This behavior is correct according to the rfc specs:
http://www.ietf.org/rfc/rfc2396.txt (see eg the example given in App D).
If you want the "1" to be interpreted as a hierarchical component (ie as a
directory on a filesystem), you need to append a slash in the end:
{code}
PathDescriptor( new URL(
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1/
), "../../../com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png" )
{code}
which is a recommended practice for web URLs anyway, see eg
http://www.standardzilla.com/2007/07/09/dont-forget-your-trailing-slash/
> PathDescriptor fails to create proper absolute paths from relative
> components, as expected by
> DefaultDecorationModelInheritanceAssembler.convertPaths
> -
>
> Key: DOXIASITETOOLS-9
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-9
> Project: Maven Doxia Site Tools
> Issue Type: Bug
>Affects Versions: 1.0-alpha-10
> Environment: 2.0.8
>Reporter: John Allen
>Assignee: Lukas Theussl
>
> PathDescriptor is either incorrectly implemented for handling the building of
> URLs from relativePaths.
> A call to
> {code}
> PathDescriptor( new URL(
> http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1
> ), "../../../com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png" )
> {code}
> And you boil down to this call
> {code}
> private static final URL buildUrl( final URL baseUrl, final String path )
> throws MalformedURLException
> {
> if ( baseUrl == null )
> {
> throw new MalformedURLException( "Base is null!" );
> }
> if ( path == null )
> {
> return baseUrl;
> }
> if ( baseUrl.getProtocol().equals( "file" ) )
> {
> return new File( baseUrl.getFile(), path ).toURL();
> }
> if ( path.startsWith( "/" ) && baseUrl.getPath().endsWith( "/" ) )
> {
> return new URL( baseUrl, path.substring( 1 ) );
> }
> return new URL( baseUrl, path );
> }
> {code}
> And critically the last line, namely:
> {code}
> return new URL( baseUrl, path );
> {code}
> where baseUrl is the previously mentioned LHS and path is the RHS passed into
> the constructor
> Javadoc for this baby says (java.net.URL.URL(URL context, String spec)):
> {quote}
> Otherwise, the path is treated as a relative path and is appended to the
> context path, as described in RFC2396. Also, in this case, the path is
> canonicalized through the removal of directory changes made by occurences of
> ".." and ".".
> For a more detailed description of URL parsing, refer to RFC2396.
> {quote}
> Going to RFC 2396 and we find this in relation to "5.2. Resolving Relative
> References to Absolute Form"
> {quote}
> 6) If this step is reached, then we are resolving a relative-path
> reference. The relative path needs to be merged with the base
> URI's path. Although there are many ways to do this, we will
> describe a simple method using a separate string buffer.
> a) All but the last segment of the base URI's path component is
> copied to the buffer. In other words, any characters after the
> last (right-most) slash character, if any, are excluded.
> {quote}
> So what happens? First of all the most right hand side path segment of the
> context is removed.
> That turns our LHS url from:
> http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1
> to:
> http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins
> And now it says we cat on the spec, handling the '..' etc.
> So we now do this:
> http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins
> + ../../../com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png
> Which results in:
> http://projects.apt.fs.fujitsu.com/com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png
> Which is *INVALID* as it does not exist
> What this object was trying to do was create a new URL of the form:
> http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1
> + ../../../com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png
> i.e.:
> http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png
> Which it can't as the first thing java.
