[jira] (MENFORCER-170) Refactored Unit Test Code
[ https://jira.codehaus.org/browse/MENFORCER-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MENFORCER-170: - Assignee: Karl Heinz Marbaise Refactored Unit Test Code - Key: MENFORCER-170 URL: https://jira.codehaus.org/browse/MENFORCER-170 Project: Maven Enforcer Plugin Issue Type: Improvement Components: Rule API Affects Versions: 1.3.1 Environment: all Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Trivial Attachments: x.diff I have refactored the code of the unit test a little bit. Patch attached (against r1554171 from trunk). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-170) Refactored Unit Test Code
[ https://jira.codehaus.org/browse/MENFORCER-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MENFORCER-170. - Resolution: Fixed Fix Version/s: 2.0 Fixed in r113. Refactored Unit Test Code - Key: MENFORCER-170 URL: https://jira.codehaus.org/browse/MENFORCER-170 Project: Maven Enforcer Plugin Issue Type: Improvement Components: Rule API Affects Versions: 1.3.1 Environment: all Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Trivial Fix For: 2.0 Attachments: x.diff I have refactored the code of the unit test a little bit. Patch attached (against r1554171 from trunk). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-170) Refactored Unit Test Code
[ https://jira.codehaus.org/browse/MENFORCER-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reopened MENFORCER-170: --- Broken the build. I have to check the cause of that. Refactored Unit Test Code - Key: MENFORCER-170 URL: https://jira.codehaus.org/browse/MENFORCER-170 Project: Maven Enforcer Plugin Issue Type: Improvement Components: Rule API Affects Versions: 1.3.1 Environment: all Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Trivial Fix For: 2.0 Attachments: x.diff I have refactored the code of the unit test a little bit. Patch attached (against r1554171 from trunk). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5406) don't expose core's slf4j-api by default, add a plugin-descriptor option to expose
[ https://jira.codehaus.org/browse/MNG-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5406: --- Fix Version/s: (was: 3.1.x) 3.2 don't expose core's slf4j-api by default, add a plugin-descriptor option to expose -- Key: MNG-5406 URL: https://jira.codehaus.org/browse/MNG-5406 Project: Maven 2 3 Issue Type: Improvement Components: Logging, Plugin API Affects Versions: 3.1.0-alpha-1 Reporter: Herve Boutemy Assignee: Jason van Zyl Fix For: 3.2 Plugins written until now didn't expect slf4j-api exposition from core: exposing it can cause problems. Then we need to avoid slf4j-api exposition by default for them, but add an option in plugin-descriptor to enable Future plugin-tools will generate a plugin descriptor with this option defined to effectivemely choose to benefit from core'slf4j or not -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5265) enforce repository url verification for passing authz
[
https://jira.codehaus.org/browse/MNG-5265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5265:
---
Fix Version/s: (was: 3.1.x)
3.2
enforce repository url verification for passing authz
-
Key: MNG-5265
URL: https://jira.codehaus.org/browse/MNG-5265
Project: Maven 2 3
Issue Type: Improvement
Components: Settings
Affects Versions: 2.0.10, 2.2.1, 3.0.2, 3.0.3, 3.0.4
Reporter: Olivier Lamy
Fix For: 3.2
Related discussion: http://markmail.org/message/7pswshucxc7qwtef
in your settings you have:
{code}
server
usernameolamy/username
passwordreallycomplicatedpassword/password
idfoo.org/id
/server
{code}
During dependencies resolution, you get a pom with a repository.
{code}
repository
idfoo.org/id
urlhttp://yourpasswordwillbehacked.org//url
/repository
{code}
Idea id in settings must contains the target hostname.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5075) MavenProject.getParent throws undocumented ISE
[
https://jira.codehaus.org/browse/MNG-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5075:
---
Fix Version/s: (was: 3.1.x)
3.2
MavenProject.getParent throws undocumented ISE
--
Key: MNG-5075
URL: https://jira.codehaus.org/browse/MNG-5075
Project: Maven 2 3
Issue Type: Bug
Components: Embedding
Affects Versions: 3.0.3
Reporter: Jesse Glick
Fix For: 3.2
Attachments: MavenProject-getParent-ISE.diff
http://bugzilla-attachments-197994.netbeans.org/bugzilla/attachment.cgi?id=107899
shows a stack trace encountered when calling {{MavenProject.getParent}} on a
project with some errors (probably POMs missing in the local repository).
This method has no Javadoc comment, so it is hard to know exactly what it is
permitted/supposed to do, but {{hasParent}} implies that {{null}} is a valid
return value, and there is no {{throws IllegalStateException}} clause. The
attached patch brings the behavior in line with that signature. (I think I
got the {{PlexusTestCase}} infrastructure working with all the required
wiring but it may be possible to simplify the test case.)
Cleaner might be to just declare {{getParent}} (and also {{hasParent}}?) to
throw {{ProjectBuildingException}}, though this would be a
source-incompatible change. (Only binary-incompatible for clients which are
already catching {{IllegalStateException}}!)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5185) Improve missing dependency error message when _maven.repositories/_remote.repositories contains other repository ids than requested
[ https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5185: --- Fix Version/s: (was: 3.1.x) 3.2 Improve missing dependency error message when _maven.repositories/_remote.repositories contains other repository ids than requested - Key: MNG-5185 URL: https://jira.codehaus.org/browse/MNG-5185 Project: Maven 2 3 Issue Type: Improvement Affects Versions: 3.0.2, 3.0.3, 3.0.4 Reporter: Mark Derricutt Assignee: Olivier Lamy Fix For: 3.2 Attachments: 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch Based on a discussion on the users list [1], [Maven 3 has changed how it resolves artifacts from local repositories|https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository]. Unfortunately, when conflicts arise (GAV is cached in local repo, but restricted to some repository ids, and actual POM has no matching repository id declared), Maven just tells the user that the artifact could not be resolved. This leads to confusion from users who find the .jar files in their local repository without knowing this restriction feature: they just get frustrated and complain that maven sucks. It would be good if Maven was updated with some improved error messages along the lines of: The (GAV) artifact was found in your local repository, but came from remote repository xxx: either configure this in your pom with (insert sample XML block in error message), or in your yyy mirror. The mirror section of the error message should be included -if- the current ~/.m2/settings.xml declares a mirror. By improving the messages here we can help the users move on to building software, rather than pulling out their hair :) [1] http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5366) [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4
[ https://jira.codehaus.org/browse/MNG-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5366: --- Fix Version/s: (was: 3.1.x) 3.2 [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4 -- Key: MNG-5366 URL: https://jira.codehaus.org/browse/MNG-5366 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.4, 3.0.5 Reporter: Paul Gier Fix For: 3.2 Using Maven 3.0.4, artifacts can only be resolved a single time during the build lifecycle using the Maven 2.x dependency resolution API. Using resolver.resolveAlways() should force re-resolution of the artifact, however if the artifact was already resolved once during the build, then it will not be re-resolved even when calling resolveAlways(). This works as expected in Maven 3.0.0-3.0.3, and the artifact is re-resolved. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5162) Maven stuck on downloading dependencies when using java 7.
[ https://jira.codehaus.org/browse/MNG-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5162: --- Fix Version/s: (was: 3.1.x) 3.2 Maven stuck on downloading dependencies when using java 7. -- Key: MNG-5162 URL: https://jira.codehaus.org/browse/MNG-5162 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.1, 3.0.3 Environment: Windows 7 Professional x64 Reporter: Lukas Stampf Fix For: 3.2 Attachments: dump.tdump, edb.zip, java6.jpg, java7.jpg When JAVA_HOME is set to the Java 7 JDK and I run mvn clean install on my project the following happens: Maven downloads the dependencies to my local repository, as usual, but on some dependencies he stops while downloading and never continues. He is just stuck. I then must use CTRL+C and start from the beginning with my build, but it doesnt help because he gets stuck at the same dependencies again. In my local repository, where the failed dependency belongs is just a tmp file like: org.apache.servicemix.bundles.serp-1.13.1_4.jar.tmp90088a9d7e9e4642 When I set JAVA_HOME to java 6 Update 27 everything works fine. The problem does not seem to be related to JAR size because, I saw it fail on 19kb dependencies as well. I have the impression it happens mostly to JARs with long names. Attached you will find a subproject of the project I am working on. it contains the org.apache.servicemix.bundles.serp-1.13.1_4 dependency, which is one of almost all servicemix bundles that is failing for me, when i use java7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5091) Add option to fail build if WARNING's appear in POM
[
https://jira.codehaus.org/browse/MNG-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5091:
---
Fix Version/s: (was: 3.1.x)
3.2
Add option to fail build if WARNING's appear in POM
---
Key: MNG-5091
URL: https://jira.codehaus.org/browse/MNG-5091
Project: Maven 2 3
Issue Type: Improvement
Components: Command Line, POM
Affects Versions: 3.0.3
Reporter: Karl Heinz Marbaise
Priority: Minor
Fix For: 3.2
Attachments: MNG-5091-maven-embedder.patch
It would be nice to have the option to let a build fail if something like
this will appear:
{code}
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for com.soebes.training.module:050-project-without-warnings:jar:0.1.0-SNAPSHOT
[WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
be unique: org.slf4j:slf4j-api:jar - duplicate declaration of version 1.6.1
@ line 28, column 14
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
{code}
This shoud be done for WARNING's in case of missing versions for plugins etc.
Currently it is possible to set the Validation leven in Jenkins/Hudson
already but it is not possible on command line. So an option on command line
like:
{code}
mvn --fail-warning ...
{code}
would be great. Or may be a good supplemental option to set the validation
level like:
{code}
mvn --validation-level MINIMAL
mvn --validation-level MAVEN20
mvn --validation-level MAVEN30
mvn --validation-level MAVEN31
mvn --validation-level DEFAULT
{code}
or may be both. May this might be an enhancement for Maven 3.0.4 ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5553) ${map(some.key)} is not properly interpolated
[
https://jira.codehaus.org/browse/MNG-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5553.
--
Resolution: Fixed
${map(some.key)} is not properly interpolated
-
Key: MNG-5553
URL: https://jira.codehaus.org/browse/MNG-5553
Project: Maven 2 3
Issue Type: Bug
Components: Inheritance and Interpolation
Reporter: Igor Fedorenko
Assignee: Igor Fedorenko
Fix For: 3.2
Attachments: dotted-map-key.zip
Plexus ReflectionValueExtractor does not correctly handle mapped properties
when map key contains '.' (dot). I will use this jira to track both changes
to plexus-util and corresponding changes to maven.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5075) MavenProject.getParent throws undocumented ISE
[
https://jira.codehaus.org/browse/MNG-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MNG-5075.
-
Resolution: Fixed
Assignee: Stephen Connolly
2eb419ed95ccfdd80c5755890e649a49274cceca
MavenProject.getParent throws undocumented ISE
--
Key: MNG-5075
URL: https://jira.codehaus.org/browse/MNG-5075
Project: Maven 2 3
Issue Type: Bug
Components: Embedding
Affects Versions: 3.0.3
Reporter: Jesse Glick
Assignee: Stephen Connolly
Fix For: 3.2
Attachments: MavenProject-getParent-ISE.diff
http://bugzilla-attachments-197994.netbeans.org/bugzilla/attachment.cgi?id=107899
shows a stack trace encountered when calling {{MavenProject.getParent}} on a
project with some errors (probably POMs missing in the local repository).
This method has no Javadoc comment, so it is hard to know exactly what it is
permitted/supposed to do, but {{hasParent}} implies that {{null}} is a valid
return value, and there is no {{throws IllegalStateException}} clause. The
attached patch brings the behavior in line with that signature. (I think I
got the {{PlexusTestCase}} infrastructure working with all the required
wiring but it may be possible to simplify the test case.)
Cleaner might be to just declare {{getParent}} (and also {{hasParent}}?) to
throw {{ProjectBuildingException}}, though this would be a
source-incompatible change. (Only binary-incompatible for clients which are
already catching {{IllegalStateException}}!)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5470) Fix license headers on source files
[
https://jira.codehaus.org/browse/MNG-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MNG-5470.
-
Resolution: Fixed
Fix Version/s: (was: 3.2)
3.1.0
Assignee: Stephen Connolly
This was closed as part of the 3.1.0 release... the separate issue of the test
resources is not resolved though
Fix license headers on source files
---
Key: MNG-5470
URL: https://jira.codehaus.org/browse/MNG-5470
Project: Maven 2 3
Issue Type: Task
Components: General
Affects Versions: 3.1.0-alpha-1
Reporter: Stephen Connolly
Assignee: Stephen Connolly
Priority: Blocker
Fix For: 3.1.0
Attachments: rat.txt
RAT is reporting GIT HASH 262b9bb1ef91d1414e5162d9dd0f5522e7186202 has 391
files that are either missing license headers or have not been flagged as
files that cannot support a license header.
Most of these are test data files and I would be happy to argue that the test
may require a specific exact content for reproducibility, but the following I
do not feel we can make a case for:
{code}
apache-maven/src/bin/m2.conf
apache-maven/src/conf/logging/simplelogger.properties
maven-aether-provider/src/main/java/org/apache/maven/repository/internal/package.html
maven-aether-provider/src/site/apt/index.apt
maven-artifact/src/site/apt/index.apt
maven-compat/compatibility.cfl
maven-compat/src/main/resources/META-INF/maven/plugin.xml
maven-core/lifecycle-executor.txt
maven-core/plugin-manager.txt
maven-core/project-builder.txt
maven-core/src/main/resources/org/apache/maven/messages/build.properties
maven-core/src/site/apt/artifact-handlers.apt
maven-core/src/site/apt/configuration-management.apt
maven-core/src/site/apt/default-bindings.apt.vm
maven-core/src/site/apt/getting-to-container-configured-mojos.apt
maven-core/src/site/apt/index.apt
maven-core/src/site/apt/inheritance.apt
maven-core/src/site/apt/lifecycles.apt.vm
maven-core/src/site/apt/offline-mode.apt
maven-core/src/site/apt/plugin-execution-isolation.apt
maven-core/src/site/apt/scripting-support/marmalade-support.apt
maven-core/src/site/resources/design/2.1-lifecycle-refactor.graffle
maven-embedder/src/examples/simple-project/src/main/java/org/apache/maven/embedder/App.java
maven-embedder/src/examples/simple-project/src/test/java/org/apache/maven/embedder/AppTest.java
maven-embedder/src/main/resources/META-INF/MANIFEST.MF
maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
maven-embedder/src/site/apt/cli.apt.vm
maven-embedder/src/site/apt/index.apt.vm
maven-embedder/src/site/apt/logging.apt
maven-model/src/main/java/org/apache/maven/model/io/xpp3/package.html
maven-model/src/main/java/org/apache/maven/model/merge/package.html
maven-model/src/main/java/org/apache/maven/model/package.html
maven-model/src/site/apt/index.apt
maven-model-builder/src/site/apt/index.apt
maven-model-builder/src/site/apt/super-pom.apt.vm
maven-plugin-api/src/site/apt/index.apt
maven-plugin-api/src/test/resources/plugin.xml
maven-repository-metadata/src/site/apt/index.apt
maven-settings/src/site/apt/index.apt
{code}
Attached is the full RAT report
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGINTESTING-34) Documentation: sample code using MojoRule doesn't work
Laird Nelson created MPLUGINTESTING-34:
--
Summary: Documentation: sample code using MojoRule doesn't work
Key: MPLUGINTESTING-34
URL: https://jira.codehaus.org/browse/MPLUGINTESTING-34
Project: Maven Plugin Testing
Issue Type: Bug
Components: plugin-testing-harness
Affects Versions: 3.0.0
Reporter: Laird Nelson
The cookbook reachable from
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/getting-started/index.html
includes code like this:
{code:java}
File pom = rule.getTestFile( src/test/resources/unit/project-to-test/pom.xml
);
{code}
This method does not exist on {{MojoRule}}
(http://maven.apache.org/plugin-testing/maven-plugin-testing-harness/apidocs/org/apache/maven/plugin/testing/MojoRule.html).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5556) org.jvnet.jax-ws-commons:jaxws-maven-plugin:2.3.1-b03
[ https://jira.codehaus.org/browse/MNG-5556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=338087#comment-338087 ] Robert Scholte commented on MNG-5556: - Could you complete the following fields: * groupId org.jvnet.jax-ws-commons * artifactId jaxws-maven-plugin * affected goal * Plugin Name * Compatible Version * Related Issues org.jvnet.jax-ws-commons:jaxws-maven-plugin:2.3.1-b03 - Key: MNG-5556 URL: https://jira.codehaus.org/browse/MNG-5556 Project: Maven 2 3 Issue Type: Bug Reporter: Archimedes Trajano The plugin groupIdorg.jvnet.jax-ws-commons/groupId artifactIdjaxws-maven-plugin/artifactId version2.3.1-b03/version Does not work on Maven 3.1.1 Please add to https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound (I can't seem to comment or add to the list) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5556) Document org.jvnet.jax-ws-commons:jaxws-maven-plugin:2.3.1-b03 fails with AetherClassNotFound
[
https://jira.codehaus.org/browse/MNG-5556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5556:
Component/s: Documentation: Faqs
Description:
The plugin
{code:xml}
groupIdorg.jvnet.jax-ws-commons/groupId
artifactIdjaxws-maven-plugin/artifactId
version2.3.1-b03/version
{code}
Does not work on Maven 3.1.1
Please add to
https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound (I can't
seem to comment or add to the list)
was:
The plugin
groupIdorg.jvnet.jax-ws-commons/groupId
artifactIdjaxws-maven-plugin/artifactId
version2.3.1-b03/version
Does not work on Maven 3.1.1
Please add to
https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound (I can't
seem to comment or add to the list)
Priority: Minor (was: Major)
Issue Type: Task (was: Bug)
Summary: Document org.jvnet.jax-ws-commons:jaxws-maven-plugin:2.3.1-b03
fails with AetherClassNotFound (was:
org.jvnet.jax-ws-commons:jaxws-maven-plugin:2.3.1-b03)
Document org.jvnet.jax-ws-commons:jaxws-maven-plugin:2.3.1-b03 fails with
AetherClassNotFound
-
Key: MNG-5556
URL: https://jira.codehaus.org/browse/MNG-5556
Project: Maven 2 3
Issue Type: Task
Components: Documentation: Faqs
Reporter: Archimedes Trajano
Priority: Minor
The plugin
{code:xml}
groupIdorg.jvnet.jax-ws-commons/groupId
artifactIdjaxws-maven-plugin/artifactId
version2.3.1-b03/version
{code}
Does not work on Maven 3.1.1
Please add to
https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound (I
can't seem to comment or add to the list)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5554) Please delete old releases from mirroring system
[ https://jira.codehaus.org/browse/MNG-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-5554. --- Resolution: Fixed Assignee: Robert Scholte Fixed in rev. 4049 Please delete old releases from mirroring system Key: MNG-5554 URL: https://jira.codehaus.org/browse/MNG-5554 Project: Maven 2 3 Issue Type: Task Environment: https://dist.apache.org/repos/dist/release/maven/maven-3/3.1.0-alpha-1/ Reporter: SebbASF Assignee: Robert Scholte To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [Note that older releases are always available from the ASF archive server] [1] http://www.apache.org/dev/release.html#when-to-archive -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1049) Printing running test after test is completed
[ https://jira.codehaus.org/browse/SUREFIRE-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte moved MNG-5548 to SUREFIRE-1049: --- Key: SUREFIRE-1049 (was: MNG-5548) Project: Maven Surefire (was: Maven 2 3) Printing running test after test is completed --- Key: SUREFIRE-1049 URL: https://jira.codehaus.org/browse/SUREFIRE-1049 Project: Maven Surefire Issue Type: Bug Environment: At least Linux, but I believe all environments are affected. Reporter: Leonardo Leite Priority: Trivial Problem: the message running test name is printed just after the test is completed, being printed together the message Tests run: X, Failures: Y Consequence: when a test gets frozen, I do not know which test is frozen! Desired behavior: print running test name when the test execution starts, and print Tests run: X, Failures: Y ... when the test execution finishes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5532) Adding repository error running mvn clean
[ https://jira.codehaus.org/browse/MNG-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-5532. --- Resolution: Not A Bug Assignee: Robert Scholte To be correct: this is not a Maven bug, but an Eclipse Tycho/Equinox issue and should be reported there. I found [this thread|http://dev.eclipse.org/mhonarc/lists/tycho-user/msg04916.html] which might help. Adding repository error running mvn clean - Key: MNG-5532 URL: https://jira.codehaus.org/browse/MNG-5532 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.1.1 Environment: Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400) Maven home: C:\apache-maven-3.1.1 Java version: 1.7.0_40, vendor: Oracle Corporation Java home: C:\Java\jdk1.7.0.40-x64\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gregg Stewart Assignee: Robert Scholte Attachments: debug.log Problem: While running mvn clean I receive some exceptions while: Adding repository http://download.eclipse.org/eclipse/updates/license The -X debug output has been attached to see the full error. I've also provided instructions on how I receive this error. The first exception is: java.lang.ClassCastException: org.eclipse.tycho.p2.remote.RemoteMetadataRepositoryManager cannot be cast to org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager I have to admit that I'm pretty new to building eclipse and using maven. My apologies if this is not a valid bug. I'm doing some more research to see if I am missing something. I'm not clear whether this is a problem with Maven or the maybe the POM. I'm opening the bug under Maven since I found this at the end of the error: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException I believe I received something similar while using the eclipse plugin so decided to download/use apache maven outside of eclipse to see if i received the same problem. After extracting maven, changing some maven environment variables, i re-extracted the zip i downloaded and tried using the mvn binary. But it looks like it failed in the same place. STEPS TO REPRODUCE: 1. Go to http://download.eclipse.org/eclipse/downloads/drops4/R-4.3.1-201309111000/ 2. click the link for View the repositories used for the current build. 3. copy/paste the URL for: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit?id=629251e64d8bebd34caca0939ee2e4c460eee609 4. download the file: eclipse.platform.releng.aggregator-629251e64d8bebd34caca0939ee2e4c460eee609.zip 5. rename my existing .m2 repository folder to .m2.old (because I had a bunch of stuff in there from training stuff). 6. extract the file from step 4 to my C:\apache-maven-3.1.1 directory. 7. open a command prompt and cd to the directory: C:\apache-maven-3.1.1\eclipse.platform\eclipse.platform.releng.tychoeclipsebuilder\platform 8. run: mvn clean 9. receive error while: Adding repository http://download.eclipse.org/eclipse/updates/license Kind regards, Gregg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5528) Help text confuses people
[
https://jira.codehaus.org/browse/MNG-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=338090#comment-338090
]
Robert Scholte commented on MNG-5528:
-
Well, AFAIK the text reflects actually what it does. If you try to use a
certain released version which isn't yet available in a (mirrored) remote
repository, Maven will remember this for an amount of time before trying to
resolve it again. The {{-U}} forces Maven the look again for the specific
artifact.
Help text confuses people
-
Key: MNG-5528
URL: https://jira.codehaus.org/browse/MNG-5528
Project: Maven 2 3
Issue Type: Bug
Components: Command Line
Affects Versions: 3.1.0
Environment: any
Reporter: Chris Erskine
Priority: Minor
When the 'mvn --help' command is used, the output for -U states Forces a
check for updated releases and snapshots on remote repositories. This
confuses a lot of users into thinking that this option will update released
versions of artifacts.
Could this be changed to something like Forces a check for updated snapshots
on remote repositories
This would solve a number of problems that I have seen at different sites
where people think they can patch a finally released artifact and it is
updated in the local repository with the -U option.
Updating the help text would then roll into documentation where the text is
copied into it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-678) Assembly using repositories mucks with classpath for later portions of the build
[ https://jira.codehaus.org/browse/MASSEMBLY-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte moved MNG-5531 to MASSEMBLY-678: --- Complexity: (was: Intermediate) Component/s: (was: Plugins and Lifecycle) Affects Version/s: (was: 3.1.0) Key: MASSEMBLY-678 (was: MNG-5531) Project: Maven Assembly Plugin (was: Maven 2 3) Assembly using repositories mucks with classpath for later portions of the build -- Key: MASSEMBLY-678 URL: https://jira.codehaus.org/browse/MASSEMBLY-678 Project: Maven Assembly Plugin Issue Type: Bug Environment: OSX, jdk8 Reporter: bob mcwhirter If a maven-assembly-plugin execution run during the 'package' phase includes a repositories element to gather up dependencies, it appears that dependency filtering is performed, removing dependencies with scope of 'test'. This breaks integration tests that run subsequent to 'package' phase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-256) @Parameter annotation requires property element to use command-line -D
[ https://jira.codehaus.org/browse/MPLUGIN-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte moved MNG-5518 to MPLUGIN-256: - Complexity: (was: Intermediate) Component/s: (was: Plugin API) maven-plugin-annotations Affects Version/s: (was: 3.1.0) (was: 3.0.4) Key: MPLUGIN-256 (was: MNG-5518) Project: Maven Plugin Tools (was: Maven 2 3) @Parameter annotation requires property element to use command-line -D -- Key: MPLUGIN-256 URL: https://jira.codehaus.org/browse/MPLUGIN-256 Project: Maven Plugin Tools Issue Type: Bug Components: maven-plugin-annotations Environment: Windows 7 Pro 64 bit, JDK 1.7.0_40 Reporter: Robert Patrick Attachments: annotations.zip When writing a plugin using the Maven Java annotations, the @Parameter annotation currently requires the property element to allow the goal to receive configuration information from the command-line using -DparamName=value even though the goal works fine without it when using a POM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-256) @Parameter annotation requires property element to use command-line -D
[ https://jira.codehaus.org/browse/MPLUGIN-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MPLUGIN-256. -- Resolution: Not A Bug Assignee: Robert Scholte This is indeed intended behavior. @Parameter annotation requires property element to use command-line -D -- Key: MPLUGIN-256 URL: https://jira.codehaus.org/browse/MPLUGIN-256 Project: Maven Plugin Tools Issue Type: Bug Components: maven-plugin-annotations Environment: Windows 7 Pro 64 bit, JDK 1.7.0_40 Reporter: Robert Patrick Assignee: Robert Scholte Attachments: annotations.zip When writing a plugin using the Maven Java annotations, the @Parameter annotation currently requires the property element to allow the goal to receive configuration information from the command-line using -DparamName=value even though the goal works fine without it when using a POM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5516) ${project.basedir} in profile activation exists clause strange behavior
[
https://jira.codehaus.org/browse/MNG-5516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5516:
Description:
directory structure:
{noformat}
pom.xml
dir
{noformat}
relevant pom part:
{code:xml}
profiles
profile
idP1/id
activation
file
exists${project.basedir}/dir//exists
/file
/activation
/profile
profile
idP2/id
activation
file
exists${basedir}/dir//exists
/file
/activation
/profile
/profiles
{code}
{noformat}
mvn help:profiles-all
Profile Id: P2 (Active: true , Source: pom)
Profile Id: P1 (Active: false , Source: pom)
{noformat}
Since dir exists this leads to conclusion that $\{project.basedir} in P1 does
not resolve properly.
{noformat}
mvn help:effective-pom relevant part:
{noformat}
{code:xml}
profiles
profile
idP1/id
activation
file
exists/home/isipka/NetBeansProjects/test-maven/simple/dir//exists
/file
/activation
/profile
profile
idP2/id
activation
file
exists/home/isipka/NetBeansProjects/test-maven/simple/dir//exists
/file
/activation
/profile
/profiles
{code}
both $\{project.basedir} in P1 and $\{basedir} in P2 have resolved properly.
AFAIK this is a bug. If not, or you need additional info please contact me. I
have tested this on 3.0.5 the behavior is the same. I have found out about it
here http://stackoverflow.com/q/18868772/679982
was:
directory structure:
pom.xml
dir
relevant pom part:
profiles
profile
idP1/id
activation
file
exists${project.basedir}/dir//exists
/file
/activation
/profile
profile
idP2/id
activation
file
exists${basedir}/dir//exists
/file
/activation
/profile
/profiles
mvn help:profiles-all
Profile Id: P2 (Active: true , Source: pom)
Profile Id: P1 (Active: false , Source: pom)
Since dir exists this leads to conclusion that ${project.basedir} in P1 does
not resolve properly.
mvn help:effective-pom relevant part:
profiles
profile
idP1/id
activation
file
exists/home/isipka/NetBeansProjects/test-maven/simple/dir//exists
/file
/activation
/profile
profile
idP2/id
activation
file
exists/home/isipka/NetBeansProjects/test-maven/simple/dir//exists
/file
/activation
/profile
/profiles
both ${project.basedir} in P1 and ${basedir} in P2 have resolved properly.
AFAIK this is a bug. If not, or you need additional info please contact me. I
have tested this on 3.0.5 the behavior is the same. I have found out about it
here http://stackoverflow.com/q/18868772/679982
${project.basedir} in profile activation exists clause strange behavior
---
Key: MNG-5516
URL: https://jira.codehaus.org/browse/MNG-5516
Project: Maven 2 3
Issue Type: Bug
Components: Profiles
Affects Versions: 3.0.5, 3.1.0
Environment: uname -a
Linux localhost 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
mvn -version
Apache Maven 3.1.0 (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-28
04:15:32+0200)
Maven home: /usr/local/apache-maven/apache-maven-3.1.0
Java version: 1.6.0_37, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/jdk1.6.0_37/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 3.2.0-23-generic, arch: amd64, family: unix
Reporter: Ivan ?ipka
Priority: Minor
Attachments: project.tar.gz
directory structure:
{noformat}
pom.xml
dir
{noformat}
relevant pom part:
{code:xml}
profiles
profile
idP1/id
activation
file
exists${project.basedir}/dir//exists
/file
/activation
/profile
profile
idP2/id
activation
file
exists${basedir}/dir//exists
/file
/activation
/profile
/profiles
{code}
{noformat}
mvn
[jira] (MNG-5516) ${project.basedir} in profile activation exists clause strange behavior
[
https://jira.codehaus.org/browse/MNG-5516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-5516.
---
Resolution: Not A Bug
Assignee: Robert Scholte
This is by design, see http://maven.apache.org/pom.html#Activation
${project.basedir} in profile activation exists clause strange behavior
---
Key: MNG-5516
URL: https://jira.codehaus.org/browse/MNG-5516
Project: Maven 2 3
Issue Type: Bug
Components: Profiles
Affects Versions: 3.0.5, 3.1.0
Environment: uname -a
Linux localhost 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
mvn -version
Apache Maven 3.1.0 (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-28
04:15:32+0200)
Maven home: /usr/local/apache-maven/apache-maven-3.1.0
Java version: 1.6.0_37, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/jdk1.6.0_37/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 3.2.0-23-generic, arch: amd64, family: unix
Reporter: Ivan ?ipka
Assignee: Robert Scholte
Priority: Minor
Attachments: project.tar.gz
directory structure:
{noformat}
pom.xml
dir
{noformat}
relevant pom part:
{code:xml}
profiles
profile
idP1/id
activation
file
exists${project.basedir}/dir//exists
/file
/activation
/profile
profile
idP2/id
activation
file
exists${basedir}/dir//exists
/file
/activation
/profile
/profiles
{code}
{noformat}
mvn help:profiles-all
Profile Id: P2 (Active: true , Source: pom)
Profile Id: P1 (Active: false , Source: pom)
{noformat}
Since dir exists this leads to conclusion that $\{project.basedir} in P1 does
not resolve properly.
{noformat}
mvn help:effective-pom relevant part:
{noformat}
{code:xml}
profiles
profile
idP1/id
activation
file
exists/home/isipka/NetBeansProjects/test-maven/simple/dir//exists
/file
/activation
/profile
profile
idP2/id
activation
file
exists/home/isipka/NetBeansProjects/test-maven/simple/dir//exists
/file
/activation
/profile
/profiles
{code}
both $\{project.basedir} in P1 and $\{basedir} in P2 have resolved properly.
AFAIK this is a bug. If not, or you need additional info please contact me. I
have tested this on 3.0.5 the behavior is the same. I have found out about it
here http://stackoverflow.com/q/18868772/679982
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5476) [REGRESSION] @required parameter not being enforced for arrays
[
https://jira.codehaus.org/browse/MNG-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5476:
Summary: [REGRESSION] @required parameter not being enforced for arrays
(was: [REGRESSION] @required parameter not being enforced.)
[REGRESSION] @required parameter not being enforced for arrays
--
Key: MNG-5476
URL: https://jira.codehaus.org/browse/MNG-5476
Project: Maven 2 3
Issue Type: Bug
Components: POM
Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5
Reporter: Chris Graham
For a plugin that has the following parameters defined:
{code}
/**
* The message flows to be added to the bar file.
* @parameter expression=${msgFlows}
* @required
*/
private String[] msgFlows;
/**
* The message sets to be added to the bar file.
* @parameter expression=${msgSets}
* @required
*/
private String[] msgSets;
{code}
and a pom config snippet of (note missing the msgSets):
{code:xml}
configuration
msgFlows
msgFlow/
/msgFlows
/configuration
{code}
maven 2.x (2.09 and 2.2.1) will correctly fail with the following error:
{code}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] One or more required plugin parameters are invalid/missing for
'message-broker:package-bar-file'
[0] Inside the definition for plugin 'maven-message-broker-plugin' specify
the following:
configuration
...
msgSetsVALUE/msgSets
/configuration
OR
on the command line, specify: '-DmsgSets=VALUE'
{code}
However, maven 3.x (3.0-beta-1 through to 3.0.5) do NOT enforce this.
I would expect the build to be failed in the same manner as 2.x.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5302) Include thread number in output messages
[
https://jira.codehaus.org/browse/MNG-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-5302.
---
Resolution: Fixed
Fix Version/s: 3.1.0
Assignee: Robert Scholte
By switching to SLF4J as the logging framework this option has become available.
http://maven.apache.org/maven-logging.html
Just set {{org.slf4j.simpleLogger.showThreadName}} to {{true}}
Include thread number in output messages
Key: MNG-5302
URL: https://jira.codehaus.org/browse/MNG-5302
Project: Maven 2 3
Issue Type: Improvement
Components: Logging
Affects Versions: 3.0.4
Reporter: George Lindholm
Assignee: Robert Scholte
Priority: Minor
Fix For: 3.1.0
When doing a parallel build the log messages are mixed up making it hard to
determine what module a message comes from. If the thread number is included
in the log message it would make it easier to see what is going on,
especially when the debug flag is used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5557) Limit the reactor to the projects that are specified using --projects
[ https://jira.codehaus.org/browse/MNG-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5557: --- Fix Version/s: 3.2 Assignee: Jason van Zyl Limit the reactor to the projects that are specified using --projects - Key: MNG-5557 URL: https://jira.codehaus.org/browse/MNG-5557 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.1.1 Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 3.2 Currently when --projects is used all of the projects that are listed in the modules section are loaded and used insided of the ReactorReader instead of being constrained to the list of projects specified. This causes inconsistencies in resolution between what the user expects to be available in the reactor and what actually is. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5557) Limit the reactor to the projects that are specified using --projects
Jason van Zyl created MNG-5557: -- Summary: Limit the reactor to the projects that are specified using --projects Key: MNG-5557 URL: https://jira.codehaus.org/browse/MNG-5557 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.1.1 Reporter: Jason van Zyl Currently when --projects is used all of the projects that are listed in the modules section are loaded and used insided of the ReactorReader instead of being constrained to the list of projects specified. This causes inconsistencies in resolution between what the user expects to be available in the reactor and what actually is. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5176) Print build times in an ISO 8601-style manner
[
https://jira.codehaus.org/browse/MNG-5176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5176:
Assignee: Michael Osipov
Print build times in an ISO 8601-style manner
-
Key: MNG-5176
URL: https://jira.codehaus.org/browse/MNG-5176
Project: Maven 2 3
Issue Type: Improvement
Components: Logging
Affects Versions: 2.2.1, 3.0.3
Environment: Maven 2.2.1 and 3.0.3
Reporter: Michael Osipov
Assignee: Michael Osipov
Attachments: MNG-5176.patch
The current output of build times is hard to read and does not follow any
standard. I have patched branch 2.2.x and 3 trunk to follow ISO 8601-style
date/time formats.
My patches need less code compared to the current solution. I had the
following ideas in mind:
1. Display times in the same proportional format.
2. hour display is fixed to max 24 h as in ISO defined.
3. Days are directly integrated, not brain math necessary anymore. Though
this should be a rare case.
3. remove the smallest component if a bigger one is added.
4. Easier to parse, predictable output.
More over, I have changed the finish and total time to ISO too. I did not
touch the finish time in Maven 2.2.x because it is alphanumeric. I'd rather
prefer that as total time but this is maybe a matter of taste and harder to
parse.
This is a real output:
{noformat}
[INFO] Building tar :
/.amd_mnt/blnn728x/home/osipovmi/Projekte/maven-3/apache-maven/target/apache-maven-3.0.4-SNAPSHOT-bin.tar.gz
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Maven .. SUCCESS [00:04.732]
[INFO] Maven Model ... SUCCESS [00:06.332]
[INFO] Maven Artifact SUCCESS [00:02.551]
[INFO] Maven Plugin API .. SUCCESS [00:03.855]
[INFO] Maven Model Builder ... SUCCESS [00:06.708]
[INFO] Maven Settings SUCCESS [00:02.292]
[INFO] Maven Settings Builder SUCCESS [00:02.138]
[INFO] Maven Repository Metadata Model ... SUCCESS [00:01.931]
[INFO] Maven Aether Provider . SUCCESS [00:02.442]
[INFO] Maven Core SUCCESS [00:28.509]
[INFO] Maven Compat .. SUCCESS [00:20.260]
[INFO] Maven Embedder SUCCESS [00:03.478]
[INFO] Maven Distribution SUCCESS [00:26.715]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 01:52.618
[INFO] Finished at: 2011-09-19 14:25:24
[INFO] Final Memory: 36M/144M
[INFO]
{noformat}
A crafted output with all formats would look like this:
{noformat}
[INFO] Building tar :
/.amd_mnt/blnn728x/home/osipovmi/Projekte/maven-3/apache-maven/target/apache-maven-3.0.4-SNAPSHOT-bin.tar.gz
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Maven .. SUCCESS [1 d 03:04]
[INFO] Maven Model ... SUCCESS [01:00:06]
[INFO] Maven Artifact SUCCESS [00:02.551]
[INFO] Maven Plugin API .. SUCCESS [00:03.855]
[INFO] Maven Model Builder ... SUCCESS [00:06.708]
[INFO] Maven Settings SUCCESS [00:02.292]
[INFO] Maven Settings Builder SUCCESS [00:02.138]
[INFO] Maven Repository Metadata Model ... SUCCESS [00:01.931]
[INFO] Maven Aether Provider . SUCCESS [00:02.442]
[INFO] Maven Core SUCCESS [00:28.509]
[INFO] Maven Compat .. SUCCESS [00:20.260]
[INFO] Maven Embedder SUCCESS [00:03.478]
[INFO] Maven Distribution SUCCESS [00:26.715]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1 d 03:05
[INFO] Finished at: 2011-09-19 14:25:24
[INFO] Final Memory: 36M/144M
[INFO]
{noformat}
Since most build
[jira] (MNG-5176) Print build times in an ISO 8601-style manner
[
https://jira.codehaus.org/browse/MNG-5176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=338095#comment-338095
]
Michael Osipov commented on MNG-5176:
-
Robert, do you think further discussion is necessary on dev@? Otherwise I would
apply the patch to 3.2.x without further modification.
Print build times in an ISO 8601-style manner
-
Key: MNG-5176
URL: https://jira.codehaus.org/browse/MNG-5176
Project: Maven 2 3
Issue Type: Improvement
Components: Logging
Affects Versions: 2.2.1, 3.0.3
Environment: Maven 2.2.1 and 3.0.3
Reporter: Michael Osipov
Assignee: Michael Osipov
Attachments: MNG-5176.patch
The current output of build times is hard to read and does not follow any
standard. I have patched branch 2.2.x and 3 trunk to follow ISO 8601-style
date/time formats.
My patches need less code compared to the current solution. I had the
following ideas in mind:
1. Display times in the same proportional format.
2. hour display is fixed to max 24 h as in ISO defined.
3. Days are directly integrated, not brain math necessary anymore. Though
this should be a rare case.
3. remove the smallest component if a bigger one is added.
4. Easier to parse, predictable output.
More over, I have changed the finish and total time to ISO too. I did not
touch the finish time in Maven 2.2.x because it is alphanumeric. I'd rather
prefer that as total time but this is maybe a matter of taste and harder to
parse.
This is a real output:
{noformat}
[INFO] Building tar :
/.amd_mnt/blnn728x/home/osipovmi/Projekte/maven-3/apache-maven/target/apache-maven-3.0.4-SNAPSHOT-bin.tar.gz
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Maven .. SUCCESS [00:04.732]
[INFO] Maven Model ... SUCCESS [00:06.332]
[INFO] Maven Artifact SUCCESS [00:02.551]
[INFO] Maven Plugin API .. SUCCESS [00:03.855]
[INFO] Maven Model Builder ... SUCCESS [00:06.708]
[INFO] Maven Settings SUCCESS [00:02.292]
[INFO] Maven Settings Builder SUCCESS [00:02.138]
[INFO] Maven Repository Metadata Model ... SUCCESS [00:01.931]
[INFO] Maven Aether Provider . SUCCESS [00:02.442]
[INFO] Maven Core SUCCESS [00:28.509]
[INFO] Maven Compat .. SUCCESS [00:20.260]
[INFO] Maven Embedder SUCCESS [00:03.478]
[INFO] Maven Distribution SUCCESS [00:26.715]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 01:52.618
[INFO] Finished at: 2011-09-19 14:25:24
[INFO] Final Memory: 36M/144M
[INFO]
{noformat}
A crafted output with all formats would look like this:
{noformat}
[INFO] Building tar :
/.amd_mnt/blnn728x/home/osipovmi/Projekte/maven-3/apache-maven/target/apache-maven-3.0.4-SNAPSHOT-bin.tar.gz
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Maven .. SUCCESS [1 d 03:04]
[INFO] Maven Model ... SUCCESS [01:00:06]
[INFO] Maven Artifact SUCCESS [00:02.551]
[INFO] Maven Plugin API .. SUCCESS [00:03.855]
[INFO] Maven Model Builder ... SUCCESS [00:06.708]
[INFO] Maven Settings SUCCESS [00:02.292]
[INFO] Maven Settings Builder SUCCESS [00:02.138]
[INFO] Maven Repository Metadata Model ... SUCCESS [00:01.931]
[INFO] Maven Aether Provider . SUCCESS [00:02.442]
[INFO] Maven Core SUCCESS [00:28.509]
[INFO] Maven Compat .. SUCCESS [00:20.260]
[INFO] Maven Embedder SUCCESS [00:03.478]
[INFO] Maven Distribution SUCCESS [00:26.715]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1 d 03:05
[INFO]
[jira] (MNG-5528) Help text confuses people
[ https://jira.codehaus.org/browse/MNG-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=338096#comment-338096 ] Chris Erskine commented on MNG-5528: I agree that the current text is what is done but people read it that 'updated releases' will replace V2.5 with an updated V2.5. They do not pickup that maven does not replace an existing version. I have had this problem at a number of sites that I have gone into where they think they can update the current version and do a -U to update the local repository rather than creating a new version number. Maybe adding that it does not update current released versions. Help text confuses people - Key: MNG-5528 URL: https://jira.codehaus.org/browse/MNG-5528 Project: Maven 2 3 Issue Type: Bug Components: Command Line Affects Versions: 3.1.0 Environment: any Reporter: Chris Erskine Priority: Minor When the 'mvn --help' command is used, the output for -U states Forces a check for updated releases and snapshots on remote repositories. This confuses a lot of users into thinking that this option will update released versions of artifacts. Could this be changed to something like Forces a check for updated snapshots on remote repositories This would solve a number of problems that I have seen at different sites where people think they can patch a finally released artifact and it is updated in the local repository with the -U option. Updating the help text would then roll into documentation where the text is copied into it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
