[jira] Updated: (MRESOURCES-81) 2.3 escapes characters when filtering properties
[
http://jira.codehaus.org/browse/MRESOURCES-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MRESOURCES-81:
--
Description:
When filtering a property additional escaping characters are inserted into the
replacement text. Here's an example pom snippett:
{code:xml}
Automated-Testing-Windows
nt
D:\\AutomatedTesting
${server.remote.base.dir}\\temp
src/main/resources/${server.resource.type}
true
maven-resources-plugin
2.3
resources
process-resources
resources
${project.build.directory}/resources
true
{code}
and the following line of text in a file in src\main\resources\nt
cd /d ${server.remote.temp.dir}
Resources plug in version 2.2 filters this property as follows:
cd /d D:\\AutomatedTesting\\temp
Resources plug in version 2.3 filters this property differently:
cd /d D\:AutomatedTestingtemp
Notice the extra backslashes inserted before each backslash (minor issue) and
colon (major issue). Is there a way to prevent maven from inserting these
escape characters?
I also checked out 2.4-SNAPSHOT revision 732027 and observed the same behavior.
Thanks,
-Paul
was:
When filtering a property additional escaping characters are inserted into the
replacement text. Here's an example pom snippett:
Automated-Testing-Windows
nt
D:\\AutomatedTesting
${server.remote.base.dir}\\temp
src/main/resources/${server.resource.type}
true
maven-resources-plugin
2.3
resources
process-resources
resources
${project.build.directory}/resources
true
and the following line of text in a file in src\main\resources\nt
cd /d ${server.remote.temp.dir}
Resources plug in version 2.2 filters this property as follows:
cd /d D:\\AutomatedTesting\\temp
Resources plug in version 2.3 filters this property differently:
cd /d D\:AutomatedTestingtemp
Notice the extra backslashes inserted before each backslash (minor issue) and
colon (major issue). Is there a way to prevent maven from inserting these
escape characters?
I also checked out 2.4-SNAPSHOT revision 732027 and observed the same behavior.
Thanks,
-Paul
> 2.3 escapes characters when filtering properties
>
>
> Key: MRESOURCES-81
> URL: http://jira.codehaus.org/browse/MRESOURCES-81
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows
>Reporter: Paul Jackson
>Assignee: John Casey
> Fix For: 2.4
>
>
> When filtering a property additional escaping characters are inserted into
> the replacement text. Here's an example pom snippett:
> {code:xml}
>
>
> Automated-Testing-Windows
>
> nt
>
> D:\\AutomatedTesting
>
> ${server.remote.base.dir}\\temp
>
>
>
>
>
> src/main/resources/${server.resource.type}
> true
>
>
>
>
>
> maven-resources-plugin
> 2.3
>
>
> resources
> process-resources
>
> resources
>
>
>
> ${project.build.directory}/resources
> true
>
>
>
>
>
>
> {code}
> and the following line of text in a file in src\main\resources\nt
> cd /d ${server.remote.temp.dir}
> Resources plug in version 2.2 filters this property as follows:
> cd /d D:\\AutomatedTesting\\temp
> Resources plug in version 2.3 filters this property differently:
> cd /d D\:AutomatedTestingtemp
> Notice the extra backslashes inserted before each backslash (minor issue) and
> colon (major issue). Is there a way to prevent maven from inserting these
> escape characters?
>
> I also checked out 2.4-SNAPSHOT revision 732027 and observed the same
> behavior.
> Thanks,
> -Paul
--
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: (MSHARED-179) FilteringUtils.escapeWindowsPath only works if the Windows path is at the beginning of a property
FilteringUtils.escapeWindowsPath only works if the Windows path is at the
beginning of a property
-
Key: MSHARED-179
URL: http://jira.codehaus.org/browse/MSHARED-179
Project: Maven Shared Components
Issue Type: Bug
Components: maven-filtering
Affects Versions: maven-filtering-1.0-beta-4
Reporter: Dennis Lundberg
If the Windows path is in the middle, like in a JDBC URL escaping is not done.
Here's the code from FilteringUtils.java that causes it:
{code:java}
public static final String escapeWindowsPath( String val )
{
if ( !StringUtils.isEmpty( val ) && val.indexOf( ":\\" ) == 1 )
...
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSHARED-179) FilteringUtils.escapeWindowsPath only works if the Windows path is at the beginning of a property
[
http://jira.codehaus.org/browse/MSHARED-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSHARED-179:
Attachment: MSHARED-179.zip
Here is a sample project that highlights this problem.
Run 'mvn test' and have a look at the file
"target/test-classes/database.properties".
Notice how the "logfile" property has escaped backslashes, but the "jdbc.url"
property does not.
> FilteringUtils.escapeWindowsPath only works if the Windows path is at the
> beginning of a property
> -
>
> Key: MSHARED-179
> URL: http://jira.codehaus.org/browse/MSHARED-179
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.0-beta-4
>Reporter: Dennis Lundberg
> Attachments: MSHARED-179.zip
>
>
> If the Windows path is in the middle, like in a JDBC URL escaping is not
> done. Here's the code from FilteringUtils.java that causes it:
> {code:java}
> public static final String escapeWindowsPath( String val )
> {
> if ( !StringUtils.isEmpty( val ) && val.indexOf( ":\\" ) == 1 )
> ...
> {code}
--
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-682) cannot be overridden by commandline param
cannot be overridden by commandline param - Key: SUREFIRE-682 URL: http://jira.codehaus.org/browse/SUREFIRE-682 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.7.1 Reporter: Julien HENRY This issue is very similar to SUREFIRE-319 When is defined in the pom, there is no way to override the value using -DskipTests or -DskipTests=true|false on the command line. I think it would be better if command line parameter could have higher priority over pom configuration. -- 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: (MSHARED-121) FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the drive letter.
[
http://jira.codehaus.org/browse/MSHARED-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250495#action_250495
]
Dennis Lundberg commented on MSHARED-121:
-
In r1055372 I committed the test case submitted by John Casey, but with the two
failing tests commented out.
> FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the
> drive letter.
> --
>
> Key: MSHARED-121
> URL: http://jira.codehaus.org/browse/MSHARED-121
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.0-beta-3
>Reporter: John Casey
> Attachments:
> 0001-MSHARED-121-Don-t-require-a-drive-letter-to-escape-a.patch,
> FilteringUtilsTest.java
>
>
> FilteringUtils.escapeWindowsPath requires a drive letter to be present in the
> path, or at least the string {noformat}":\\"{noformat} to be present in order
> to trigger escaping the value as a windows path.
> In cases where the path is an absolute reference to a file on the current
> drive (no drive letter is included), or when the path starts with an
> unresolved expression (in cases where n+1 level interpolation will eventually
> resolve the expression), escaping doesn't happen at all.
--
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: (MCHANGES-216) Alow arbitrary xdoc markup inside action
Alow arbitrary xdoc markup inside action Key: MCHANGES-216 URL: http://jira.codehaus.org/browse/MCHANGES-216 Project: Maven 2.x Changes Plugin Issue Type: New Feature Components: changes.xml Affects Versions: 2.3 Reporter: Lukas Theussl In maven 1, the element could contain arbitrary xdoc markup. This will require a new xsd. See MCHANGES-190. -- 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: (MSHARED-179) FilteringUtils.escapeWindowsPath only works if the Windows path is at the beginning of a property
[
http://jira.codehaus.org/browse/MSHARED-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250496#action_250496
]
Dennis Lundberg commented on MSHARED-179:
-
In r1055383 I added a failing test case for this issue, that is commented out.
> FilteringUtils.escapeWindowsPath only works if the Windows path is at the
> beginning of a property
> -
>
> Key: MSHARED-179
> URL: http://jira.codehaus.org/browse/MSHARED-179
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.0-beta-4
>Reporter: Dennis Lundberg
> Attachments: MSHARED-179.zip
>
>
> If the Windows path is in the middle, like in a JDBC URL escaping is not
> done. Here's the code from FilteringUtils.java that causes it:
> {code:java}
> public static final String escapeWindowsPath( String val )
> {
> if ( !StringUtils.isEmpty( val ) && val.indexOf( ":\\" ) == 1 )
> ...
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSHARED-179) FilteringUtils.escapeWindowsPath only works if the Windows path is at the beginning of a property
[
http://jira.codehaus.org/browse/MSHARED-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSHARED-179:
Attachment: MSHARED-179.patch
Attached a proposed patch for this issue. Please review.
> FilteringUtils.escapeWindowsPath only works if the Windows path is at the
> beginning of a property
> -
>
> Key: MSHARED-179
> URL: http://jira.codehaus.org/browse/MSHARED-179
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.0-beta-4
>Reporter: Dennis Lundberg
> Attachments: MSHARED-179.patch, MSHARED-179.zip
>
>
> If the Windows path is in the middle, like in a JDBC URL escaping is not
> done. Here's the code from FilteringUtils.java that causes it:
> {code:java}
> public static final String escapeWindowsPath( String val )
> {
> if ( !StringUtils.isEmpty( val ) && val.indexOf( ":\\" ) == 1 )
> ...
> {code}
--
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-667) Setting up maven resources when testing in addition to testResources
[
http://jira.codehaus.org/browse/SUREFIRE-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250499#action_250499
]
lisak commented on SUREFIRE-667:
The resources (spring configs mainly) in Liferay plugins are being loaded very
traditionally within containers. From container's web application context
webapps/APP/WEB-INF/classes/META-INF/spring-stuff.xml ... Liferay portal is
webapp depending on a standard jar having META-INF/spring-stuff.xml inside
I really don't see what is wrong with it. It is actually very convenience as
far as I know. You know, Liferay is build with Ant, and there appears to be an
effort lastly to slowly migrate to maven. So far there is a possibility to use
it for plugins development, but still using Ant is considered the default and
it works very well. I prefer maven and the guy who maintains Maven stuff in
Liferay isn't very communicative, I sent him some patches a month ago and I
didn't even get response back.
> Setting up maven resources when testing in addition to testResources
>
>
> Key: SUREFIRE-667
> URL: http://jira.codehaus.org/browse/SUREFIRE-667
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 2.6
>Reporter: vychtrle
>
> Hey,
> I think that developers would need resource goal of resource plugin to be set
> up differently for
> test phase, than for build phase. When testing one needs to exclude stuff
> from src/main/resources. It seems it can't be done, testResources goal
> is irrelevant for this because it can't operate on src/main/* and resource
> goal can have only one
> setting in pom definition, that takes effect in both test and build
> phase...
> For example, I'd need following settings to look differently (some
> excludes) in testing phase :
>
>
>${project.basedir}/src/main/java
>
>**/*.java
>service.properties
>
>
>
>
> ${project.basedir}/src/main/resources
>
>**/*.xml
>**/*.properties
>
>
>
> The ideal behavior would be if one could define "src/main/*" in
> but it unfortunately can't be done right now
--
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: (MCHANGES-217) wrong sorting order in jira report
wrong sorting order in jira report -- Key: MCHANGES-217 URL: http://jira.codehaus.org/browse/MCHANGES-217 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: jira Affects Versions: 2.3 Reporter: Lukas Theussl >From the >[documentation|http://maven.apache.org/plugins/maven-changes-plugin/jira-report-mojo.html#sortColumnNames]: > 'Fix Version DESC, Type sorts first by the Fix Version in descending order >and then by Type in ascending order'. The actual result is however the other >way round: the sorting by type is done first. -- 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-217) wrong sorting order in jira report
[ http://jira.codehaus.org/browse/MCHANGES-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MCHANGES-217: --- Attachment: MCHANGES-217.zip Attaching small demonstration project. > wrong sorting order in jira report > -- > > Key: MCHANGES-217 > URL: http://jira.codehaus.org/browse/MCHANGES-217 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira >Affects Versions: 2.3 >Reporter: Lukas Theussl > Attachments: MCHANGES-217.zip > > > From the > [documentation|http://maven.apache.org/plugins/maven-changes-plugin/jira-report-mojo.html#sortColumnNames]: > 'Fix Version DESC, Type sorts first by the Fix Version in descending order > and then by Type in ascending order'. The actual result is however the other > way round: the sorting by type is done first. -- 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: (MDOAP-35) Fetch file-release url
Fetch file-release url -- Key: MDOAP-35 URL: http://jira.codehaus.org/browse/MDOAP-35 Project: Maven 2.x DOAP Plugin Issue Type: New Feature Reporter: Vincent Siveton -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGES-218) Downloading from JIRA fails if issueManagement.url has trailing slash
Downloading from JIRA fails if issueManagement.url has trailing slash
-
Key: MCHANGES-218
URL: http://jira.codehaus.org/browse/MCHANGES-218
Project: Maven 2.x Changes Plugin
Issue Type: Bug
Components: jira
Affects Versions: 2.3
Reporter: Lukas Theussl
With an issueManagement.url like http://jira.codehaus.org/browse/DOXIA/ (note
trailing slash), the jira report chokes
{noformat}
[WARNING] Downloading from JIRA failed. Received: [404]
{noformat}
and an empty report is generated. removing the trailing slash makes it work.
--
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: (MDOAP-35) Fetch file-release url
[ http://jira.codehaus.org/browse/MDOAP-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MDOAP-35. Resolution: Fixed Fix Version/s: 1.1 Assignee: Vincent Siveton fixed in r1055397 > Fetch file-release url > -- > > Key: MDOAP-35 > URL: http://jira.codehaus.org/browse/MDOAP-35 > Project: Maven 2.x DOAP Plugin > Issue Type: New Feature >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.1 > > -- 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: (MPIR-216) Report on dependency-management throws Exceptions using version range for dependency
[
http://jira.codehaus.org/browse/MPIR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250506#action_250506
]
Vincent Siveton commented on MPIR-216:
--
It seems to come from aether, fill an issue to
https://issues.sonatype.org/browse/AETHER
> Report on dependency-management throws Exceptions using version range for
> dependency
>
>
> Key: MPIR-216
> URL: http://jira.codehaus.org/browse/MPIR-216
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.3.1
> Environment: Maven 3.0.1, Java 6u23
>Reporter: André Fügenschuh
>
> Given the following simple project:
> {code}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> foo
> app
> 3.0-SNAPSHOT
> App
>
>
>
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.0-beta-3
>
>
>
> org.apache.maven.plugins
> maven-project-info-reports-plugin
> 2.3.1
>
>
>
>
> dependency-management
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> junit
> junit
> [4.8,)
> test
>
>
>
>
>
> junit
> junit
>
>
>
> {code}
> {{mvn site}} throws an exception (although site is generated):
> {code}
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building App 3.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-site-plugin:3.0-beta-3:site (default-site) @ app ---
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-project-info-reports-plugin:2.3.1
> [WARNING] No URL defined for the project - decoration links will not be
> resolved
> [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
> skin.
> [INFO] Generating "Dependency Management" report---
> maven-project-info-reports-plugin:2.3.1
> [WARNING] Unable to create Maven project from repository.
> org.apache.maven.project.ProjectBuildingException: Error resolving project
> artifact: Failure to find junit:junit:pom:[4.
> 8,) in http://uk.maven.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the updat
> e interval of UK has elapsed or updates are forced for project
> junit:junit:pom:[4.8,)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:260)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtil
> s.java:332)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(Depen
> dencyManagementRenderer.java:219)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForS
> cope(DependencyManagementRenderer.java:198)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForA
> llScopes(DependencyManagementRenderer.java:149)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDe
> pendencies(DependencyManagementRenderer.java:140)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyM
> anagementRenderer.java:126)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:
> 115)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:165)
> at
> org.apache.maven.doxia.siterende
[jira] Updated: (MPIR-216) Report on dependency-management throws Exceptions using version range for dependency
[
http://jira.codehaus.org/browse/MPIR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MPIR-216:
---
Attachment: pom.xml
Modified version of reporter-provided example POM for use with Maven 2.x. This
logs
{noformat}
[INFO] Generating "Dependency Management" report.
Downloading: http://repo1.maven.org/maven2/junit/junit/[4.8,)/junit-[4.8,).pom
[INFO] Unable to find resource 'junit:junit:pom:[4.8,)' in repository central
(http://repo1.maven.org/maven2)
{noformat}
The plugin is misusing Maven APIs, Maven 3.x is merely more verbose about this.
> Report on dependency-management throws Exceptions using version range for
> dependency
>
>
> Key: MPIR-216
> URL: http://jira.codehaus.org/browse/MPIR-216
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.3.1
> Environment: Maven 3.0.1, Java 6u23
>Reporter: André Fügenschuh
> Attachments: pom.xml
>
>
> Given the following simple project:
> {code}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> foo
> app
> 3.0-SNAPSHOT
> App
>
>
>
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.0-beta-3
>
>
>
> org.apache.maven.plugins
> maven-project-info-reports-plugin
> 2.3.1
>
>
>
>
> dependency-management
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> junit
> junit
> [4.8,)
> test
>
>
>
>
>
> junit
> junit
>
>
>
> {code}
> {{mvn site}} throws an exception (although site is generated):
> {code}
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building App 3.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-site-plugin:3.0-beta-3:site (default-site) @ app ---
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-project-info-reports-plugin:2.3.1
> [WARNING] No URL defined for the project - decoration links will not be
> resolved
> [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
> skin.
> [INFO] Generating "Dependency Management" report---
> maven-project-info-reports-plugin:2.3.1
> [WARNING] Unable to create Maven project from repository.
> org.apache.maven.project.ProjectBuildingException: Error resolving project
> artifact: Failure to find junit:junit:pom:[4.
> 8,) in http://uk.maven.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the updat
> e interval of UK has elapsed or updates are forced for project
> junit:junit:pom:[4.8,)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:260)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtil
> s.java:332)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(Depen
> dencyManagementRenderer.java:219)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForS
> cope(DependencyManagementRenderer.java:198)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForA
> llScopes(DependencyManagementRenderer.java:149)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDe
> pendencies(DependencyManagementRenderer.java:140)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyM
> anagementRenderer.java:126)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.D
[jira] Updated: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[
http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated MSITE-502:
Component/s: site descriptor
multi module
> Multiple Parent-Links and additional module-link inherited wrong from parent
>
>
> Key: MSITE-502
> URL: http://jira.codehaus.org/browse/MSITE-502
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: inheritance, multi module, site descriptor
>Affects Versions: 2.1.1
>Reporter: Michael Wenig
> Attachments: siteInheritance.zip
>
>
> Attached is a couple of projects showing a problem with the site inheritance.
> The projects have the following structure:
> parentPom1
> -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
> -> projectB (parentPom3)
> -> projectC (projectRoot with a submodule 'projectModule')
> I ran the following commands:
> parentPom1: install
> projectA: site site:attach-descriptor install
> projectB site install
> projectC site install
> I added the corresponding target-folders to the zip:
> projectA:
> generated correctly
> projectB:
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to parentPom2 (which is correct)
> projectC (root):
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to projectB (which is correct)
> shows two modules:
> -> dummyModule (the one of projectA which is wrong and IMHO inherited out of
> the attached site-descriptor)
> -> projectModule (correct)
> ==> I expected the parent-Menu to only contain the direct parent
> ==> I expected the modules menu to only contain modules of the pom and not
> the modules of a parent...
> Content of the attached site descriptor:
> {code:xml}
> xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1
> http://maven.apache.org/xsd/decoration-1.0.1.xsd";
> xmlns="http://maven.apache.org/DECORATION/1.0.1";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
>
>
>
>
>
>
>
> {code}
> I think the problem are the contained item-tags which are included in the
> sites of consumer projects.
--
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: (MCHANGES-115) Add title to type images
[ http://jira.codehaus.org/browse/MCHANGES-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250526#action_250526 ] Anders Hammar commented on MCHANGES-115: This would be very nice. Couldn't the required Maven version be bumped to 2.1 at the same time as the plugin is moved to Java 5? > Add title to type images > > > Key: MCHANGES-115 > URL: http://jira.codehaus.org/browse/MCHANGES-115 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: changes.xml >Affects Versions: 2.0 >Reporter: Michael Osipov > > Right now the type images are just images without any text. Every unknowing > person cannot identify the affiliation of this image to its type. I would be > great to add a title attribute to the img tag. Would clarify a lot. > Tried myself to create a patch and found out that this issue is related to > DOXIA-75 but Doxia 1.0-beta-1 has not been released yet. -- 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: (MCHANGES-219) Not specifying a date for a release causes "null" to be displayed in changes report
Not specifying a date for a release causes "null" to be displayed in changes report --- Key: MCHANGES-219 URL: http://jira.codehaus.org/browse/MCHANGES-219 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: changes.xml Affects Versions: 2.3 Environment: Windows XP Sun JDK 1.6.0_18 Reporter: Anders Hammar If the date is not specified for a release, "null" is displayed in the header of that release. For example, the header text for release 1.0.0 is "Release 1.0.0 - null". Note that the date is correctly left empty in the release table. My suggestion is that if no date is specified, the header text should just be "Release x.x.x". No dash and obviously no "null" text. :-) -- 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: (MWAR-246) NullPointerException Processing Web Resources
NullPointerException Processing Web Resources - Key: MWAR-246 URL: http://jira.codehaus.org/browse/MWAR-246 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1.1 Environment: Linux, JDK 6 Reporter: Gary Murphy NullPointerException on packaging of web resources. Configuration is: maven-war-plugin xercesImpl-*.jar Stack trace is: Execution default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:116) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) ... 19 more Caused by: java.lang.NullPointerException at java.io.File.(File.java:222) at org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleWebResources(WarProjectPackagingTask.java:124) at org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:91) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:472) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:404) at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:197) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:159) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) ... 20 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: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[
http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250527#action_250527
]
Lukas Theussl commented on MSITE-502:
-
The reason is that the site descriptor gets interpolated by site:attach, see
MSITE-61. If you specify relativePath, the original site.xml is loaded
un-interpolated, so no problem.
However, I don't understand the logic behind MSITE-61, why would you need the
parent's parent/modules in the child? IMO the site descriptor should get
attached as is without interpolation.
> Multiple Parent-Links and additional module-link inherited wrong from parent
>
>
> Key: MSITE-502
> URL: http://jira.codehaus.org/browse/MSITE-502
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: inheritance, multi module, site descriptor
>Affects Versions: 2.1.1
>Reporter: Michael Wenig
> Attachments: siteInheritance.zip
>
>
> Attached is a couple of projects showing a problem with the site inheritance.
> The projects have the following structure:
> parentPom1
> -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
> -> projectB (parentPom3)
> -> projectC (projectRoot with a submodule 'projectModule')
> I ran the following commands:
> parentPom1: install
> projectA: site site:attach-descriptor install
> projectB site install
> projectC site install
> I added the corresponding target-folders to the zip:
> projectA:
> generated correctly
> projectB:
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to parentPom2 (which is correct)
> projectC (root):
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to projectB (which is correct)
> shows two modules:
> -> dummyModule (the one of projectA which is wrong and IMHO inherited out of
> the attached site-descriptor)
> -> projectModule (correct)
> ==> I expected the parent-Menu to only contain the direct parent
> ==> I expected the modules menu to only contain modules of the pom and not
> the modules of a parent...
> Content of the attached site descriptor:
> {code:xml}
> xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1
> http://maven.apache.org/xsd/decoration-1.0.1.xsd";
> xmlns="http://maven.apache.org/DECORATION/1.0.1";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
>
>
>
>
>
>
>
> {code}
> I think the problem are the contained item-tags which are included in the
> sites of consumer projects.
--
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: (MCHANGES-219) Not specifying a date for a release causes "null" to be displayed in changes report
[ http://jira.codehaus.org/browse/MCHANGES-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250532#action_250532 ] Anders Hammar commented on MCHANGES-219: The method that needs to be updated is ChangesReportGenerator.constructReleases(). I believe that release.getDateRelease() returns null which is converted to the "null" text string. An simple fix would be to check if it returns null. > Not specifying a date for a release causes "null" to be displayed in changes > report > --- > > Key: MCHANGES-219 > URL: http://jira.codehaus.org/browse/MCHANGES-219 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes.xml >Affects Versions: 2.3 > Environment: Windows XP > Sun JDK 1.6.0_18 >Reporter: Anders Hammar > > If the date is not specified for a release, "null" is displayed in the header > of that release. For example, the header text for release 1.0.0 is "Release > 1.0.0 - null". > Note that the date is correctly left empty in the release table. > My suggestion is that if no date is specified, the header text should just be > "Release x.x.x". No dash and obviously no "null" text. :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-502) Multiple Parent-Links and additional module-link inherited wrong from parent
[
http://jira.codehaus.org/browse/MSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated MSITE-502:
Fix Version/s: 2.3
> Multiple Parent-Links and additional module-link inherited wrong from parent
>
>
> Key: MSITE-502
> URL: http://jira.codehaus.org/browse/MSITE-502
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: inheritance, multi module, site descriptor
>Affects Versions: 2.1.1
>Reporter: Michael Wenig
> Fix For: 2.3
>
> Attachments: siteInheritance.zip
>
>
> Attached is a couple of projects showing a problem with the site inheritance.
> The projects have the following structure:
> parentPom1
> -> projectA (parentPom2, with a submodule 'dummyModule' and attached site.xml)
> -> projectB (parentPom3)
> -> projectC (projectRoot with a submodule 'projectModule')
> I ran the following commands:
> parentPom1: install
> projectA: site site:attach-descriptor install
> projectB site install
> projectC site install
> I added the corresponding target-folders to the zip:
> projectA:
> generated correctly
> projectB:
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to parentPom2 (which is correct)
> projectC (root):
> shows two(!) parent links:
> -> to parentPom1 (which is wrong and IMHO inherited out of the attached
> site-descriptor)
> -> to projectB (which is correct)
> shows two modules:
> -> dummyModule (the one of projectA which is wrong and IMHO inherited out of
> the attached site-descriptor)
> -> projectModule (correct)
> ==> I expected the parent-Menu to only contain the direct parent
> ==> I expected the modules menu to only contain modules of the pom and not
> the modules of a parent...
> Content of the attached site descriptor:
> {code:xml}
> xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.1
> http://maven.apache.org/xsd/decoration-1.0.1.xsd";
> xmlns="http://maven.apache.org/DECORATION/1.0.1";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
>
>
>
>
>
>
>
> {code}
> I think the problem are the contained item-tags which are included in the
> sites of consumer projects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-488) site:deploy shouldn't repace variables from site.xml
[ http://jira.codehaus.org/browse/MSITE-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-488: Fix Version/s: 2.3 > site:deploy shouldn't repace variables from site.xml > > > Key: MSITE-488 > URL: http://jira.codehaus.org/browse/MSITE-488 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.1.1 >Reporter: Krashan Brahmanjara > Fix For: 2.3 > > > Action site:deploy pushes site.xml to external location. > This action works ok but parse original site description and send different > to server. > For example orignal site.xml contain line > > sended file contain line > > instead.. > I suppose that developers expect that original file will be commited to maven > repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-538) html issues in maven plugin goal report
html issues in maven plugin goal report --- Key: MSITE-538 URL: http://jira.codehaus.org/browse/MSITE-538 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Affects Versions: 3.0-beta-3, 2.2, 2.1.1, 2.1 Environment: Maven 2.2.1 (and 3.0.1 for site:3.0-beta-3) MacOS 10.6.x Mac Java JDK 1.6.0 Reporter: Anders Hammar Attachments: project.zip, Screen shot 2011-01-05 at 15.30.52.png There are html issues with the goal report of the plugin documentation caused by the site plugin, see attached screen shot. I've also attached a test project, which should reproduce this. I see this issue with m-site-p 2.1 and later, but not 2.0 or 2.0.1. I guess something was changed in the release of 2.1. Also note that this issue is seen with m-site-p 3.0-beta-3 (haven't tested beta-1 and beta-2, but I assume it exists there 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] Closed: (MNG-4919) Plugin execution contributed by lifecycle mapping gets lost when same goal is bound multiple times
[
http://jira.codehaus.org/browse/MNG-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4919.
--
Resolution: Fixed
Fix Version/s: 3.0.2
Assignee: Benjamin Bentmann
Fixed in [r1055486|http://svn.apache.org/viewvc?view=revision&revision=1055486]
by making implied execution ids are unique via index, {{default-goal}},
{{default-goal-1}}, etc.
> Plugin execution contributed by lifecycle mapping gets lost when same goal is
> bound multiple times
> --
>
> Key: MNG-4919
> URL: http://jira.codehaus.org/browse/MNG-4919
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle, POM
>Affects Versions: 3.0.1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 3.0.2
>
>
> When a plugin goal is implicitly bound twice from lifecycle mappings, the two
> goal executions get the same id and clash. This clash can eventually lead to
> all but one goal execution being lost (during model merging).
> Originally reported as
> [TYCHO-546|https://issues.sonatype.org/browse/TYCHO-546] where
> {{org.apache.maven.plugins:maven-clean-plugin:clean}} is bound once for the
> {{clean}} lifecycle (from Maven core) and once for the {{default}} lifecycle
> (from the build extension), both times using the execution id
> {{default-clean}}.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-538) html issues in maven plugin goal report
[ http://jira.codehaus.org/browse/MSITE-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-538. --- Resolution: Duplicate Assignee: Lukas Theussl > html issues in maven plugin goal report > --- > > Key: MSITE-538 > URL: http://jira.codehaus.org/browse/MSITE-538 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.1.1, 2.2, 3.0-beta-3 > Environment: Maven 2.2.1 (and 3.0.1 for site:3.0-beta-3) > MacOS 10.6.x > Mac Java JDK 1.6.0 >Reporter: Anders Hammar >Assignee: Lukas Theussl > Attachments: project.zip, Screen shot 2011-01-05 at 15.30.52.png > > > There are html issues with the goal report of the plugin documentation caused > by the site plugin, see attached screen shot. > I've also attached a test project, which should reproduce this. I see this > issue with m-site-p 2.1 and later, but not 2.0 or 2.0.1. I guess something > was changed in the release of 2.1. > Also note that this issue is seen with m-site-p 3.0-beta-3 (haven't tested > beta-1 and beta-2, but I assume it exists there 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] Created: (MNG-4959) Update default plugin versions
Update default plugin versions -- Key: MNG-4959 URL: http://jira.codehaus.org/browse/MNG-4959 Project: Maven 2 & 3 Issue Type: Task Components: Plugins and Lifecycle Affects Versions: 3.0.1 Reporter: Benjamin Bentmann Priority: Trivial The lifecycle mappings in Maven 3.0.1 currently default to Surefire 2.5, Kristian made a bunch of fixes since then which are worth to pick up. -- 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-4959) Update default plugin versions
[ http://jira.codehaus.org/browse/MNG-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4959. -- Resolution: Fixed Fix Version/s: 3.0.2 Assignee: Benjamin Bentmann Done in [r1055523|http://svn.apache.org/viewvc?view=revision&revision=1055523]. > Update default plugin versions > -- > > Key: MNG-4959 > URL: http://jira.codehaus.org/browse/MNG-4959 > Project: Maven 2 & 3 > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 3.0.1 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Trivial > Fix For: 3.0.2 > > > The lifecycle mappings in Maven 3.0.1 currently default to Surefire 2.5, > Kristian made a bunch of fixes since then which are worth to pick up. -- 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-539) Double quotes in fork call / long classpath
[ http://jira.codehaus.org/browse/SUREFIRE-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-539. --- Resolution: Fixed Fix Version/s: 2.6 Assignee: Kristian Rosenvold This was fixed with the upgrade of plexus-utils in r983693 > Double quotes in fork call / long classpath > --- > > Key: SUREFIRE-539 > URL: http://jira.codehaus.org/browse/SUREFIRE-539 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.4.3 > Environment: Windows XP SP3 >Reporter: Patrik Kleindl >Assignee: Kristian Rosenvold >Priority: Trivial > Fix For: 2.6 > > > We use a customized TestSuite for our test cases, it works fine when executed > in the IDE (Eclipse), but when i run mvn test then the test fails with a > nondescript > [INFO] [surefire:test] > [INFO] Surefire report directory: ... > [ERROR] There are test failures. > The config in pom.xml is > > org.apache.maven.plugins > maven-surefire-plugin > 2.4.3 > > -Xms500M -Xmx500M -Xmn250M > false > >testClasses after here > When i tried it from the commandline with the debug option i saw a big block > of text when then fork call happend, as mentioned in the documentation the > classpath was very long. Although this might be the root of the problem i > also noticed that the statement had double quotes which might not work > Forking command line: cmd.exe /X /C > "C:\Programme\Java\jdk1.5.0_16\jre\bin\java -Xms500M -Xmx500M -Xmn250M > -classpath "C:\" org.apache.maven.surefire.booter.SurefireBooter > tempFiles" > I cut out the long classpath and the file names after SurefireBooter but i > think you see what i mean > It's no big deal as it runs fine on Linux and on Windows you can always > execute it from the IDE. -- 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-227) site:deploy -> wrong links in ${modules} when artifactId=module's directory
[
http://jira.codehaus.org/browse/MSITE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250577#action_250577
]
Stefan Hansel commented on MSITE-227:
-
But why do I need a workaround (i.e. specifying an URL) at all?
In my project I am not specifying any URL in the poms so the site plugin
decides alone where to put each folder.
In my multimodule build it creates the following structure in the site-deploy
dir, when 'artifact-ID = project dirname':
|- parent
|- child1
|- child2
(with broken links)
If 'artifact-ID != project dirname' the following layout is created:
|- parent
|---|- child 1
|---|- child 1
(with working links)
I don't even care about the folder structure - but if the site plugin decides
for a certain folder structure, why isn't it generating the correct links for
it?
Sorry I'm very new to maven - but everyone told me it is about plugin-and-play.
Configure important stuff (and leave out all optional stuff, like 'URL'-tags,
because otherwise I don't do it the 'maven way').
So what is wrong when I expect the site plugin to create correct links when I
don't specify any optional URL tag in the POM?
The maven docs say "url: The URL, like the name, is not required." - so the
site plugin should obey that?
> site:deploy -> wrong links in ${modules} when artifactId=module's directory
> ---
>
> Key: MSITE-227
> URL: http://jira.codehaus.org/browse/MSITE-227
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5, 2.0
> Environment: Eclipse IDE
>Reporter: Guimiot Isabelle
>Assignee: Lukas Theussl
> Attachments: MSITE-227-working.zip, MSITE-227.zip
>
>
> I have a problem in the ${modules} part when I run the site:deploy goal.
> my project contains a root module and 2 sub-modules, at the same directory
> depth (I'm using Eclipse) :
> workspace/myRoot/
> workspace/myModule1/
> workspace/myModule2/
> my root pom contains this module declaration :
>
> ../myModule1
> ../myModule1
>
> the site:deploy goal gives this structure :
> [deploydir]/myRoot/index.html --> root's index
> [deploydir]/myRoot/myModule1/index.html --> first module's index
> [deploydir]/myRoot/myModule2/index.html --> second module's index
> when the project name (directory name in the workspace) and the artifactId
> are exactly the same, I have wrong links, both in root and in sub-modules
> pages :
> - in the root page, my links to submodules are like this :
> Modules
>
>
>myModule1
>
>
>myModule2
>
>
> - and in both modules pages, my link to the parent project is like this :
> Parent project
>
>
>myRoot
>
>
> The weirdest thing is that everything is fine when the artefactId and the
> eclipse project name (directory) are different !!! the problem appears only
> when they are identical...
> Thanks for your help !
--
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-227) site:deploy -> wrong links in ${modules} when artifactId=module's directory
[
http://jira.codehaus.org/browse/MSITE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250578#action_250578
]
Lukas Theussl commented on MSITE-227:
-
I totally agree with with everything you say, that's why I opened MSITE-535.
> site:deploy -> wrong links in ${modules} when artifactId=module's directory
> ---
>
> Key: MSITE-227
> URL: http://jira.codehaus.org/browse/MSITE-227
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5, 2.0
> Environment: Eclipse IDE
>Reporter: Guimiot Isabelle
>Assignee: Lukas Theussl
> Attachments: MSITE-227-working.zip, MSITE-227.zip
>
>
> I have a problem in the ${modules} part when I run the site:deploy goal.
> my project contains a root module and 2 sub-modules, at the same directory
> depth (I'm using Eclipse) :
> workspace/myRoot/
> workspace/myModule1/
> workspace/myModule2/
> my root pom contains this module declaration :
>
> ../myModule1
> ../myModule1
>
> the site:deploy goal gives this structure :
> [deploydir]/myRoot/index.html --> root's index
> [deploydir]/myRoot/myModule1/index.html --> first module's index
> [deploydir]/myRoot/myModule2/index.html --> second module's index
> when the project name (directory name in the workspace) and the artifactId
> are exactly the same, I have wrong links, both in root and in sub-modules
> pages :
> - in the root page, my links to submodules are like this :
> Modules
>
>
>myModule1
>
>
>myModule2
>
>
> - and in both modules pages, my link to the parent project is like this :
> Parent project
>
>
>myRoot
>
>
> The weirdest thing is that everything is fine when the artefactId and the
> eclipse project name (directory) are different !!! the problem appears only
> when they are identical...
> Thanks for your help !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MSITE-227) site:deploy -> wrong links in ${modules} when artifactId=module's directory
[
http://jira.codehaus.org/browse/MSITE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250578#action_250578
]
Lukas Theussl edited comment on MSITE-227 at 1/5/11 12:37 PM:
--
I totally agree with everything you say, that's why I opened MSITE-535.
was (Author: lukas):
I totally agree with with everything you say, that's why I opened MSITE-535.
> site:deploy -> wrong links in ${modules} when artifactId=module's directory
> ---
>
> Key: MSITE-227
> URL: http://jira.codehaus.org/browse/MSITE-227
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5, 2.0
> Environment: Eclipse IDE
>Reporter: Guimiot Isabelle
>Assignee: Lukas Theussl
> Attachments: MSITE-227-working.zip, MSITE-227.zip
>
>
> I have a problem in the ${modules} part when I run the site:deploy goal.
> my project contains a root module and 2 sub-modules, at the same directory
> depth (I'm using Eclipse) :
> workspace/myRoot/
> workspace/myModule1/
> workspace/myModule2/
> my root pom contains this module declaration :
>
> ../myModule1
> ../myModule1
>
> the site:deploy goal gives this structure :
> [deploydir]/myRoot/index.html --> root's index
> [deploydir]/myRoot/myModule1/index.html --> first module's index
> [deploydir]/myRoot/myModule2/index.html --> second module's index
> when the project name (directory name in the workspace) and the artifactId
> are exactly the same, I have wrong links, both in root and in sub-modules
> pages :
> - in the root page, my links to submodules are like this :
> Modules
>
>
>myModule1
>
>
>myModule2
>
>
> - and in both modules pages, my link to the parent project is like this :
> Parent project
>
>
>myRoot
>
>
> The weirdest thing is that everything is fine when the artefactId and the
> eclipse project name (directory) are different !!! the problem appears only
> when they are identical...
> Thanks for your help !
--
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-227) site:deploy -> wrong links in ${modules} when artifactId=module's directory
[
http://jira.codehaus.org/browse/MSITE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250579#action_250579
]
Stefan Hansel commented on MSITE-227:
-
Would it be a temporary workaround to have the site-plugin just create the same
folder structure regardless of whether artifactID matches the folder-name of
the project?
> site:deploy -> wrong links in ${modules} when artifactId=module's directory
> ---
>
> Key: MSITE-227
> URL: http://jira.codehaus.org/browse/MSITE-227
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5, 2.0
> Environment: Eclipse IDE
>Reporter: Guimiot Isabelle
>Assignee: Lukas Theussl
> Attachments: MSITE-227-working.zip, MSITE-227.zip
>
>
> I have a problem in the ${modules} part when I run the site:deploy goal.
> my project contains a root module and 2 sub-modules, at the same directory
> depth (I'm using Eclipse) :
> workspace/myRoot/
> workspace/myModule1/
> workspace/myModule2/
> my root pom contains this module declaration :
>
> ../myModule1
> ../myModule1
>
> the site:deploy goal gives this structure :
> [deploydir]/myRoot/index.html --> root's index
> [deploydir]/myRoot/myModule1/index.html --> first module's index
> [deploydir]/myRoot/myModule2/index.html --> second module's index
> when the project name (directory name in the workspace) and the artifactId
> are exactly the same, I have wrong links, both in root and in sub-modules
> pages :
> - in the root page, my links to submodules are like this :
> Modules
>
>
>myModule1
>
>
>myModule2
>
>
> - and in both modules pages, my link to the parent project is like this :
> Parent project
>
>
>myRoot
>
>
> The weirdest thing is that everything is fine when the artefactId and the
> eclipse project name (directory) are different !!! the problem appears only
> when they are identical...
> Thanks for your help !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MSITE-227) site:deploy -> wrong links in ${modules} when artifactId=module's directory
[
http://jira.codehaus.org/browse/MSITE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250579#action_250579
]
Stefan Hansel edited comment on MSITE-227 at 1/5/11 12:42 PM:
--
Would it be a temporary workaround to have the site-plugin just create the same
folder structure regardless of whether artifactID matches the folder-name of
the project?
It's so depressing it already works like I'd expect it in a certain
configuration.
How much can I expect MISTE-535 to be resolved. Sounds like a change that
breaks backwards compatiblity - are you really going to do that?
was (Author: stefan.han...@tolina.de):
Would it be a temporary workaround to have the site-plugin just create the
same folder structure regardless of whether artifactID matches the folder-name
of the project?
> site:deploy -> wrong links in ${modules} when artifactId=module's directory
> ---
>
> Key: MSITE-227
> URL: http://jira.codehaus.org/browse/MSITE-227
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5, 2.0
> Environment: Eclipse IDE
>Reporter: Guimiot Isabelle
>Assignee: Lukas Theussl
> Attachments: MSITE-227-working.zip, MSITE-227.zip
>
>
> I have a problem in the ${modules} part when I run the site:deploy goal.
> my project contains a root module and 2 sub-modules, at the same directory
> depth (I'm using Eclipse) :
> workspace/myRoot/
> workspace/myModule1/
> workspace/myModule2/
> my root pom contains this module declaration :
>
> ../myModule1
> ../myModule1
>
> the site:deploy goal gives this structure :
> [deploydir]/myRoot/index.html --> root's index
> [deploydir]/myRoot/myModule1/index.html --> first module's index
> [deploydir]/myRoot/myModule2/index.html --> second module's index
> when the project name (directory name in the workspace) and the artifactId
> are exactly the same, I have wrong links, both in root and in sub-modules
> pages :
> - in the root page, my links to submodules are like this :
> Modules
>
>
>myModule1
>
>
>myModule2
>
>
> - and in both modules pages, my link to the parent project is like this :
> Parent project
>
>
>myRoot
>
>
> The weirdest thing is that everything is fine when the artefactId and the
> eclipse project name (directory) are different !!! the problem appears only
> when they are identical...
> Thanks for your help !
--
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-219) Not specifying a date for a release causes "null" to be displayed in changes report
[ http://jira.codehaus.org/browse/MCHANGES-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MCHANGES-219. -- Resolution: Fixed Fix Version/s: 2.4 Assignee: Lukas Theussl Fixed in [r1055577|http://svn.apache.org/viewvc?rev=1055577&view=rev] > Not specifying a date for a release causes "null" to be displayed in changes > report > --- > > Key: MCHANGES-219 > URL: http://jira.codehaus.org/browse/MCHANGES-219 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes.xml >Affects Versions: 2.3 > Environment: Windows XP > Sun JDK 1.6.0_18 >Reporter: Anders Hammar >Assignee: Lukas Theussl > Fix For: 2.4 > > > If the date is not specified for a release, "null" is displayed in the header > of that release. For example, the header text for release 1.0.0 is "Release > 1.0.0 - null". > Note that the date is correctly left empty in the release table. > My suggestion is that if no date is specified, the header text should just be > "Release x.x.x". No dash and obviously no "null" text. :-) -- 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: (MASSEMBLY-538) filtering broken in files containing '@'
filtering broken in files containing '@'
Key: MASSEMBLY-538
URL: http://jira.codehaus.org/browse/MASSEMBLY-538
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: mvn -v
Apache Maven 2.2.1 (rNON-CANONICAL_2010-08-13_17-44_abuild; 2010-08-13
19:44:44+0200)
Java version: 1.6.0_22
Java home: /usr/lib64/jvm/java-1.6.0-sun-1.6.0/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux" version: "2.6.34.7-0.7-desktop" arch: "amd64" Family: "unix"
Reporter: Alexander Rettig
Priority: Minor
Attachments: filter-test-1.0.zip
Files containing the '@' sign as eg within e-mail URLs are only filtered up to
the occurrence of this sign.
To check this, unpack the attached ZIP, cd into the created directory
'filter-test-01' and run
mvn assembly:single
The created target/filter-test-1.0-filtertest.zip contains a README, which has
only the first occurrence of ${project.artifactId} replaced, but not the second
one.
--
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-227) site:deploy -> wrong links in ${modules} when artifactId=module's directory
[
http://jira.codehaus.org/browse/MSITE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250582#action_250582
]
Lukas Theussl commented on MSITE-227:
-
bq. Would it be a temporary workaround to have the site-plugin just create the
same folder structure regardless of whether artifactID matches the folder-name
of the project?
That's exactly equivalent to implementing MSITE-535 since the folder structure
is determined by distributionManagement.site.url
bq. How much can I expect MISTE-535 to be resolved.
I just scheduled it for the next release, I am currently looking at all these
deploy/relative link related issues. But I'm a slow worker, so don't ask me for
a release date ;)
> site:deploy -> wrong links in ${modules} when artifactId=module's directory
> ---
>
> Key: MSITE-227
> URL: http://jira.codehaus.org/browse/MSITE-227
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5, 2.0
> Environment: Eclipse IDE
>Reporter: Guimiot Isabelle
>Assignee: Lukas Theussl
> Attachments: MSITE-227-working.zip, MSITE-227.zip
>
>
> I have a problem in the ${modules} part when I run the site:deploy goal.
> my project contains a root module and 2 sub-modules, at the same directory
> depth (I'm using Eclipse) :
> workspace/myRoot/
> workspace/myModule1/
> workspace/myModule2/
> my root pom contains this module declaration :
>
> ../myModule1
> ../myModule1
>
> the site:deploy goal gives this structure :
> [deploydir]/myRoot/index.html --> root's index
> [deploydir]/myRoot/myModule1/index.html --> first module's index
> [deploydir]/myRoot/myModule2/index.html --> second module's index
> when the project name (directory name in the workspace) and the artifactId
> are exactly the same, I have wrong links, both in root and in sub-modules
> pages :
> - in the root page, my links to submodules are like this :
> Modules
>
>
>myModule1
>
>
>myModule2
>
>
> - and in both modules pages, my link to the parent project is like this :
> Parent project
>
>
>myRoot
>
>
> The weirdest thing is that everything is fine when the artefactId and the
> eclipse project name (directory) are different !!! the problem appears only
> when they are identical...
> Thanks for your help !
--
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-4960) Maven3 behaves differently than Maven2 when building a multi-module enterprise project on command line
Maven3 behaves differently than Maven2 when building a multi-module enterprise
project on command line
--
Key: MNG-4960
URL: http://jira.codehaus.org/browse/MNG-4960
Project: Maven 2 & 3
Issue Type: Bug
Components: Command Line
Affects Versions: 3.0.1, 3.0
Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 02:58:32-0800)
Java version: 1.6.0_19
OS name: Windows XP/Vista
Reporter: Sujit Kabbinahally
Attachments: Maven3 Command Line.zip
As of now in Maven2 (2.2.1) we are able to build a multi-module enterprise
project as explained below and the same does not work in Maven3 (3.0.1) after
the migration.
Basically in the multi-module enterprise project, we build multiple ear's with
their own dependents and each one of these EAR's is built as its own module by
inheriting properties/attributes etc from the parent pom at the base level of
the whole project.
In Maven2, the below command to accomplish the above explanation works as
expected when initiated from the ${project.basedir} of the main project.
mvn -pl ear_module -am -rf first_dependent_module clean install -P
@ build time, the reactor lists the build order as shown below
1. first_dependent_module
2. second_dependent_module
3. ear_module
Option '-rf' is used to NOT delete the target folder at the main
${project.basedir} since we want to still keep the output from the build of
another EAR and its dependents.
With Maven3, however, the reactor lists the build order as shown below:
1. first_dependent_module
2. second_dependent_module
Maven3 ignores the argument (ear_module) set to '-pl' option to be also built
after its dependents have been.
This behavior can be made to work only if '-rf' option is removed from the
command and i.e. call 'mvn -pl ear_module -am clean install -P '
which defeats the whole purpose of NOT deleting the 'target' folder under under
base ${project.basedir}.
Attached doc has screen shots to display the behavior explained above for all
cases.
--
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-4960) Maven3 behaves differently than Maven2 when building a multi-module enterprise project on command line
[
http://jira.codehaus.org/browse/MNG-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sujit Kabbinahally updated MNG-4960:
Attachment: Maven3 Command Line.zip
Please ignore the initial attachment as the comments in it are wrong and use
this instead.
Thanks
> Maven3 behaves differently than Maven2 when building a multi-module
> enterprise project on command line
> --
>
> Key: MNG-4960
> URL: http://jira.codehaus.org/browse/MNG-4960
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0, 3.0.1
> Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 02:58:32-0800)
> Java version: 1.6.0_19
> OS name: Windows XP/Vista
>Reporter: Sujit Kabbinahally
> Attachments: Maven3 Command Line.zip, Maven3 Command Line.zip
>
>
> As of now in Maven2 (2.2.1) we are able to build a multi-module enterprise
> project as explained below and the same does not work in Maven3 (3.0.1) after
> the migration.
> Basically in the multi-module enterprise project, we build multiple ear's
> with their own dependents and each one of these EAR's is built as its own
> module by inheriting properties/attributes etc from the parent pom at the
> base level of the whole project.
> In Maven2, the below command to accomplish the above explanation works as
> expected when initiated from the ${project.basedir} of the main project.
> mvn -pl ear_module -am -rf first_dependent_module clean install -P
> @ build time, the reactor lists the build order as shown below
>1. first_dependent_module
>2. second_dependent_module
>3. ear_module
> Option '-rf' is used to NOT delete the target folder at the main
> ${project.basedir} since we want to still keep the output from the build of
> another EAR and its dependents.
> With Maven3, however, the reactor lists the build order as shown below:
>1. first_dependent_module
>2. second_dependent_module
> Maven3 ignores the argument (ear_module) set to '-pl' option to be also built
> after its dependents have been.
>
> This behavior can be made to work only if '-rf' option is removed from the
> command and i.e. call 'mvn -pl ear_module -am clean install -P '
> which defeats the whole purpose of NOT deleting the 'target' folder under
> under base ${project.basedir}.
> Attached doc has screen shots to display the behavior explained above for all
> cases.
--
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: (MCHANGES-218) Downloading from JIRA fails if issueManagement.url has trailing slash
[
http://jira.codehaus.org/browse/MCHANGES-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250587#action_250587
]
Dennis Lundberg commented on MCHANGES-218:
--
This is a known limitation that is somewhat documented in the "Linking to Your
Issue Management System" section at
http://maven.apache.org/plugins/maven-changes-plugin/usage.html
The documentation is of course in the wrong place for your use case.
I'll take a look and see if I can try to fix the parsing routine. If now at
least the docs should be improved to highlight this better.
> Downloading from JIRA fails if issueManagement.url has trailing slash
> -
>
> Key: MCHANGES-218
> URL: http://jira.codehaus.org/browse/MCHANGES-218
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: jira
>Affects Versions: 2.3
>Reporter: Lukas Theussl
>
> With an issueManagement.url like http://jira.codehaus.org/browse/DOXIA/ (note
> trailing slash), the jira report chokes
> {noformat}
> [WARNING] Downloading from JIRA failed. Received: [404]
> {noformat}
> and an empty report is generated. removing the trailing slash makes it work.
--
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: (SCM-595) Allow to use BASE in revision range for changelog command
[ http://jira.codehaus.org/browse/SCM-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-595: - Fix Version/s: 1.5 Assignee: Olivier Lamy > Allow to use BASE in revision range for changelog command > - > > Key: SCM-595 > URL: http://jira.codehaus.org/browse/SCM-595 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-svn >Reporter: Evgeny Mandrikov >Assignee: Olivier Lamy > Fix For: 1.5 > > -- 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-610) Surefire plugin aborts if target directory contains files/dirs
[ http://jira.codehaus.org/browse/SUREFIRE-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250596#action_250596 ] Kristian Rosenvold commented on SUREFIRE-610: - The full configuration settings for the plugin will be needed to fix this one. Can you also re-confirm that this happens on BOTH linux and windows ? Can you also re-test with 2.7.1 ? > Surefire plugin aborts if target directory contains files/dirs > -- > > Key: SUREFIRE-610 > URL: http://jira.codehaus.org/browse/SUREFIRE-610 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.5 > Environment: Windows XP, Windows 2003k, Ubuntu, Maven 2.0.9, Maven > 2.2.1 >Reporter: Randall Fidler > > If there are files in the target directory when the plugin is run, > specifically when tests are run inconjunction with the release:perform plugin > goal, the plugin seems to simply terminate. The overall build is failed due > to there being test failures, but the build shows no test failures (i.e. <<< > FAILURE!) and none of the surefire reports list any test failures. It's > important to note that there will be only part of your test reports you > expect (say 50%) as the plugin appears to stop before it has executed all > tests. I believe what occurs is the plugin tries to create a report, say for > test G, and finds in the target directory that the reports files for test G > already exist that's where it pukes. As a result, you will have reports for > tests A-F and nothing more; all of these reports will NOT list any > error/failure. Also important to note is that there is no summary you > usually see, i.e. Tests: 100 Failures: 0 Errors: 0, after the surefire plugin > runs - you only see the stats for the last test and then information from the > "main" maven thread saying the build failed due to test failures. > It would be ideal if: > a) the surefire plugin could remove any surefire reports prior to execution > or > b) fail the build but provide a reason why, e.g. "could not write the test > report for test G" -- 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-587) Doesn't run tests if they don't end with Test
[ http://jira.codehaus.org/browse/SUREFIRE-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-587: Priority: Major (was: Critical) > Doesn't run tests if they don't end with Test > - > > Key: SUREFIRE-587 > URL: http://jira.codehaus.org/browse/SUREFIRE-587 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support, Junit 4.x support >Affects Versions: 2.4.3 > Environment: N/A >Reporter: David J. M. Karlsen > > We have a mix of test - some purely junit4 (e.g. not extending anything and > annotating with @Test) - and some which extends TestCase. > I've discovered that the ones extending TestCase won't run if the classname > doesn't end with Test - so that the class CommonsAttributesParserTests won't > get included (notice the ending "s"). -- 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-4960) Maven3 behaves differently than Maven2 when building a multi-module enterprise project on command line
[
http://jira.codehaus.org/browse/MNG-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4960:
---
Attachment: MNG-4960.zip
Can you confirm that the attached demo project reproduces your issue upon
invocation of {{mvn -pl sub-2 -am -rf sub-1 clean}} of? If not, could you
please attach a minimal example project that can be used to reproduce the issue?
> Maven3 behaves differently than Maven2 when building a multi-module
> enterprise project on command line
> --
>
> Key: MNG-4960
> URL: http://jira.codehaus.org/browse/MNG-4960
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0, 3.0.1
> Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 02:58:32-0800)
> Java version: 1.6.0_19
> OS name: Windows XP/Vista
>Reporter: Sujit Kabbinahally
> Attachments: Maven3 Command Line.zip, Maven3 Command Line.zip,
> MNG-4960.zip
>
>
> As of now in Maven2 (2.2.1) we are able to build a multi-module enterprise
> project as explained below and the same does not work in Maven3 (3.0.1) after
> the migration.
> Basically in the multi-module enterprise project, we build multiple ear's
> with their own dependents and each one of these EAR's is built as its own
> module by inheriting properties/attributes etc from the parent pom at the
> base level of the whole project.
> In Maven2, the below command to accomplish the above explanation works as
> expected when initiated from the ${project.basedir} of the main project.
> mvn -pl ear_module -am -rf first_dependent_module clean install -P
> @ build time, the reactor lists the build order as shown below
>1. first_dependent_module
>2. second_dependent_module
>3. ear_module
> Option '-rf' is used to NOT delete the target folder at the main
> ${project.basedir} since we want to still keep the output from the build of
> another EAR and its dependents.
> With Maven3, however, the reactor lists the build order as shown below:
>1. first_dependent_module
>2. second_dependent_module
> Maven3 ignores the argument (ear_module) set to '-pl' option to be also built
> after its dependents have been.
>
> This behavior can be made to work only if '-rf' option is removed from the
> command and i.e. call 'mvn -pl ear_module -am clean install -P '
> which defeats the whole purpose of NOT deleting the 'target' folder under
> under base ${project.basedir}.
> Attached doc has screen shots to display the behavior explained above for all
> cases.
--
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-4961) CLONE -Dependency exclusions not always honored for dependencies with classifier
CLONE -Dependency exclusions not always honored for dependencies with classifier
Key: MNG-4961
URL: http://jira.codehaus.org/browse/MNG-4961
Project: Maven 2 & 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.2.1
Environment: Windows 7 64bit, Java 1.6 32bit
Reporter: Sunil Kumar Dhage
Assignee: Benjamin Bentmann
Priority: Blocker
Like the summary says, I've encountered and tracked down a bug that prevents
dependency exclusions from being honored by plugins when the dependency with
the exclusions has a classifier. This seems to only occur or surface in
multi-module builds.
For example, I have a multi-module project structured as follows:
{noformat}
myproj-parent
myproj-a
myproj-b
{noformat}
If {{myproj-a}} produces a classified artifact (say, an obfuscated JAR via
ProGuard) and {{myproj-b}} has it as a dependency with exclusions, those
exclusions will not be honored by plugins run in {{myproj-b}} (say, the
webstart plugin).
I think I've tracked the problem down to the {{replaceWithActiveArtifact(...)}}
method of {{org.apache.maven.project.MavenProject}}. Specifically, see [lines
1772 through
1784|http://maven.apache.org/ref/2.2.1/xref/org/apache/maven/project/MavenProject.html#1772].
The following {{if}} clause does not account for artifacts with classifiers:
{noformat}
if ( ref.getArtifact() != null
&& ref.getArtifact().getDependencyConflictId().equals(
pluginArtifact.getDependencyConflictId() ) )
{noformat}
Because the classified {{pluginArtifact}} does not match the _main_ artifact of
{{ref}}, the artifact is not resolved from the currently building project's
dependencies. As the method continues, it is instead resolved with
{{myproj-a}}'s "standard" metadata, which of course don't include the
exclusions in {{myproj-b}}.
I've marked this bug a blocker because I can't think of a way around it and
it's badly polluting one of my project's builds. Due to it, a webstart build
that only needs 30 artifacts has over 100. I have not yet tried to reproduce it
in Maven 3.x because our company likely won't be moving to it for a couple of
months.
--
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-4961) CLONE -Dependency exclusions not always honored for dependencies with classifier
[
http://jira.codehaus.org/browse/MNG-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250634#action_250634
]
Sunil Kumar Dhage commented on MNG-4961:
Hi Benjamin,
I have created clone of MNG 4872, since the fix version(3.0-beta-1) provided
for the issue did not have this issue actually fixed. or might not have
included the bug id in the release notes.
If it has been taken care of, please update the release notes of 3.0-beta-1 or
PLEASE avoid closing issues before they actually fixing the same.
> CLONE -Dependency exclusions not always honored for dependencies with
> classifier
>
>
> Key: MNG-4961
> URL: http://jira.codehaus.org/browse/MNG-4961
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.2.1
> Environment: Windows 7 64bit, Java 1.6 32bit
>Reporter: Sunil Kumar Dhage
>Assignee: Benjamin Bentmann
>Priority: Blocker
>
> Like the summary says, I've encountered and tracked down a bug that prevents
> dependency exclusions from being honored by plugins when the dependency with
> the exclusions has a classifier. This seems to only occur or surface in
> multi-module builds.
> For example, I have a multi-module project structured as follows:
> {noformat}
> myproj-parent
> myproj-a
> myproj-b
> {noformat}
> If {{myproj-a}} produces a classified artifact (say, an obfuscated JAR via
> ProGuard) and {{myproj-b}} has it as a dependency with exclusions, those
> exclusions will not be honored by plugins run in {{myproj-b}} (say, the
> webstart plugin).
> I think I've tracked the problem down to the
> {{replaceWithActiveArtifact(...)}} method of
> {{org.apache.maven.project.MavenProject}}. Specifically, see [lines 1772
> through
> 1784|http://maven.apache.org/ref/2.2.1/xref/org/apache/maven/project/MavenProject.html#1772].
> The following {{if}} clause does not account for artifacts with classifiers:
> {noformat}
> if ( ref.getArtifact() != null
> && ref.getArtifact().getDependencyConflictId().equals(
> pluginArtifact.getDependencyConflictId() ) )
> {noformat}
> Because the classified {{pluginArtifact}} does not match the _main_ artifact
> of {{ref}}, the artifact is not resolved from the currently building
> project's dependencies. As the method continues, it is instead resolved with
> {{myproj-a}}'s "standard" metadata, which of course don't include the
> exclusions in {{myproj-b}}.
> I've marked this bug a blocker because I can't think of a way around it and
> it's badly polluting one of my project's builds. Due to it, a webstart build
> that only needs 30 artifacts has over 100. I have not yet tried to reproduce
> it in Maven 3.x because our company likely won't be moving to it for a couple
> of months.
--
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-246) NullPointerException Processing Web Resources
[ http://jira.codehaus.org/browse/MWAR-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MWAR-246: - Fix Version/s: 2.2 > NullPointerException Processing Web Resources > - > > Key: MWAR-246 > URL: http://jira.codehaus.org/browse/MWAR-246 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Linux, JDK 6 >Reporter: Gary Murphy > Fix For: 2.2 > > > NullPointerException on packaging of web resources. Configuration is: > > maven-war-plugin > > > > >xercesImpl-*.jar > > > > > > Stack trace is: > Execution default-war of goal > org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war > failed. > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:116) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) > ... 19 more > Caused by: java.lang.NullPointerException > at java.io.File.(File.java:222) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleWebResources(WarProjectPackagingTask.java:124) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:91) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:472) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:404) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:197) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:159) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) > ... 20 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: (MWAR-246) NullPointerException Processing Web Resources
[ http://jira.codehaus.org/browse/MWAR-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250636#action_250636 ] Stephane Nicoll commented on MWAR-246: -- you miss the directory. webResources is just a regular resource section. That being said, the plugin should fail with a proper error message. What are you trying to accomplish exactly? Remove stuff from the generated war? You may want to look at packagingExcludes http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#packagingExcludes > NullPointerException Processing Web Resources > - > > Key: MWAR-246 > URL: http://jira.codehaus.org/browse/MWAR-246 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Linux, JDK 6 >Reporter: Gary Murphy > Fix For: 2.2 > > > NullPointerException on packaging of web resources. Configuration is: > > maven-war-plugin > > > > >xercesImpl-*.jar > > > > > > Stack trace is: > Execution default-war of goal > org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war > failed. > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:116) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) > ... 19 more > Caused by: java.lang.NullPointerException > at java.io.File.(File.java:222) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleWebResources(WarProjectPackagingTask.java:124) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:91) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:472) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:404) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:197) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:159) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) > ... 20 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] Closed: (MCHANGES-218) Downloading from JIRA fails if issueManagement.url has trailing slash
[
http://jira.codehaus.org/browse/MCHANGES-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MCHANGES-218.
--
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Lukas Theussl
Hacked it out: [r1055775|http://svn.apache.org/viewvc?rev=1055775&view=rev]
> Downloading from JIRA fails if issueManagement.url has trailing slash
> -
>
> Key: MCHANGES-218
> URL: http://jira.codehaus.org/browse/MCHANGES-218
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: jira
>Affects Versions: 2.3
>Reporter: Lukas Theussl
>Assignee: Lukas Theussl
> Fix For: 2.4
>
>
> With an issueManagement.url like http://jira.codehaus.org/browse/DOXIA/ (note
> trailing slash), the jira report chokes
> {noformat}
> [WARNING] Downloading from JIRA failed. Received: [404]
> {noformat}
> and an empty report is generated. removing the trailing slash makes it work.
--
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: (MCHANGES-217) wrong sorting order in jira report
[ http://jira.codehaus.org/browse/MCHANGES-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250639#action_250639 ] Lukas Theussl commented on MCHANGES-217: Maybe this depends on the JIRA version. There is a comment in the sorting routine in AbstractJiraDownloader that says: bq. // N.B. Add in reverse order (it's the way JIRA likes it!!) Has the behavior changed in a certain JIRA version? > wrong sorting order in jira report > -- > > Key: MCHANGES-217 > URL: http://jira.codehaus.org/browse/MCHANGES-217 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira >Affects Versions: 2.3 >Reporter: Lukas Theussl > Attachments: MCHANGES-217.zip > > > From the > [documentation|http://maven.apache.org/plugins/maven-changes-plugin/jira-report-mojo.html#sortColumnNames]: > 'Fix Version DESC, Type sorts first by the Fix Version in descending order > and then by Type in ascending order'. The actual result is however the other > way round: the sorting by type is done first. -- 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
