[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=340329#comment-340329
]
Michael Osipov commented on MNG-5176:
-
Robert, the leading zero makes the minutes consistent. That was intentional and
reasonable. We could evaluate the following two options:
Make [] always same size and pad with whitespace
1.
{noformat}
[1 d 01:10 h]
[01:02 h]
[ 01:49 min]
[ 22.345 s]
[0.912 s]
{noformat}
2. Left-aligned
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min ]
[22.345 s ]
[0.912 s]
{noformat}
or even
3.
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min]
[22.345 s]
[0.912 s]
{noformat}
I'd prefer option one.
Though I strongly doubt that a duration longer than a day will occur very
option, it should be less than 3 %. In this case one could either say {{24 h+}}
or {{1.2 d}}, decimal day value.
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
Fix For: 3.2
Attachments: MNG-5176.patch, 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
[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=340329#comment-340329
]
Michael Osipov edited comment on MNG-5176 at 1/29/14 3:04 AM:
--
Robert, the leading zero makes the minutes consistent. That was intentional and
reasonable. We could evaluate the following two options:
Make [] always same size and pad with whitespace
1.
{noformat}
[1 d 01:10 h]
[01:02 h]
[ 01:49 min]
[ 22.345 s]
[0.912 s]
{noformat}
2. Left-aligned
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min ]
[22.345 s ]
[0.912 s]
{noformat}
or even
3.
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min]
[22.345 s]
[0.912 s]
{noformat}
I'd prefer option one.
Though I strongly doubt that a duration longer than a day will occur very
option, it should be less than 3 %. In this case one could either say {{24
h+}}, {{1.2 d}}, decimal day value or reduce to {{ 1 d 1 h}} since who cares
for the minutes if you build runs longer than a day.
was (Author: michael-o):
Robert, the leading zero makes the minutes consistent. That was intentional and
reasonable. We could evaluate the following two options:
Make [] always same size and pad with whitespace
1.
{noformat}
[1 d 01:10 h]
[01:02 h]
[ 01:49 min]
[ 22.345 s]
[0.912 s]
{noformat}
2. Left-aligned
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min ]
[22.345 s ]
[0.912 s]
{noformat}
or even
3.
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min]
[22.345 s]
[0.912 s]
{noformat}
I'd prefer option one.
Though I strongly doubt that a duration longer than a day will occur very
option, it should be less than 3 %. In this case one could either say {{24 h+}}
or {{1.2 d}}, decimal day value.
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
Fix For: 3.2
Attachments: MNG-5176.patch, 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 :
[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=340329#comment-340329
]
Michael Osipov edited comment on MNG-5176 at 1/29/14 3:04 AM:
--
Robert, the leading zero makes the minutes consistent. That was intentional and
reasonable. We could evaluate the following two options:
Make [] always same size and pad with whitespace
1.
{noformat}
[1 d 01:10 h]
[01:02 h]
[ 01:49 min]
[ 22.345 s]
[0.912 s]
{noformat}
2. Left-aligned
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min ]
[22.345 s ]
[0.912 s]
{noformat}
or even
3.
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min]
[22.345 s]
[0.912 s]
{noformat}
I'd prefer option one.
Though I strongly doubt that a duration longer than a day will occur very
option, it should be less than 3 %. In this case one could either say {{24
h+}}, {{1.2 d}}, decimal day value or reduce to {{1 d 1 h}} since who cares for
the minutes if you build runs longer than a day.
was (Author: michael-o):
Robert, the leading zero makes the minutes consistent. That was intentional and
reasonable. We could evaluate the following two options:
Make [] always same size and pad with whitespace
1.
{noformat}
[1 d 01:10 h]
[01:02 h]
[ 01:49 min]
[ 22.345 s]
[0.912 s]
{noformat}
2. Left-aligned
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min ]
[22.345 s ]
[0.912 s]
{noformat}
or even
3.
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min]
[22.345 s]
[0.912 s]
{noformat}
I'd prefer option one.
Though I strongly doubt that a duration longer than a day will occur very
option, it should be less than 3 %. In this case one could either say {{24
h+}}, {{1.2 d}}, decimal day value or reduce to {{ 1 d 1 h}} since who cares
for the minutes if you build runs longer than a day.
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
Fix For: 3.2
Attachments: MNG-5176.patch, 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
[jira] (MSCMPUB-4) Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module
[
https://jira.codehaus.org/browse/MSCMPUB-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340333#comment-340333
]
Anthony Whitford commented on MSCMPUB-4:
I will try...
Need a working example for GitHub/gh-pages, preferably naturally linked to
natural site lifecycle, and multi-module
---
Key: MSCMPUB-4
URL: https://jira.codehaus.org/browse/MSCMPUB-4
Project: maven-scm-publish-plugin
Issue Type: Story
Environment: Mac OSX 10.8.2, Java 1.6 Update 35, Maven 3.0.4, Maven
Site Plugin 3.2, Maven SCM Plugin 1.8, Git
Reporter: Anthony Whitford
Priority: Critical
I am trying to update my
[lombok-maven-plugin|http://awhitford.github.com/lombok.maven/lombok-maven-plugin/index.html]
project to use this plugin to publish the project to _Github Pages_.
When I try this command:
{noformat}
mvn clean site site:stage-deploy scm-publish:publish-scm
{noformat}
which is outlined
[here|http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-module-configuration.html],
I get this error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(default-cli) on project lombok-maven: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-log command failed.
[ERROR] Command output:
[ERROR] fatal: ambiguous argument 'master': unknown revision or path not in
the working tree.
[ERROR] Use '--' to separate paths from revisions
{noformat}
(?) Is there a multi-module project in GitHub that uses this plugin that I
can use as an example?
This is what I did so far...
{code:xml}
properties
siteMainDirectory${user.home}/Sites/lombok.maven/siteMainDirectory
scmPubCheckoutDirectory${user.home}/site-content-scm/lombok.maven/scmPubCheckoutDirectory
/properties
...
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.2/version
configuration
skipDeploytrue/skipDeploy
stagingSiteURLfile://${siteMainDirectory}/stagingSiteURL
/configuration
/plugin
...
/plugins
/pluginManagement
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
executions
execution
idstage-for-scm-publish/id
phasepost-site/phase
goals
goalstage/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-publish-plugin/artifactId
version1.0-beta-1/version
configuration
checkoutDirectory${scmPubCheckoutDirectory}/checkoutDirectory
content\${siteMainDirectory}/content
tryUpdatetrue/tryUpdate
scmBranchgh-pages/scmBranch
pubScmUrlscm:git:g...@github.com:awhitford/lombok.maven.git/pubScmUrl
/configuration
executions
execution
idscm-publish/id
phasesite-deploy/phase
goals
goalpublish-scm/goal
/goals
/execution
/executions
/plugin
/plugins
{code}
Finally, I'm really interested in wiring this up so that when I do a normal
{{site-deploy}} or an implicit one through the release process, it gets
published to {{gh-pages}} -- just like I had working with
[wagon-gitsite|https://github.com/awhitford/wagon-gitsite].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-430) default excludes of Abstract*Test not working
[
https://jira.codehaus.org/browse/SUREFIRE-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340334#comment-340334
]
Andreas Höhmann commented on SUREFIRE-430:
--
I'm using 2.16 and see a lot of AbstractXXXTest in my log:
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.71 sec - in
com.siemens.spice.hscm.test.AbstractHscmGoosWebserviceTest
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.476 sec - in
com.siemens.spice.hscm.util.AbstractCustomizationTest
Always with 0 Tests ... of course :)
default excludes of Abstract*Test not working
-
Key: SUREFIRE-430
URL: https://jira.codehaus.org/browse/SUREFIRE-430
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.4
Environment: maven 2.0.7/2.08
Reporter: Robert-Jan Peters
Priority: Critical
The default excludes of Abstract Tests is not backward compatible.
version 2.3.1
excludes =
new ArrayList( Arrays.asList( new String[] {
**/Abstract*Test.java,
**/Abstract*TestCase.java, **/*$* } )
);
version 2.4
excludes =
new ArrayList( Arrays.asList( new String[] { **/*$*
} ) );
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[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=340329#comment-340329
]
Michael Osipov edited comment on MNG-5176 at 1/29/14 5:42 AM:
--
Robert, the leading zero makes the minutes consistent. That was intentional and
reasonable. We could evaluate the following two options:
Make [] always same size and pad with whitespace
1.
{noformat}
[1 d 01:10 h]
[01:02 h]
[ 01:49 min]
[ 22.345 s]
[0.912 s]
{noformat}
2. Left-aligned
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min ]
[22.345 s ]
[0.912 s]
{noformat}
or even
3.
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min]
[22.345 s]
[0.912 s]
{noformat}
I'd prefer option one.
Though I strongly doubt that a duration longer than a day will occur very
option, it should be less than 3 %. In this case one could either say {{24
h+}}, {{1.2 d}}, decimal day value or reduce to {{1 d 1 h}} since who cares for
the minutes if you build runs longer than a day. Alternatively, pad everyhing
to the max length w/o day duration:
{noformat}
[1 d 01:10 h]
[ 1 d 1 h] (alternative 1)
[24 h+] (alternative 2)
[ 01:02 h]
[01:49 min]
[ 22.345 s]
[ 0.912 s]
{noformat}
was (Author: michael-o):
Robert, the leading zero makes the minutes consistent. That was intentional and
reasonable. We could evaluate the following two options:
Make [] always same size and pad with whitespace
1.
{noformat}
[1 d 01:10 h]
[01:02 h]
[ 01:49 min]
[ 22.345 s]
[0.912 s]
{noformat}
2. Left-aligned
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min ]
[22.345 s ]
[0.912 s]
{noformat}
or even
3.
{noformat}
[1 d 01:10 h]
[01:02 h]
[01:49 min]
[22.345 s]
[0.912 s]
{noformat}
I'd prefer option one.
Though I strongly doubt that a duration longer than a day will occur very
option, it should be less than 3 %. In this case one could either say {{24
h+}}, {{1.2 d}}, decimal day value or reduce to {{1 d 1 h}} since who cares for
the minutes if you build runs longer than a day.
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
Fix For: 3.2
Attachments: MNG-5176.patch, 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]
[jira] (MNG-5570) Changes to AbstractMavenLifecycleParticipant breaks Tycho
[ https://jira.codehaus.org/browse/MNG-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5570. --- Resolution: Cannot Reproduce There was no problem with reactor ordering, participants were invoked at the right time. I still added a unit test to make sure I don't question this behaviour in the future. https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=43d67de0451d15f504490ed5adfde032249bd649 Changes to AbstractMavenLifecycleParticipant breaks Tycho - Key: MNG-5570 URL: https://jira.codehaus.org/browse/MNG-5570 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.2 Reporter: Jason van Zyl Assignee: Igor Fedorenko Fix For: 3.2 The participant is now called too late for Tycho to affect dependency ordering. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1911) Building plugins with extensions in a reactor fails
[
https://jira.codehaus.org/browse/MNG-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340366#comment-340366
]
Jason van Zyl commented on MNG-1911:
Trying to build plugins that have extensions that are to be used in the same
build is just a complication in the core we're not going to accommodate. This
is in part because extensions are ill defined and can be used for many things
but trying to make extensions work generally where transport is provided is
very difficult. If, in the future, we define different types of extensions some
of these can likely be accommodated.
Building plugins with extensions in a reactor fails
---
Key: MNG-1911
URL: https://jira.codehaus.org/browse/MNG-1911
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.1
Reporter: Guillaume Nodet
Assignee: Jason van Zyl
Priority: Critical
Fix For: 3.2
Attachments: MNG-1911.zip
I have the following in my main pom
{code:xml}
build
pluginManagement
plugins
plugin
groupIdorg.apache.servicemix.plugins/groupId
artifactIdmaven2-jbi-plugin/artifactId
version1.0-SNAPSHOT/version
extensionstrue/extensions
/plugin
/plugins
/pluginManagement
/build
{code}
If i try to add it to the modules, the first time, maven complains that it
can not download the plugin.
If i remove the {{extensions}} tag, all works, but i need it :)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-1911) Building plugins with extensions in a reactor fails
[
https://jira.codehaus.org/browse/MNG-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-1911.
--
Resolution: Won't Fix
Building plugins with extensions in a reactor fails
---
Key: MNG-1911
URL: https://jira.codehaus.org/browse/MNG-1911
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.1
Reporter: Guillaume Nodet
Assignee: Jason van Zyl
Priority: Critical
Fix For: 3.2
Attachments: MNG-1911.zip
I have the following in my main pom
{code:xml}
build
pluginManagement
plugins
plugin
groupIdorg.apache.servicemix.plugins/groupId
artifactIdmaven2-jbi-plugin/artifactId
version1.0-SNAPSHOT/version
extensionstrue/extensions
/plugin
/plugins
/pluginManagement
/build
{code}
If i try to add it to the modules, the first time, maven complains that it
can not download the plugin.
If i remove the {{extensions}} tag, all works, but i need it :)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-384) Allow whitespace in javadoc exclude list
Omair Majid created MJAVADOC-384: Summary: Allow whitespace in javadoc exclude list Key: MJAVADOC-384 URL: https://jira.codehaus.org/browse/MJAVADOC-384 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9.1 Reporter: Omair Majid Priority: Minor Attachments: spaces-for-javadoc-exclude-list One of the projects that I am working on has a fairly large exclude list for javadoc packages. maven-javadoc-plugin requires me to put this in on line in the pom, which makes it very hard to read. I think it would be nicer to allow separating the items in the list with newlines and other whitespace characters. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[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=340372#comment-340372
]
Robert Scholte commented on MNG-5176:
-
The issue refers to [ISO 8601|http://en.wikipedia.org/wiki/ISO_8601#Durations],
but to me it has become a more readable pattern. Since it's not a standard
anymore, there's room for discussion ;)
I've been searching for the time-unit notation, but I couldn't find the reason
why minutes is {{min}}, while seconds, hours and days are {{s}}, {{h}} and
{{d}}.
My vote would go for same size of [] and right alignment. Also think of the
notation for
{noformat}
[9.953 s] or [09.953 s]
{noformat}
I'm also interested in others opinion, so maybe it's worth to start a
poll/discussion.
Also keep in mind there's this special property:
{{maven.build.timestamp.format}} (
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Available_Variables
)
Maybe this should be extended per timeunit, so users can decide the format for
themselves.
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
Fix For: 3.2
Attachments: MNG-5176.patch, 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
[jira] (MNG-5572) Warn for building plugins with extensions in a reactor
Robert Scholte created MNG-5572:
---
Summary: Warn for building plugins with extensions in a reactor
Key: MNG-5572
URL: https://jira.codehaus.org/browse/MNG-5572
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle, Reactor and workspace
Affects Versions: 3.1.1, 3.0
Reporter: Robert Scholte
MNG-1911 Has been closed as {{won't fix}}. However, if the project was build
with {{mvn install}} you can still get it from the local repository, which is
probably an unexpected and unwanted situation.
It would be better if Maven warns for these constructions within a reactor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[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=340374#comment-340374
]
Michael Osipov commented on MNG-5176:
-
Actually, it is and the primer of this issue was to improve the duration as
well as the readability of the build timestamp at the end of the build. The
Wikipedia article contains only a condensed view of the standard. I have full
access to the PDF file and it states that durations can be expressed like time
but with the according SI unit for time. I can add the reference if you would
like to see it. See [this BIPM
page|http://www.bipm.org/en/si/si_brochure/chapter4/table6.html] for SI units.
Padding with zeros is only necessary when you have multiple components. In the
case of seconds, you have only one.
So you would go for:
{noformat}
[1 d 01:10 h]
[01:02 h]
[ 01:49 min]
[ 22.345 s]
[0.912 s]
{noformat}
?
To space and take in account and build times above 24 h are rare, one could
align by the next big string:
{noformat}
[1 d 01:10 h]
[ 01:02 h]
[01:49 min]
[ 22.345 s]
[ 0.912 s]
{noformat}
I am aware of this property, it has one drawback: You cannot you set the
timezone for that. The latter issue exists with the buildnumber plugin too.
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
Fix For: 3.2
Attachments: MNG-5176.patch, 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 ..
[jira] (MNG-2381) improved control over the repositories in the POM
[ https://jira.codehaus.org/browse/MNG-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-2381: --- Fix Version/s: (was: 3.2) Removed specified fixed version. improved control over the repositories in the POM - Key: MNG-2381 URL: https://jira.codehaus.org/browse/MNG-2381 Project: Maven 2 3 Issue Type: Improvement Components: Artifacts and Repositories, Design, Patterns Best Practices Reporter: Brett Porter some discussion: http://mail-archives.apache.org/mod_mbox/maven-users/200510.mbox/%3c9e3862d80509301841w70bb5883hf352ac3c3bb7e...@mail.gmail.com%3e some questions raised by Chris Berry in relation to this: Let's take, for example, repos defined in settings.xml, in a parent POM, a grandparent POM, and in the local POM . So for this case, what is The precedence level (if any) ?? The search order of hierarchies?? Are they additive?? Can they be masked?? How can one disable SNAPSHOTs completely ?? There are times, mostly when cutting a Release, when you want to be very sure that you are not using any SNAPSHOTs. How does one accomplish this?? So can one then mask all repos except those seen in settings.xml?? These need to be defined and documented as at present, however I believe this yields the need for more control, particularly with relation to the latter requests. Snapshot repositories should not be used in a release build, which it would be good to define as building something that is not a snapshot rather than tying it to the performRelease flag and the release plugin (or imply the perform release plugin under these conditions regardless of the plugin being used). It would be good to better mirror the repositories, and perhaps use the same pattern to control this from the user end (so settings.xml might always use a mirror for a given repository, block another one, and do these things under a profile in some circumstances). I also have the overall goal of reducing traffic, so perhaps we need to group dependencies under a particular repository too. I think this is filed separately. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3124) Inherit mailing lists from parent POM
[ https://jira.codehaus.org/browse/MNG-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-3124: --- Fix Version/s: (was: 3.2) Removed specified fixed version. Inherit mailing lists from parent POM - Key: MNG-3124 URL: https://jira.codehaus.org/browse/MNG-3124 Project: Maven 2 3 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.0.7 Reporter: Vincent Siveton Mailing lists report should have a property to get them from parent POM and concatenate in child: actually, if child pom defines a mailing list, all parent mailing lists are ignored. append inheritance should be the default option -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2807) ciManagement from parent is not merging with children
[
https://jira.codehaus.org/browse/MNG-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Benedict updated MNG-2807:
---
Fix Version/s: (was: 3.2)
Removed specified fixed version.
ciManagement from parent is not merging with children
-
Key: MNG-2807
URL: https://jira.codehaus.org/browse/MNG-2807
Project: Maven 2 3
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.4
Environment: linux jdk1.5.0_10 amd64
Reporter: Kelly Davis
If I define the following in my parent pom:
{code:xml}
ciManagement
systemcontinuum/system
urlhttp://blah/url
/ciManagement
{code}
and then in the child pom I have the following:
{code:xml}
ciManagement
notifiers
notifier
typemail/type
configuration
addressblah/address
/configuration
/notifier
/notifiers
/ciManagement
{code}
The ciManagement for the effective pom lacks the system and url properties
from the parent pom. Seems like it should be merging them but isn't. This
would helpful for reducing code duplication.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-426) [toolchain] create maxmem setting for all plugins to refer to
[ https://jira.codehaus.org/browse/MNG-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-426: -- Fix Version/s: (was: 3.2) Removed specified fixed version. [toolchain] create maxmem setting for all plugins to refer to --- Key: MNG-426 URL: https://jira.codehaus.org/browse/MNG-426 Project: Maven 2 3 Issue Type: New Feature Components: Settings Reporter: Jeff Jensen Create a centralized setting for the max memory setting that all plugins launching a new JVM to respect/use. Then, update the plugins to use it. With the time spent repeatedly running, researching, and configuring some plugins to not have Out of Memory errors, it now seems silly not to add this kind of feature in the revolutionary vs evolutionary Maven 2! :-) I would prefer a setting at the core Maven level, e.g. maven.plugins.maxheap=1024m, that the plugins magically used, vs having to repeatedly specify the same one to each plugin that needs it. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1911) Building plugins with extensions in a reactor fails
[
https://jira.codehaus.org/browse/MNG-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Benedict updated MNG-1911:
---
Fix Version/s: (was: 3.2)
Removed specified fixed version.
Building plugins with extensions in a reactor fails
---
Key: MNG-1911
URL: https://jira.codehaus.org/browse/MNG-1911
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.1
Reporter: Guillaume Nodet
Assignee: Jason van Zyl
Priority: Critical
Attachments: MNG-1911.zip
I have the following in my main pom
{code:xml}
build
pluginManagement
plugins
plugin
groupIdorg.apache.servicemix.plugins/groupId
artifactIdmaven2-jbi-plugin/artifactId
version1.0-SNAPSHOT/version
extensionstrue/extensions
/plugin
/plugins
/pluginManagement
/build
{code}
If i try to add it to the modules, the first time, maven complains that it
can not download the plugin.
If i remove the {{extensions}} tag, all works, but i need it :)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3474) Add parameter --internet to test Internet access with and without using proxy defined in settings.xml
[ https://jira.codehaus.org/browse/MNG-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-3474: --- Fix Version/s: (was: 3.2) Removed specified fixed version. Add parameter --internet to test Internet access with and without using proxy defined in settings.xml - Key: MNG-3474 URL: https://jira.codehaus.org/browse/MNG-3474 Project: Maven 2 3 Issue Type: New Feature Components: Command Line Affects Versions: 2.0.8 Reporter: Wayne Fay Based on the number of problems we see reported on the User list relating to web proxies, I think this is an area we should attempt to address. I think we might seriously want to throw a little code in core-uber that is delivered with the installation that can attempt to access the Internet without any proxy, and then some more code that uses the settings.xml proxy info, to be used for debugging these kinds of situations. Then we can tell people, what does mvn --internet say? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5570) Changes to AbstractMavenLifecycleParticipant breaks Tycho
[ https://jira.codehaus.org/browse/MNG-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-5570: --- Fix Version/s: (was: 3.2) Removed specified fixed version. Changes to AbstractMavenLifecycleParticipant breaks Tycho - Key: MNG-5570 URL: https://jira.codehaus.org/browse/MNG-5570 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.2 Reporter: Jason van Zyl Assignee: Igor Fedorenko The participant is now called too late for Tycho to affect dependency ordering. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1911) Building plugins with extensions in a reactor fails
[
https://jira.codehaus.org/browse/MNG-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340382#comment-340382
]
Vincent Massol commented on MNG-1911:
-
Very disappointed that issues reported by users are just discarded without any
plan to fix them :( This is not the first one I see like this. Closing invalid
issues is ok but closing valid issues with a won't fix is not a good signal
sent to users... Especially when no workaround is provided...
Building plugins with extensions in a reactor fails
---
Key: MNG-1911
URL: https://jira.codehaus.org/browse/MNG-1911
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.1
Reporter: Guillaume Nodet
Assignee: Jason van Zyl
Priority: Critical
Attachments: MNG-1911.zip
I have the following in my main pom
{code:xml}
build
pluginManagement
plugins
plugin
groupIdorg.apache.servicemix.plugins/groupId
artifactIdmaven2-jbi-plugin/artifactId
version1.0-SNAPSHOT/version
extensionstrue/extensions
/plugin
/plugins
/pluginManagement
/build
{code}
If i try to add it to the modules, the first time, maven complains that it
can not download the plugin.
If i remove the {{extensions}} tag, all works, but i need it :)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-169) Support multi-threaded mode of PMD 5
[ https://jira.codehaus.org/browse/MPMD-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340385#comment-340385 ] Anthony Whitford commented on MPMD-169: --- I think I desperately need this as I just realized that the PMD report is the slowest component of a seriously long build. Support multi-threaded mode of PMD 5 Key: MPMD-169 URL: https://jira.codehaus.org/browse/MPMD-169 Project: Maven PMD Plugin Issue Type: Improvement Components: PMD Affects Versions: 3.0 Reporter: Andreas Dangel Assignee: Olivier Lamy Priority: Minor Fix For: 3.1 PMD 5 supports executing in multi-threaded mode, which should be a performance improvement in case you have multiple cores. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
