[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-tabpanel&focusedCommentId=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)
[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-tabpanel&focusedCommentId=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}
>
>
>
>
> org.apache.servicemix.plugins
> maven2-jbi-plugin
> 1.0-SNAPSHOT
> true
>
>
>
>
> {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 {{}} tag, all works, but i need it :)
--
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-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-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}
>
>
>
>
> org.apache.servicemix.plugins
> maven2-jbi-plugin
> 1.0-SNAPSHOT
> true
>
>
>
>
> {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 {{}} tag, all works, but i need it :)
--
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}
>
> continuum
> http://blah
>
> {code}
> and then in the child pom I have the following:
> {code:xml}
>
>
>
> mail
>
> blah
>
>
>
>
> {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-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-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-tabpanel&focusedCommentId=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
[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-tabpanel&focusedCommentId=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 .
[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-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}
>
>
>
>
> org.apache.servicemix.plugins
> maven2-jbi-plugin
> 1.0-SNAPSHOT
> true
>
>
>
>
> {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 {{}} 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:comment-tabpanel&focusedCommentId=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}
>
>
>
>
> org.apache.servicemix.plugins
> maven2-jbi-plugin
> 1.0-SNAPSHOT
> true
>
>
>
>
> {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 {{}} tag, all works, but i need it :)
--
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 ] 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-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-tabpanel&focusedCommentId=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] (SUREFIRE-430) default excludes of Abstract*Test not working
[
https://jira.codehaus.org/browse/SUREFIRE-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] (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-tabpanel&focusedCommentId=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}
>
> ${user.home}/Sites/lombok.maven
>
> ${user.home}/site-content-scm/lombok.maven
>
> ...
>
>
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.2
>
> true
> file://${siteMainDirectory}
>
>
> ...
>
>
> ...
>
>
> org.apache.maven.plugins
> maven-site-plugin
>
>
> stage-for-scm-publish
> post-site
>
> stage
>
>
>
>
>
> org.apache.maven.plugins
> maven-scm-publish-plugin
> 1.0-beta-1
>
> ${scmPubCheckoutDirectory}
> \${siteMainDirectory}
> true
> gh-pages
>
> scm:git:g...@github.com:awhitford/lombok.maven.git
>
>
>
> scm-publish
> site-deploy
>
> publish-scm
>
>
>
>
>
> {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] (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-tabpanel&focusedCommentId=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]
> -
[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-tabpanel&focusedCommentId=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 wou
[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-tabpanel&focusedCommentId=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 Me
