[jira] Closed: (SCM-591) Move to Java 1.5
[ http://jira.codehaus.org/browse/SCM-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-591. Resolution: Fixed Move to Java 1.5 Key: SCM-591 URL: http://jira.codehaus.org/browse/SCM-591 Project: Maven SCM Issue Type: Improvement Components: maven-scm-api Affects Versions: 1.4 Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 1.5 As the main scm consumer is in 1.5 (release plugin), we can move this to 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] Created: (MARCHETYPES-37) The POM of generated projects should have xml prolog/header specifying encoding
The POM of generated projects should have xml prolog/header specifying encoding --- Key: MARCHETYPES-37 URL: http://jira.codehaus.org/browse/MARCHETYPES-37 Project: Maven Archetype Bundles Issue Type: Improvement Components: Maven Archetype Archetype, Maven Plugin Archetype, Maven Plugin Site Archetype, Maven Portlet Archetype, Maven Quickstart Archetype, Maven Simple J2EE Archetype, Maven Simple Project Archetype, Maven Simple Site Archetype, Maven Site Archetype, Maven Webapp Archetype Environment: n/a Reporter: Anders Hammar Attachments: archetypes.patch The POM generated by the archetypes should have an xml prolog/header specifying encoding. For anyone using non-ascii chars this is important as it will ensure that chars are handled correctly. I've attached a patch for this. Changes are relative the top level archetypes project trunk. -- 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: (MARCHETYPES-37) The POM of generated projects should have xml prolog/header specifying encoding
[ http://jira.codehaus.org/browse/MARCHETYPES-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251579#action_251579 ] Anders Hammar commented on MARCHETYPES-37: -- There is no fix for the Simple Project Archetype (maven-archetype-simple), as I couldn't find a pom (nor understand its structure). Please remove it from the listed components for this jira! The POM of generated projects should have xml prolog/header specifying encoding --- Key: MARCHETYPES-37 URL: http://jira.codehaus.org/browse/MARCHETYPES-37 Project: Maven Archetype Bundles Issue Type: Improvement Components: Maven Archetype Archetype, Maven Plugin Archetype, Maven Plugin Site Archetype, Maven Portlet Archetype, Maven Quickstart Archetype, Maven Simple J2EE Archetype, Maven Simple Project Archetype, Maven Simple Site Archetype, Maven Site Archetype, Maven Webapp Archetype Environment: n/a Reporter: Anders Hammar Attachments: archetypes.patch The POM generated by the archetypes should have an xml prolog/header specifying encoding. For anyone using non-ascii chars this is important as it will ensure that chars are handled correctly. I've attached a patch for this. Changes are relative the top level archetypes project trunk. -- 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-4978) [Documentation] Reactor sorting
[Documentation] Reactor sorting
---
Key: MNG-4978
URL: http://jira.codehaus.org/browse/MNG-4978
Project: Maven 2 3
Issue Type: Bug
Components: Documentation: Guides
Affects Versions: 3.0.1
Reporter: Andrey Vorobiev
Guide to Working with Multiple Modules
(http://maven.apache.org/guides/mini/guide-multiple-modules.html) says:
The following relationships are honoured when sorting projects:
a project dependency on another module in the build
a plugin declaration where the plugin is another modules in the build
a plugin dependency on another module in the build
a build extension declaration on another module in the build
the order declared in the modules element (if no other rule applies)
and what's about parent pom relation?
For instance we have three modules:
- parent
- child-1
- child-2
parent module is specified as parent pom for modules child-1 and child-2:
parent
...
artifactIdparent/artifactId
...
/parent
Also we have aggregator module with contents:
project
...
modules
modulepath to parent module/module
modulepath to child-1 module/module
modulepath to child-2 module/module
/modules
...
/project
Next we type: mvn clean install
Can it be guaranteed that parent module will be builded and installed into
local repository before child-1 and child-2 modules?
The same question but in case of multithreaded execution (-T option is
provided)?
As far as I understand from source
maven-core/src/main/java/org/apache/maven/project/ProjectSorter.java it can:
...
Parent parent = project.getModel().getParent();
if ( parent != null )
{
// Parent is added as an edge, but must not cause a cycle - so we remove any
other edges it has
// in conflict
addEdge( projectMap, vertexMap, null, projectVertex, parent.getGroupId(),
parent.getArtifactId(),
parent.getVersion(), true, false );
}
...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-139) New option to avoid empty jar creation
[ http://jira.codehaus.org/browse/MJAR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251591#action_251591 ] Falko Modler commented on MJAR-139: --- I'd prefer the addition of the skip parameter for jar:jar. Adding another packing might be too invasive... New option to avoid empty jar creation -- Key: MJAR-139 URL: http://jira.codehaus.org/browse/MJAR-139 Project: Maven 2.x Jar Plugin Issue Type: Improvement Affects Versions: 2.3.1 Reporter: Roman Ivanov Usage of test-jar is beneficial for all project, as all of them have tests. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.3.1/version executions execution goals goaltest-jar/goal /goals /execution /executions /plugin Pom artifacts and some jar artifacts does not have test and will never have them. In logs we have: [WARNING] JAR will be empty - no content was marked for inclusion! and empty and useless artifacts are created, deployed , ... It will be convenient to have an plugin option to define whether skip empty jar creation and warning or generate jar with warning in log. Does it make sense ? By default option will be FALSE, to comply with previous behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MJAR-139) New option to avoid empty jar creation
[ http://jira.codehaus.org/browse/MJAR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251591#action_251591 ] Falko Modler edited comment on MJAR-139 at 1/14/11 4:50 AM: I'd prefer the addition of the skip parameter for jar:jar. Adding another packaging might be too invasive... was (Author: famod): I'd prefer the addition of the skip parameter for jar:jar. Adding another packing might be too invasive... New option to avoid empty jar creation -- Key: MJAR-139 URL: http://jira.codehaus.org/browse/MJAR-139 Project: Maven 2.x Jar Plugin Issue Type: Improvement Affects Versions: 2.3.1 Reporter: Roman Ivanov Usage of test-jar is beneficial for all project, as all of them have tests. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.3.1/version executions execution goals goaltest-jar/goal /goals /execution /executions /plugin Pom artifacts and some jar artifacts does not have test and will never have them. In logs we have: [WARNING] JAR will be empty - no content was marked for inclusion! and empty and useless artifacts are created, deployed , ... It will be convenient to have an plugin option to define whether skip empty jar creation and warning or generate jar with warning in log. Does it make sense ? By default option will be FALSE, to comply with previous behavior. -- 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: (MPLUGIN-173) Start using net.sf.jtidy artifact with correct I/O encoding
[ http://jira.codehaus.org/browse/MPLUGIN-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251593#action_251593 ] Anders Hammar commented on MPLUGIN-173: --- I don't like how encoding is hard-coded in this patch. Start using net.sf.jtidy artifact with correct I/O encoding --- Key: MPLUGIN-173 URL: http://jira.codehaus.org/browse/MPLUGIN-173 Project: Maven 2.x Plugin Tools Issue Type: Improvement Components: API Affects Versions: 2.6 Reporter: Stanislav Ochotnicky Attachments: 0001-fix-for-new-jtidy.patch Current 2.6 version uses jtidy:jtidy artifact which is not being developed anymore. net.sf.jtidy:jtidy artifact provides more features and is actively developed. This patch replaces old artifact with new one and fixes -api to not use deprecated functions for I/O encoding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MNGSITE-126) [Documentation] Reactor sorting
[
http://jira.codehaus.org/browse/MNGSITE-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann moved MNG-4978 to MNGSITE-126:
Complexity: (was: Intermediate)
Component/s: (was: Documentation: Guides)
Affects Version/s: (was: 3.0.1)
Issue Type: Improvement (was: Bug)
Key: MNGSITE-126 (was: MNG-4978)
Project: Maven Project Web Site (was: Maven 2 3)
[Documentation] Reactor sorting
---
Key: MNGSITE-126
URL: http://jira.codehaus.org/browse/MNGSITE-126
Project: Maven Project Web Site
Issue Type: Improvement
Reporter: Andrey Vorobiev
Guide to Working with Multiple Modules
(http://maven.apache.org/guides/mini/guide-multiple-modules.html) says:
The following relationships are honoured when sorting projects:
a project dependency on another module in the build
a plugin declaration where the plugin is another modules in the build
a plugin dependency on another module in the build
a build extension declaration on another module in the build
the order declared in the modules element (if no other rule applies)
and what's about parent pom relation?
For instance we have three modules:
- parent
- child-1
- child-2
parent module is specified as parent pom for modules child-1 and
child-2:
parent
...
artifactIdparent/artifactId
...
/parent
Also we have aggregator module with contents:
project
...
modules
modulepath to parent module/module
modulepath to child-1 module/module
modulepath to child-2 module/module
/modules
...
/project
Next we type: mvn clean install
Can it be guaranteed that parent module will be builded and installed into
local repository before child-1 and child-2 modules?
The same question but in case of multithreaded execution (-T option is
provided)?
As far as I understand from source
maven-core/src/main/java/org/apache/maven/project/ProjectSorter.java it can:
...
Parent parent = project.getModel().getParent();
if ( parent != null )
{
// Parent is added as an edge, but must not cause a cycle - so we remove
any other edges it has
// in conflict
addEdge( projectMap, vertexMap, null, projectVertex, parent.getGroupId(),
parent.getArtifactId(),
parent.getVersion(), true, false );
}
...
--
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: (MPLUGIN-179) Clarify the goalPrefix (is there a default value for example) param
Clarify the goalPrefix (is there a default value for example) param
---
Key: MPLUGIN-179
URL: http://jira.codehaus.org/browse/MPLUGIN-179
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Affects Versions: 2.6
Environment: n/a
Reporter: Anders Hammar
The doc for the goalPrefix param states:
{quote}
The goal prefix that will appear before the :.
{quote}
I'm trying to understand if I need to define this parameter. It doesn't seem so
based on my experience/tests as it will use some (most often good) default
value. This should be clarified in the docs.
Maybe something like this (is this correct?):
{quote}
If not defined, the default value depends on the artifactId name pattern of the
plugin:
* maven-abc-plugin - default value of 'xxx'
* abc-maven-plugin - default value of 'xxx'
* abc-cde-fgh - default value of 'abc-cde-fgh'
{quote}
--
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: (MNGSITE-126) [Documentation] Reactor sorting
[
http://jira.codehaus.org/browse/MNGSITE-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251595#action_251595
]
Benjamin Bentmann commented on MNGSITE-126:
---
Conceptually, inheritance from a parent POM does not induce a dependency on
build output, so there is generally no reason for the reactor order to build
parents before children unless the children have a {{dependency}} referring
to the parent. Besides, aggregation of sub module outputs ideally demands the
aggregator project to be built last, regardless whether it's also used as a
parent POM or not.
So be careful to base your build on observation of current sorting implemention
details.
[Documentation] Reactor sorting
---
Key: MNGSITE-126
URL: http://jira.codehaus.org/browse/MNGSITE-126
Project: Maven Project Web Site
Issue Type: Improvement
Reporter: Andrey Vorobiev
Guide to Working with Multiple Modules
(http://maven.apache.org/guides/mini/guide-multiple-modules.html) says:
The following relationships are honoured when sorting projects:
a project dependency on another module in the build
a plugin declaration where the plugin is another modules in the build
a plugin dependency on another module in the build
a build extension declaration on another module in the build
the order declared in the modules element (if no other rule applies)
and what's about parent pom relation?
For instance we have three modules:
- parent
- child-1
- child-2
parent module is specified as parent pom for modules child-1 and
child-2:
parent
...
artifactIdparent/artifactId
...
/parent
Also we have aggregator module with contents:
project
...
modules
modulepath to parent module/module
modulepath to child-1 module/module
modulepath to child-2 module/module
/modules
...
/project
Next we type: mvn clean install
Can it be guaranteed that parent module will be builded and installed into
local repository before child-1 and child-2 modules?
The same question but in case of multithreaded execution (-T option is
provided)?
As far as I understand from source
maven-core/src/main/java/org/apache/maven/project/ProjectSorter.java it can:
...
Parent parent = project.getModel().getParent();
if ( parent != null )
{
// Parent is added as an edge, but must not cause a cycle - so we remove
any other edges it has
// in conflict
addEdge( projectMap, vertexMap, null, projectVertex, parent.getGroupId(),
parent.getArtifactId(),
parent.getVersion(), true, false );
}
...
--
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: (ARCHETYPE-362) Replacing properties in default value of other properties doesn't work due to faulty ordering.
Replacing properties in default value of other properties doesn't work due to
faulty ordering.
--
Key: ARCHETYPE-362
URL: http://jira.codehaus.org/browse/ARCHETYPE-362
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Affects Versions: 2.0
Reporter: Maarten Winkels
Attachments: RequiredPropertyComparatorTest.java,
traverse-properties-without-default-value.patch
I would like to do something like:
requiredProperty key=name/
requiredProperty key=archetypeId
defaultValuesome-prefix-${name}/defaultValue
/requiredProperty
This is now not working, because the name property does not declare a default
value.
Please see the attached test for an example.
The other attachement is a patch that changes the comparator for sorting the
required properties in such a way that it actually works.
--
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: (MPLUGIN-173) Start using net.sf.jtidy artifact with correct I/O encoding
[ http://jira.codehaus.org/browse/MPLUGIN-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251599#action_251599 ] Stanislav Ochotnicky commented on MPLUGIN-173: -- Previously jtidy had: /** * CharEncoding * @see org.w3c.tidy.Configuration#CharEncoding */ public void setCharEncoding(int charencoding) That used Configuration.XXX constants for character encodings now there is: /** * codeinput-encoding/code the character encoding used for input. * @param encoding a valid java encoding name */ public void setInputEncoding(String encoding) So the patch shouldn't change anything to what was used previously. I don't see how this could cause any problems. Plus just few lines below there already is UTF-8 used to decode byte-stream. Though suggestions to make it better are welcome of course... Start using net.sf.jtidy artifact with correct I/O encoding --- Key: MPLUGIN-173 URL: http://jira.codehaus.org/browse/MPLUGIN-173 Project: Maven 2.x Plugin Tools Issue Type: Improvement Components: API Affects Versions: 2.6 Reporter: Stanislav Ochotnicky Attachments: 0001-fix-for-new-jtidy.patch Current 2.6 version uses jtidy:jtidy artifact which is not being developed anymore. net.sf.jtidy:jtidy artifact provides more features and is actively developed. This patch replaces old artifact with new one and fixes -api to not use deprecated functions for I/O encoding. -- 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: (MPLUGIN-173) Start using net.sf.jtidy artifact with correct I/O encoding
[
http://jira.codehaus.org/browse/MPLUGIN-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251599#action_251599
]
Stanislav Ochotnicky edited comment on MPLUGIN-173 at 1/14/11 6:36 AM:
---
Previously jtidy had:
{code}
/**
* CharEncoding
* @see org.w3c.tidy.Configuration#CharEncoding
*/
public void setCharEncoding(int charencoding)
{code}
That used Configuration.XXX constants for character encodings
now there is:
{code}
/**
* codeinput-encoding/code the character encoding used for input.
* @param encoding a valid java encoding name
*/
public void setInputEncoding(String encoding)
{code}
So the patch shouldn't change anything to what was used previously. I don't see
how this could cause any problems. Plus just few lines below there already is
UTF-8 used to decode byte-stream. Though suggestions to make it better are
welcome of course...
was (Author: sochotnicky):
Previously jtidy had:
/**
* CharEncoding
* @see org.w3c.tidy.Configuration#CharEncoding
*/
public void setCharEncoding(int charencoding)
That used Configuration.XXX constants for character encodings
now there is:
/**
* codeinput-encoding/code the character encoding used for input.
* @param encoding a valid java encoding name
*/
public void setInputEncoding(String encoding)
So the patch shouldn't change anything to what was used previously. I don't see
how this could cause any problems. Plus just few lines below there already is
UTF-8 used to decode byte-stream. Though suggestions to make it better are
welcome of course...
Start using net.sf.jtidy artifact with correct I/O encoding
---
Key: MPLUGIN-173
URL: http://jira.codehaus.org/browse/MPLUGIN-173
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Components: API
Affects Versions: 2.6
Reporter: Stanislav Ochotnicky
Attachments: 0001-fix-for-new-jtidy.patch
Current 2.6 version uses jtidy:jtidy artifact which is not being developed
anymore. net.sf.jtidy:jtidy artifact provides more features and is actively
developed. This patch replaces old artifact with new one and fixes -api to
not use deprecated functions for I/O encoding.
--
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: (MPLUGIN-179) Clarify the goalPrefix (is there a default value for example) param
[
http://jira.codehaus.org/browse/MPLUGIN-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251600#action_251600
]
Anders Hammar commented on MPLUGIN-179:
---
I checked the code and my suggestion above is not completely correct. Not sure
how to formulate what this code does though:
{quote}
public static String getGoalPrefixFromArtifactId( String artifactId )
\{
if ( maven-plugin-plugin.equals( artifactId ) )
\{
return plugin;
\}
else
\{
return artifactId.replaceAll( -?maven-?, ).replaceAll(
-?plugin-?, );
\}
\}
{quote}
Clarify the goalPrefix (is there a default value for example) param
---
Key: MPLUGIN-179
URL: http://jira.codehaus.org/browse/MPLUGIN-179
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Affects Versions: 2.6
Environment: n/a
Reporter: Anders Hammar
The doc for the goalPrefix param states:
{quote}
The goal prefix that will appear before the :.
{quote}
I'm trying to understand if I need to define this parameter. It doesn't seem
so based on my experience/tests as it will use some (most often good) default
value. This should be clarified in the docs.
Maybe something like this (is this correct?):
{quote}
If not defined, the default value depends on the artifactId name pattern of
the plugin:
* maven-abc-plugin - default value of 'xxx'
* abc-maven-plugin - default value of 'xxx'
* abc-cde-fgh - default value of 'abc-cde-fgh'
{quote}
--
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: (MPLUGIN-179) Clarify the goalPrefix (is there a default value for example) param
[
http://jira.codehaus.org/browse/MPLUGIN-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251600#action_251600
]
Anders Hammar edited comment on MPLUGIN-179 at 1/14/11 6:47 AM:
I checked the code and my suggestion above is not completely correct. Not sure
how to formulate what this code does though:
{noformat}
public static String getGoalPrefixFromArtifactId( String artifactId )
{
if ( maven-plugin-plugin.equals( artifactId ) )
{
return plugin;
}
else
{
return artifactId.replaceAll( -?maven-?, ).replaceAll(
-?plugin-?, );
}
}
{noformat}
was (Author: afloom):
I checked the code and my suggestion above is not completely correct. Not
sure how to formulate what this code does though:
{quote}
public static String getGoalPrefixFromArtifactId( String artifactId )
\{
if ( maven-plugin-plugin.equals( artifactId ) )
\{
return plugin;
\}
else
\{
return artifactId.replaceAll( -?maven-?, ).replaceAll(
-?plugin-?, );
\}
\}
{quote}
Clarify the goalPrefix (is there a default value for example) param
---
Key: MPLUGIN-179
URL: http://jira.codehaus.org/browse/MPLUGIN-179
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Affects Versions: 2.6
Environment: n/a
Reporter: Anders Hammar
The doc for the goalPrefix param states:
{quote}
The goal prefix that will appear before the :.
{quote}
I'm trying to understand if I need to define this parameter. It doesn't seem
so based on my experience/tests as it will use some (most often good) default
value. This should be clarified in the docs.
Maybe something like this (is this correct?):
{quote}
If not defined, the default value depends on the artifactId name pattern of
the plugin:
* maven-abc-plugin - default value of 'xxx'
* abc-maven-plugin - default value of 'xxx'
* abc-cde-fgh - default value of 'abc-cde-fgh'
{quote}
--
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: (MARCHETYPES-37) The POM of generated projects should have xml prolog/header specifying encoding
[ http://jira.codehaus.org/browse/MARCHETYPES-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251601#action_251601 ] Joerg Schaible commented on MARCHETYPES-37: --- The XML spec defines UTF-8 if the header is missing. The POM of generated projects should have xml prolog/header specifying encoding --- Key: MARCHETYPES-37 URL: http://jira.codehaus.org/browse/MARCHETYPES-37 Project: Maven Archetype Bundles Issue Type: Improvement Components: Maven Archetype Archetype, Maven Plugin Archetype, Maven Plugin Site Archetype, Maven Portlet Archetype, Maven Quickstart Archetype, Maven Simple J2EE Archetype, Maven Simple Project Archetype, Maven Simple Site Archetype, Maven Site Archetype, Maven Webapp Archetype Environment: n/a Reporter: Anders Hammar Attachments: archetypes.patch The POM generated by the archetypes should have an xml prolog/header specifying encoding. For anyone using non-ascii chars this is important as it will ensure that chars are handled correctly. I've attached a patch for this. Changes are relative the top level archetypes project trunk. -- 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-544) Encoding issues with reports
Encoding issues with reports Key: MSITE-544 URL: http://jira.codehaus.org/browse/MSITE-544 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Affects Versions: 3.0-beta-3 Environment: MacOS 10.6.6, Maven 3.0.2 also seen on Windows XP, Maven 3.0.2 Reporter: Anders Hammar Attachments: mojo-details-encoding.zip When specify project.reporting.outputEncoding and using non-ascii chars in a mojo's description (and also for mojo param descriptions), the chars are incorrectly transferred to the mojo details site page. I think there's a general encoding issue, but this is where I've seen the problem and it is easy to reproduce. Steps to reproduce with attached project: * execute 'mvn site' * have a look in target/generated-site/xdoc/touch-mojo.xml * for example, check the description of the mojo. It should be åäöÅÄÖ, but is garbage. -- 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: (MPLUGIN-173) Start using net.sf.jtidy artifact with correct I/O encoding
[ http://jira.codehaus.org/browse/MPLUGIN-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251610#action_251610 ] Anders Hammar commented on MPLUGIN-173: --- Yes, you're right. I went through the code a bit more thoroughly after writing the comment and was about to edit it as I realized I was wrong. The code should be alright, as UTF-8 is used consistently everywhere. Start using net.sf.jtidy artifact with correct I/O encoding --- Key: MPLUGIN-173 URL: http://jira.codehaus.org/browse/MPLUGIN-173 Project: Maven 2.x Plugin Tools Issue Type: Improvement Components: API Affects Versions: 2.6 Reporter: Stanislav Ochotnicky Attachments: 0001-fix-for-new-jtidy.patch Current 2.6 version uses jtidy:jtidy artifact which is not being developed anymore. net.sf.jtidy:jtidy artifact provides more features and is actively developed. This patch replaces old artifact with new one and fixes -api to not use deprecated functions for I/O encoding. -- 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: (ARCHETYPE-359) fail on mvn install with a archetype created from create-from-project command having required property in archetype-metadata.xml
[
http://jira.codehaus.org/browse/ARCHETYPE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251613#action_251613
]
Maarten Winkels commented on ARCHETYPE-359:
---
The build fails in the integration-test phase, because the new property is not
assigned in the src/test/resources/projects/basic/archetype.properties.
Simply adding a line to that file with an assignment for the new property will
solvve this.
Not really blocking?
fail on mvn install with a archetype created from create-from-project command
having required property in archetype-metadata.xml
Key: ARCHETYPE-359
URL: http://jira.codehaus.org/browse/ARCHETYPE-359
Project: Maven Archetype
Issue Type: Bug
Components: Archetypes
Affects Versions: 2.0
Environment: Apache Maven 2.2.1 (r801777; 2009-08-07 00:46:01+0530)
Java version: 1.6.0_21
Java home: C:\Program Files\Java\jdk1.6.0_18\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Abhishek Sharma
Priority: Blocker
Attachments: output.txt
mvn install fails when archetype-metadata.xml having required property entry.
[INFO] Scanning for projects...
[INFO]
[INFO] Building quipoz-qte-project-archetype-archetype
[INFO]task-segment: [install]
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 25 resources
[INFO] [resources:testResources {execution: default-testResources}]
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 2 resources
[INFO] [archetype:jar {execution: default-jar}]
[INFO] [archetype:add-archetype-metadata {execution:
default-add-archetype-metadata}]
[INFO] [archetype:integration-test {execution: default-integration-test}]
[ERROR] Archetype
quipoz-qte-project-archetype:quipoz-qte-project-archetype-archetype:0.0.1-SNAPSHOT
is not configured
Property check is missing.
org.apache.maven.archetype.exception.ArchetypeNotConfigured: Archetype
quipoz-qte-project-archetype:quipoz-qte-project-archetype-archetype:0.0.1-SNAPSHOT
is not configured
Property check is missing.
at
org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.generateArchetype(DefaultFilesetArchetypeGenerator.java:128)
at
org.apache.maven.archetype.generator.DefaultArchetypeGenerator.processFileSetArchetype(DefaultArchetypeGenerator.java:136)
at
org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype(DefaultArchetypeGenerator.java:106)
at
org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype(DefaultArchetypeGenerator.java:149)
at
org.apache.maven.archetype.mojos.IntegrationTestMojo.processIntegrationTest(IntegrationTestMojo.java:237)
at
org.apache.maven.archetype.mojos.IntegrationTestMojo.execute(IntegrationTestMojo.java:108)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[jira] Created: (MNGSITE-127) Link to reference guide is not ok.
Link to reference guide is not ok. -- Key: MNGSITE-127 URL: http://jira.codehaus.org/browse/MNGSITE-127 Project: Maven Project Web Site Issue Type: Bug Environment: all Reporter: Karl Heinz Marbaise Priority: Minor The link on the bottom of this page: http://maven.apache.org/guides/mini/guide-multiple-modules.html to the reference guide is not correct. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-134) EspaceString doesn't work
[
http://jira.codehaus.org/browse/MRESOURCES-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251628#action_251628
]
Rémy Sanlaville commented on MRESOURCES-134:
The [escapeString
parameter|http://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html]
seems to have default value
{noformat}Expression preceded with the String won't be interpolated \${foo}
will be replaced with ${foo}.
Default value is: ${maven.resources.escapeString}.
{noformat}
Also I don't understand why I have to configure the plugin if I don't need any
escapeString. If I remove this configuration, it does not work...
{code:title=pom.xml|borderStyle=solid}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
version2.5-SNAPSHOT/version
configuration
escapeString§/escapeString
/configuration
/plugin
{code}
EspaceString doesn't work
-
Key: MRESOURCES-134
URL: http://jira.codehaus.org/browse/MRESOURCES-134
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Components: escape string
Affects Versions: 2.5
Environment: maven 2.2.1
Reporter: Rémy Sanlaville
Assignee: Olivier Lamy
Attachments: maven-resources-plugin-EscapeString.zip
if I configure the maven-resource-plugin in order to escape a delimiter in a
comment, the escapeString is not removed in the target.
{code:title=src/main/resources/properties/test.properties|borderStyle=solid}
#%comment to espace:§@toto
question=@message@
{code}
{code:title=pom.xml|borderStyle=solid}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
version2.5-SNAPSHOT/version
configuration
escapeString§/escapeString
/configuration
/plugin
{code}
{code:title=target/classes/properties/test.properties|borderStyle=solid}
#%comment to espace:§@toto
question=A nice message...
{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: (MNG-4979) Cannot override configuration parameter from command line
Cannot override configuration parameter from command line - Key: MNG-4979 URL: http://jira.codehaus.org/browse/MNG-4979 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.2.1 Reporter: Stefan Birkner See the attachements for a sample project of the surefire integration tests. Its pom sets the skipTests option of the surefire-plugin to false. plugin ... configuration skipTestsfalse/skipTests /configuration /plugin This configuration is not overriden by the appropriate command line parameter: mvn -DskipTests=true test Executing this line will set the skipTests parameter of the Surefire plugin to false and the tests will not be skipped. -- 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-4979) Cannot override configuration parameter from command line
[ http://jira.codehaus.org/browse/MNG-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251641#action_251641 ] Stefan Birkner commented on MNG-4979: - I looked at the code of org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(...) and discovered the reason for this bug. The line PlexusConfiguration mergedConfiguration = mergeMojoConfiguration( pomConfiguration, mojoDescriptor ); sets the skipTests parameter to the value of the pom. Afterwards this value is not be overriden, because it is already set. Cannot override configuration parameter from command line - Key: MNG-4979 URL: http://jira.codehaus.org/browse/MNG-4979 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.2.1 Reporter: Stefan Birkner See the attachements for a sample project of the surefire integration tests. Its pom sets the skipTests option of the surefire-plugin to false. plugin ... configuration skipTestsfalse/skipTests /configuration /plugin This configuration is not overriden by the appropriate command line parameter: mvn -DskipTests=true test Executing this line will set the skipTests parameter of the Surefire plugin to false and the tests will not be skipped. -- 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-649) Might be impossible to have empty strings in systemPropertyVariables element
[ http://jira.codehaus.org/browse/SUREFIRE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251646#action_251646 ] Stefan Birkner commented on SUREFIRE-649: - The Bug happens inside of org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.fromExpression( PlexusConfiguration configuration, ExpressionEvaluator expressionEvaluator ). Within this method the empty string is converted to null. Might be impossible to have empty strings in systemPropertyVariables element Key: SUREFIRE-649 URL: http://jira.codehaus.org/browse/SUREFIRE-649 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.6 Reporter: Laird Nelson Attachments: surefireEmptyStringIssue.tar.gz This stanza: systemProperties property nameemptyProperty/name value/value /property /systemProperties ...yields from System.getProperty(emptyProperty). This (supposedly better) stanza: systemPropertyVariables emptyProperty/emptyProperty /systemPropertyVariables ...yields null from System.getProperty(emptyProperty). A test case is attached that demonstrates the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4975) [regression] plugin executions injected from profile run before instead of after existing executions in the POM
[
http://jira.codehaus.org/browse/MNG-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4975:
---
Summary: [regression] plugin executions injected from profile run before
instead of after existing executions in the POM (was: [REGRESSION] mojos
execution order doesn't respect ids if profiles are used.)
Just to clarify, plugin executions are not ordered by their IDs, only the
declaration order in the POM matters.
[regression] plugin executions injected from profile run before instead of
after existing executions in the POM
---
Key: MNG-4975
URL: http://jira.codehaus.org/browse/MNG-4975
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.0, 3.0.1, 3.0.2
Environment: I reproduced the problem with maven 3.0, 3.0.1 and
3.0.2. It doesn't exist in 2.2.1
MacOS 1.6 JVM
Reporter: Arnaud Heritier
Attachments: pom.xml
Let's imagine we have a lifecycle phase where we want to bind several mojos.
We want to force the order of execution of our mojos in this phase thus we
use ordered execution IDs (00exec, 01exec, ...).
In project's build part we define 00exec, 01exec, 02exec
In a profile #1 we define 03exec,04exec
In a profile #2 we define 05exec,06exec
If I execute my build without profiles I want to see the execution of
00-01-02
If I activate profile #1 I want to see the execution of 00-01-02-03-04
If I activate profile #2 I want to see the execution of
00-01-02-03-04-05-06
This the behavior we have in Maven 2.X. Any combinaison of profiles will
ensure executions are ordered following IDs order
In Maven 3.x it is no more the case.
Without profile we have 00-01-02 (GREAT)
With Profile 1 activate we have : 03-04-00-01-02 ( :( )
With Profile 1 2 activate we have : 05-06-03-04-00-01-02 ( :( )
I attach a simple testcase with an antrun to show the problem.
Just play with {{mvn package}} and profiles {{profile1}} {{profile2}}
Note that the order depends also of the order of profiles declaration in the
POM in M3
If profile1 is defined before profile 2 I have 05-06-03-04-00-01-02
If profile2 is defined before profile 1 I have 03-04-05-06-00-01-02
--
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-4975) [regression] plugin executions injected from profile run before instead of after existing executions in the POM
[
http://jira.codehaus.org/browse/MNG-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251653#action_251653
]
Arnaud Heritier commented on MNG-4975:
--
thus it is impossible with this rule to sort them across profiles ?
.. and it worked with maven2. Thus if consider it is specification and note a
bug we have to document this change. WDYT ?
[regression] plugin executions injected from profile run before instead of
after existing executions in the POM
---
Key: MNG-4975
URL: http://jira.codehaus.org/browse/MNG-4975
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.0, 3.0.1, 3.0.2
Environment: I reproduced the problem with maven 3.0, 3.0.1 and
3.0.2. It doesn't exist in 2.2.1
MacOS 1.6 JVM
Reporter: Arnaud Heritier
Attachments: pom.xml
Let's imagine we have a lifecycle phase where we want to bind several mojos.
We want to force the order of execution of our mojos in this phase thus we
use ordered execution IDs (00exec, 01exec, ...).
In project's build part we define 00exec, 01exec, 02exec
In a profile #1 we define 03exec,04exec
In a profile #2 we define 05exec,06exec
If I execute my build without profiles I want to see the execution of
00-01-02
If I activate profile #1 I want to see the execution of 00-01-02-03-04
If I activate profile #2 I want to see the execution of
00-01-02-03-04-05-06
This the behavior we have in Maven 2.X. Any combinaison of profiles will
ensure executions are ordered following IDs order
In Maven 3.x it is no more the case.
Without profile we have 00-01-02 (GREAT)
With Profile 1 activate we have : 03-04-00-01-02 ( :( )
With Profile 1 2 activate we have : 05-06-03-04-00-01-02 ( :( )
I attach a simple testcase with an antrun to show the problem.
Just play with {{mvn package}} and profiles {{profile1}} {{profile2}}
Note that the order depends also of the order of profiles declaration in the
POM in M3
If profile1 is defined before profile 2 I have 05-06-03-04-00-01-02
If profile2 is defined before profile 1 I have 03-04-05-06-00-01-02
--
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-4452) Metadata for snapshots should include classifier
[ http://jira.codehaus.org/browse/MNG-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leon Franzen updated MNG-4452: -- Attachment: nar-maven-metadata.xml nar-artifact-list.txt output The state of the snapshot repository during the Maven build shown in the file output (attached) Metadata for snapshots should include classifier Key: MNG-4452 URL: http://jira.codehaus.org/browse/MNG-4452 Project: Maven 2 3 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.2.1, 3.0-alpha-4 Reporter: Paul Benedict Assignee: Benjamin Bentmann Fix For: 3.0 Attachments: nar-artifact-list.txt, nar-maven-metadata.xml, output Please see the whole conversation here: http://old.nabble.com/Multi-Platform-snapshots-td25295999.html Essentially, an artifact's classifier isn't included in the repository's metadata of a snapshot. This makes it difficult (impossible?) to deploy multiply snapshots with different classifiers. The primary use case is to continuously build an artifact for different environments. -- 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-4975) [regression] plugin executions injected from profile run before instead of after existing executions in the POM
[
http://jira.codehaus.org/browse/MNG-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251657#action_251657
]
Arnaud Heritier commented on MNG-4975:
--
Ok, thus for readers I confirm Benjamin's assertion.
I misunderstood the order of plugin executions inside a phase : They have to
follow the order in the POM. Thus if I put profile 2 before profile 1, with
maven 2.X and both profiles activated I have 00-01-02-05-06-03-04
Thus there is a bug in Maven 3, in my sample build executions (00,01,02) should
always be executed before profiles executions but it won't follow execution IDs
(they could be 46, 32, 57)
Note that in an inheritance chain child executions are always done after parent
executions
[regression] plugin executions injected from profile run before instead of
after existing executions in the POM
---
Key: MNG-4975
URL: http://jira.codehaus.org/browse/MNG-4975
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.0, 3.0.1, 3.0.2
Environment: I reproduced the problem with maven 3.0, 3.0.1 and
3.0.2. It doesn't exist in 2.2.1
MacOS 1.6 JVM
Reporter: Arnaud Heritier
Attachments: pom.xml
Let's imagine we have a lifecycle phase where we want to bind several mojos.
We want to force the order of execution of our mojos in this phase thus we
use ordered execution IDs (00exec, 01exec, ...).
In project's build part we define 00exec, 01exec, 02exec
In a profile #1 we define 03exec,04exec
In a profile #2 we define 05exec,06exec
If I execute my build without profiles I want to see the execution of
00-01-02
If I activate profile #1 I want to see the execution of 00-01-02-03-04
If I activate profile #2 I want to see the execution of
00-01-02-03-04-05-06
This the behavior we have in Maven 2.X. Any combinaison of profiles will
ensure executions are ordered following IDs order
In Maven 3.x it is no more the case.
Without profile we have 00-01-02 (GREAT)
With Profile 1 activate we have : 03-04-00-01-02 ( :( )
With Profile 1 2 activate we have : 05-06-03-04-00-01-02 ( :( )
I attach a simple testcase with an antrun to show the problem.
Just play with {{mvn package}} and profiles {{profile1}} {{profile2}}
Note that the order depends also of the order of profiles declaration in the
POM in M3
If profile1 is defined before profile 2 I have 05-06-03-04-00-01-02
If profile2 is defined before profile 1 I have 03-04-05-06-00-01-02
--
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-4975) [regression] plugin executions injected from profile run before instead of after existing executions in the POM
[
http://jira.codehaus.org/browse/MNG-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4975.
--
Resolution: Fixed
Fix Version/s: 3.0.3
Assignee: Benjamin Bentmann
Fixed in [r1059192|http://svn.apache.org/viewvc?view=revisionrevision=1059192].
[regression] plugin executions injected from profile run before instead of
after existing executions in the POM
---
Key: MNG-4975
URL: http://jira.codehaus.org/browse/MNG-4975
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.0, 3.0.1, 3.0.2
Environment: I reproduced the problem with maven 3.0, 3.0.1 and
3.0.2. It doesn't exist in 2.2.1
MacOS 1.6 JVM
Reporter: Arnaud Heritier
Assignee: Benjamin Bentmann
Fix For: 3.0.3
Attachments: pom.xml
Let's imagine we have a lifecycle phase where we want to bind several mojos.
We want to force the order of execution of our mojos in this phase thus we
use ordered execution IDs (00exec, 01exec, ...).
In project's build part we define 00exec, 01exec, 02exec
In a profile #1 we define 03exec,04exec
In a profile #2 we define 05exec,06exec
If I execute my build without profiles I want to see the execution of
00-01-02
If I activate profile #1 I want to see the execution of 00-01-02-03-04
If I activate profile #2 I want to see the execution of
00-01-02-03-04-05-06
This the behavior we have in Maven 2.X. Any combinaison of profiles will
ensure executions are ordered following IDs order
In Maven 3.x it is no more the case.
Without profile we have 00-01-02 (GREAT)
With Profile 1 activate we have : 03-04-00-01-02 ( :( )
With Profile 1 2 activate we have : 05-06-03-04-00-01-02 ( :( )
I attach a simple testcase with an antrun to show the problem.
Just play with {{mvn package}} and profiles {{profile1}} {{profile2}}
Note that the order depends also of the order of profiles declaration in the
POM in M3
If profile1 is defined before profile 2 I have 05-06-03-04-00-01-02
If profile2 is defined before profile 1 I have 03-04-05-06-00-01-02
--
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-4973) [regression] Build extensions are invisible to plugins in multi module build
[
http://jira.codehaus.org/browse/MNG-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4973:
---
Summary: [regression] Build extensions are invisible to plugins in multi
module build (was: CLIRR execution failure)
[regression] Build extensions are invisible to plugins in multi module build
Key: MNG-4973
URL: http://jira.codehaus.org/browse/MNG-4973
Project: Maven 2 3
Issue Type: Bug
Components: Reactor and workspace
Affects Versions: 3.0.1, 3.0.2
Reporter: Vincent Massol
Building
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/xwiki-archetypes/
(it's a multi module POM) fails with Maven 3.0.1 and 3.0.2 but works fine
with Maven 3.0.
The error is:
{noformat}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] XWiki Platform - Tools - Archetype POM SUCCESS [11.440s]
[INFO] XWiki Platform - Tools - XWiki Rendering Macro Archetype FAILURE
[5.984s]
[INFO] XWiki Platform - Tools - XWiki Component Archetype SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 20.136s
[INFO] Finished at: Thu Jan 13 08:40:35 CET 2011
[INFO] Final Memory: 15M/81M
[INFO]
[ERROR] Failed to execute goal
org.codehaus.mojo:clirr-maven-plugin:2.2.3:check (clirr-check) on project
xwiki-archetype-macro: Error finding previous version: Could not find
artifact org.xwiki.platform.tools:xwiki-archetype-macro:maven-archetype:1.1
in xwiki-externals (http://maven.xwiki.org/externals)
[ERROR]
[ERROR] Try downloading the file manually from the project website.
[ERROR]
[ERROR] Then, install it using the command:
[ERROR] mvn install:install-file -DgroupId=org.xwiki.platform.tools
-DartifactId=xwiki-archetype-macro -Dversion=1.1 -Dpackaging=maven-archetype
-Dfile=/path/to/file
[ERROR]
[ERROR] Alternatively, if you host your own repository you can deploy the
file there:
[ERROR] mvn deploy:deploy-file -DgroupId=org.xwiki.platform.tools
-DartifactId=xwiki-archetype-macro -Dversion=1.1 -Dpackaging=maven-archetype
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
[ERROR]
[ERROR]
[ERROR] org.xwiki.platform.tools:xwiki-archetype-macro:maven-archetype:1.1
[ERROR]
[ERROR] from the specified remote repositories:
[ERROR] xwiki-externals (http://maven.xwiki.org/externals, releases=true,
snapshots=true),
[ERROR] xwiki-releases (http://maven.xwiki.org/releases, releases=true,
snapshots=false),
[ERROR] xwiki-snapshots (http://maven.xwiki.org/snapshots, releases=false,
snapshots=true),
[ERROR] central (http://repo1.maven.org/maven2, releases=true,
snapshots=false)
[ERROR] - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn goals -rf :xwiki-archetype-macro
{noformat}
Strangely if I build only the failing module it works fine even with Maven
3.0.1 3.0.2:
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/xwiki-archetypes/xwiki-archetype-macro/
So this seems to be a reactor issue somewhere.
Note: In order to reproduce you might want to set the XWiki remote maven
repository in your settings.xml as explained here:
http://dev.xwiki.org/xwiki/bin/view/Community/Building
Thanks
--
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-588) Filehandle leak in AccuRev provider
[ http://jira.codehaus.org/browse/SCM-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Gardner updated SCM-588: -- Attachment: SCM-588.patch Also fix a bug capturing AccuRev error output.Not really associated with the filehandle leak - just being lazy. Filehandle leak in AccuRev provider --- Key: SCM-588 URL: http://jira.codehaus.org/browse/SCM-588 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-accurev Affects Versions: 1.4 Environment: linux Reporter: Grant Gardner Assignee: Olivier Lamy Fix For: 1.5 Attachments: SCM-588.patch, SCM-588.patch XppStreamConsumer uses a pipe but only closes one side which causes a file handle leak under linux. -- 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-4973) [regression] Build extensions are invisible to plugins in multi module build
[
http://jira.codehaus.org/browse/MNG-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4973.
--
Resolution: Fixed
Fix Version/s: 3.0.3
Assignee: Benjamin Bentmann
Fixed in [r1059266|http://svn.apache.org/viewvc?view=revisionrevision=1059266].
[regression] Build extensions are invisible to plugins in multi module build
Key: MNG-4973
URL: http://jira.codehaus.org/browse/MNG-4973
Project: Maven 2 3
Issue Type: Bug
Components: Reactor and workspace
Affects Versions: 3.0.1, 3.0.2
Reporter: Vincent Massol
Assignee: Benjamin Bentmann
Fix For: 3.0.3
Building
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/xwiki-archetypes/
(it's a multi module POM) fails with Maven 3.0.1 and 3.0.2 but works fine
with Maven 3.0.
The error is:
{noformat}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] XWiki Platform - Tools - Archetype POM SUCCESS [11.440s]
[INFO] XWiki Platform - Tools - XWiki Rendering Macro Archetype FAILURE
[5.984s]
[INFO] XWiki Platform - Tools - XWiki Component Archetype SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 20.136s
[INFO] Finished at: Thu Jan 13 08:40:35 CET 2011
[INFO] Final Memory: 15M/81M
[INFO]
[ERROR] Failed to execute goal
org.codehaus.mojo:clirr-maven-plugin:2.2.3:check (clirr-check) on project
xwiki-archetype-macro: Error finding previous version: Could not find
artifact org.xwiki.platform.tools:xwiki-archetype-macro:maven-archetype:1.1
in xwiki-externals (http://maven.xwiki.org/externals)
[ERROR]
[ERROR] Try downloading the file manually from the project website.
[ERROR]
[ERROR] Then, install it using the command:
[ERROR] mvn install:install-file -DgroupId=org.xwiki.platform.tools
-DartifactId=xwiki-archetype-macro -Dversion=1.1 -Dpackaging=maven-archetype
-Dfile=/path/to/file
[ERROR]
[ERROR] Alternatively, if you host your own repository you can deploy the
file there:
[ERROR] mvn deploy:deploy-file -DgroupId=org.xwiki.platform.tools
-DartifactId=xwiki-archetype-macro -Dversion=1.1 -Dpackaging=maven-archetype
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
[ERROR]
[ERROR]
[ERROR] org.xwiki.platform.tools:xwiki-archetype-macro:maven-archetype:1.1
[ERROR]
[ERROR] from the specified remote repositories:
[ERROR] xwiki-externals (http://maven.xwiki.org/externals, releases=true,
snapshots=true),
[ERROR] xwiki-releases (http://maven.xwiki.org/releases, releases=true,
snapshots=false),
[ERROR] xwiki-snapshots (http://maven.xwiki.org/snapshots, releases=false,
snapshots=true),
[ERROR] central (http://repo1.maven.org/maven2, releases=true,
snapshots=false)
[ERROR] - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn goals -rf :xwiki-archetype-macro
{noformat}
Strangely if I build only the failing module it works fine even with Maven
3.0.1 3.0.2:
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/xwiki-archetypes/xwiki-archetype-macro/
So this seems to be a reactor issue somewhere.
Note: In order to reproduce you might want to set the XWiki remote maven
repository in your settings.xml as explained here:
http://dev.xwiki.org/xwiki/bin/view/Community/Building
Thanks
--
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-4971) Display maven home in version info
[ http://jira.codehaus.org/browse/MNG-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4971. -- Resolution: Fixed Fix Version/s: 3.0.3 Assignee: Benjamin Bentmann Applied in [r1059267|http://svn.apache.org/viewvc?view=revisionrevision=1059267] but opted to keep the order version, home, version, home. Display maven home in version info -- Key: MNG-4971 URL: http://jira.codehaus.org/browse/MNG-4971 Project: Maven 2 3 Issue Type: Improvement Components: Logging Affects Versions: 3.0.2 Reporter: Guo Du Assignee: Benjamin Bentmann Priority: Trivial Fix For: 3.0.3 Attachments: display-maven-home-in-version-info.diff Display maven.home information when user run mvn -version. Similar motivation as MNG-4944. User may have same version of maven for different project such as company/open source. Same as java.home, user may need go into maven.home to do some verification. The patch moved java.home one line up to group together with maven.home. With patch mvn -version will show: Apache Maven 3.0.1 (r1038046; 2010-11-23 10:58:32+) Maven home: /software/maven/3.0.1 Java home: /usr/lib/jvm/java-6-openjdk/jre Java version: 1.6.0_20, vendor: Sun Microsystems Inc. Default locale: en_IE, platform encoding: UTF-8 OS name: linux, version: 2.6.32-25-generic, arch: i386, family: unix Without patch mvn -version will show: Apache Maven 3.0.1 (r1038046; 2010-11-23 10:58:32+) Java version: 1.6.0_20, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/java-6-openjdk/jre Default locale: en_IE, platform encoding: UTF-8 OS name: linux, version: 2.6.32-25-generic, arch: i386, family: unix -- 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-4973) [regression] Build extensions are invisible to plugins in multi module build
[
http://jira.codehaus.org/browse/MNG-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=251686#action_251686
]
Vincent Massol commented on MNG-4973:
-
Thanks for fixing it Benjamin.
[regression] Build extensions are invisible to plugins in multi module build
Key: MNG-4973
URL: http://jira.codehaus.org/browse/MNG-4973
Project: Maven 2 3
Issue Type: Bug
Components: Reactor and workspace
Affects Versions: 3.0.1, 3.0.2
Reporter: Vincent Massol
Assignee: Benjamin Bentmann
Fix For: 3.0.3
Building
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/xwiki-archetypes/
(it's a multi module POM) fails with Maven 3.0.1 and 3.0.2 but works fine
with Maven 3.0.
The error is:
{noformat}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] XWiki Platform - Tools - Archetype POM SUCCESS [11.440s]
[INFO] XWiki Platform - Tools - XWiki Rendering Macro Archetype FAILURE
[5.984s]
[INFO] XWiki Platform - Tools - XWiki Component Archetype SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 20.136s
[INFO] Finished at: Thu Jan 13 08:40:35 CET 2011
[INFO] Final Memory: 15M/81M
[INFO]
[ERROR] Failed to execute goal
org.codehaus.mojo:clirr-maven-plugin:2.2.3:check (clirr-check) on project
xwiki-archetype-macro: Error finding previous version: Could not find
artifact org.xwiki.platform.tools:xwiki-archetype-macro:maven-archetype:1.1
in xwiki-externals (http://maven.xwiki.org/externals)
[ERROR]
[ERROR] Try downloading the file manually from the project website.
[ERROR]
[ERROR] Then, install it using the command:
[ERROR] mvn install:install-file -DgroupId=org.xwiki.platform.tools
-DartifactId=xwiki-archetype-macro -Dversion=1.1 -Dpackaging=maven-archetype
-Dfile=/path/to/file
[ERROR]
[ERROR] Alternatively, if you host your own repository you can deploy the
file there:
[ERROR] mvn deploy:deploy-file -DgroupId=org.xwiki.platform.tools
-DartifactId=xwiki-archetype-macro -Dversion=1.1 -Dpackaging=maven-archetype
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
[ERROR]
[ERROR]
[ERROR] org.xwiki.platform.tools:xwiki-archetype-macro:maven-archetype:1.1
[ERROR]
[ERROR] from the specified remote repositories:
[ERROR] xwiki-externals (http://maven.xwiki.org/externals, releases=true,
snapshots=true),
[ERROR] xwiki-releases (http://maven.xwiki.org/releases, releases=true,
snapshots=false),
[ERROR] xwiki-snapshots (http://maven.xwiki.org/snapshots, releases=false,
snapshots=true),
[ERROR] central (http://repo1.maven.org/maven2, releases=true,
snapshots=false)
[ERROR] - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn goals -rf :xwiki-archetype-macro
{noformat}
Strangely if I build only the failing module it works fine even with Maven
3.0.1 3.0.2:
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/xwiki-archetypes/xwiki-archetype-macro/
So this seems to be a reactor issue somewhere.
Note: In order to reproduce you might want to set the XWiki remote maven
repository in your settings.xml as explained here:
http://dev.xwiki.org/xwiki/bin/view/Community/Building
Thanks
--
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
