[jira] (MNG-5625) Provide a terse information about the used thread builder
[
https://jira.codehaus.org/browse/MNG-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5625.
---
Resolution: Fixed
Fix Version/s: 3.2.2
Assignee: Michael Osipov
Merged https://github.com/apache/maven/pull/14.
> Provide a terse information about the used thread builder
> -
>
> Key: MNG-5625
> URL: https://jira.codehaus.org/browse/MNG-5625
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.2.2
>
>
> Sample output:
> {noformat}
> [INFO] Using the builder
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder
> with a thread
> count of 1
> {noformat}
> This line is extremely long is not really readible. It could be cut down to
> (options)
> 1. If a single thread is used, omit completely
> 2. Cut down to simple class name:
> {{[INFO] Using the builder SingleThreadedBuilder with a thread count of 1}}
> 3. Cut down to a compressed class name like logback does:
> {{[INFO] Using the builder o.a.m.l.i.b.s.SingleThreadedBuilder with a thread
> count of 1}}
> Line in question:
> [link|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleStarter.java#L115]
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-336) Create a method in the DependencyGraphBuilder that accepts the reactor projects to collect unbuilt dependencies
[ https://jira.codehaus.org/browse/MSHARED-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSHARED-336: -- Summary: Create a method in the DependencyGraphBuilder that accepts the reactor projects to collect unbuilt dependencies (was: Create a method in the DependencyGraphBuilder that accepts the reactor projects and resolves dependencies from within the reactor) > Create a method in the DependencyGraphBuilder that accepts the reactor > projects to collect unbuilt dependencies > --- > > Key: MSHARED-336 > URL: https://jira.codehaus.org/browse/MSHARED-336 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree >Reporter: Jason van Zyl >Assignee: Jason van Zyl > > https://github.com/apache/maven-shared/pull/5 > https://github.com/apache/maven-shared/pull/6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-336) Create a method in the DependencyGraphBuilder that accepts the reactor projects to collect unbuilt dependencies
[ https://jira.codehaus.org/browse/MSHARED-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSHARED-336. - Resolution: Fixed Fix Version/s: maven-dependency-tree-2.2 Assignee: Herve Boutemy (was: Jason van Zyl) work finished in [r1597312|http://svn.apache.org/r1597312] > Create a method in the DependencyGraphBuilder that accepts the reactor > projects to collect unbuilt dependencies > --- > > Key: MSHARED-336 > URL: https://jira.codehaus.org/browse/MSHARED-336 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree >Reporter: Jason van Zyl >Assignee: Herve Boutemy > Fix For: maven-dependency-tree-2.2 > > > https://github.com/apache/maven-shared/pull/5 > https://github.com/apache/maven-shared/pull/6 > Maven Core resolves dependencies from reactor to build the graph (using > http://maven.apache.org/ref/current/maven-core/xref/org/apache/maven/ReactorReader.html): > this is sufficient when the graph is calculated after each reactor project > has been compiled. > But in case of Lifecycle participant (ie before any build action has taken > place) or if we don't want to compile, this isn't sufficient > Adding a method with extra parameters for such a limit-situation permits to > hack for unresolved dependencies and replace them with projects collected > from reactor -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-336) Create a method in the DependencyGraphBuilder that accepts the reactor projects to collect unbuilt dependencies
[ https://jira.codehaus.org/browse/MSHARED-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSHARED-336: -- Description: https://github.com/apache/maven-shared/pull/5 https://github.com/apache/maven-shared/pull/6 Maven Core resolves dependencies from reactor to build the graph (using http://maven.apache.org/ref/current/maven-core/xref/org/apache/maven/ReactorReader.html): this is sufficient when the graph is calculated after each reactor project has been compiled. But in case of Lifecycle participant (ie before any build action has taken place) or if we don't want to compile, this isn't sufficient Adding a method with extra parameters for such a limit-situation permits to hack for unresolved dependencies and replace them with projects collected from reactor was: https://github.com/apache/maven-shared/pull/5 https://github.com/apache/maven-shared/pull/6 > Create a method in the DependencyGraphBuilder that accepts the reactor > projects to collect unbuilt dependencies > --- > > Key: MSHARED-336 > URL: https://jira.codehaus.org/browse/MSHARED-336 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: maven-dependency-tree-2.2 > > > https://github.com/apache/maven-shared/pull/5 > https://github.com/apache/maven-shared/pull/6 > Maven Core resolves dependencies from reactor to build the graph (using > http://maven.apache.org/ref/current/maven-core/xref/org/apache/maven/ReactorReader.html): > this is sufficient when the graph is calculated after each reactor project > has been compiled. > But in case of Lifecycle participant (ie before any build action has taken > place) or if we don't want to compile, this isn't sufficient > Adding a method with extra parameters for such a limit-situation permits to > hack for unresolved dependencies and replace them with projects collected > from reactor -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-84) dependency:tree fails to show all dependencies
[
https://jira.codehaus.org/browse/MSHARED-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHARED-84:
-
Description:
After strugling with xerces 1.4.0 sneaking onto my classpath whenever I ran mvn
eclipse:eclipse I was asked to submit the minimal pom which recreates the
problem.
The dependency in my original project which caused the problem is an artifact
developed by us, which has a dependency to Castor 1.1.1. Castor has a direct
dependency to xerces 1.4.0 which is visible when running dependency:tree on the
ijcommons-distribution project (which is our local artifact). The problem
arises when we run dependency:tree on the initial project, which has a
dependency to ijcommons-distribution - then the dependency to castor and xerces
is never shown, even if xerces is included on the classpath.
Attached is the 3 poms I used to produce the problem.
"mvn dependency:tree | grep xerces" on the project using
"original-problem-pom.xml", gives the following output:
{noformat}[INFO] | | +- xerces:xmlParserAPIs:jar:2.6.2:compile
[INFO] | | \- xerces:xercesImpl:jar:2.6.2:compile
[INFO] | \- xerces:dom3-xml-apis:jar:1.0:compile{noformat}
"mvn dependency:tree" on the project using "ijcommons-distribution-pom.xml",
gives the following output:
{noformat}[INFO] [dependency:tree]
[INFO] no.integrasco.commons:ijcommons-distribution:jar:0.5-SNAPSHOT
[INFO] +- junit:junit:jar:4.4:test
[INFO] +- ch.ethz.ganymed:ganymed-ssh2:jar:build210:compile
[INFO] +- commons-httpclient:commons-httpclient:jar:3.1:compile
[INFO] | \- commons-codec:commons-codec:jar:1.2:compile
[INFO] +- org.codehaus.castor:castor:jar:1.1.1:compile
[INFO] | +- cglib:cglib-full:jar:2.0.2:compile
[INFO] | +- javax.transaction:jta:jar:1.0.1B:compile
[INFO] | \- xerces:xerces:jar:1.4.0:compile
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \- log4j:log4j:jar:1.2.14:test (scope not updated to compile){noformat}
By adding every single dependency of original-problem-pom.xml to
minimal-reproduce-pom.xml I confirmed that ijcommons-distribution.xml was the
only dependency adding xerces 1.4.0 to the classpath.
To my understanding xerces-1.4.0 should then also appear on the classpath of
the project using original-problem-pom.xml?
The POM of Castor version 1.1.1 is also attached.
was:
After strugling with xerces 1.4.0 sneaking onto my classpath whenever I ran mvn
eclipse:eclipse I was asked to submit the minimal pom which recreates the
problem.
The dependency in my original project which caused the problem is an artifact
developed by us, which has a dependency to Castor 1.1.1. Castor has a direct
dependency to xerces 1.4.0 which is visible when running dependency:tree on the
ijcommons-distribution project (which is our local artifact). The problem
arises when we run dependency:tree on the initial project, which has a
dependency to ijcommons-distribution - then the dependency to castor and xerces
is never shown, even if xerces is included on the classpath.
Attached is the 3 poms I used to produce the problem.
"mvn dependency:tree | grep xerces" on the project using
"original-problem-pom.xml", gives the following output:
[INFO] | | +- xerces:xmlParserAPIs:jar:2.6.2:compile
[INFO] | | \- xerces:xercesImpl:jar:2.6.2:compile
[INFO] | \- xerces:dom3-xml-apis:jar:1.0:compile
"mvn dependency:tree" on the project using "ijcommons-distribution-pom.xml",
gives the following output:
[INFO] [dependency:tree]
[INFO] no.integrasco.commons:ijcommons-distribution:jar:0.5-SNAPSHOT
[INFO] +- junit:junit:jar:4.4:test
[INFO] +- ch.ethz.ganymed:ganymed-ssh2:jar:build210:compile
[INFO] +- commons-httpclient:commons-httpclient:jar:3.1:compile
[INFO] | \- commons-codec:commons-codec:jar:1.2:compile
[INFO] +- org.codehaus.castor:castor:jar:1.1.1:compile
[INFO] | +- cglib:cglib-full:jar:2.0.2:compile
[INFO] | +- javax.transaction:jta:jar:1.0.1B:compile
[INFO] | \- xerces:xerces:jar:1.4.0:compile
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \- log4j:log4j:jar:1.2.14:test (scope not updated to compile)
By adding every single dependency of original-problem-pom.xml to
minimal-reproduce-pom.xml I confirmed that ijcommons-distribution.xml was the
only dependency adding xerces 1.4.0 to the classpath.
To my understanding xerces-1.4.0 should then also appear on the classpath of
the project using original-problem-pom.xml?
The POM of Castor version 1.1.1 is also attached.
> dependency:tree fails to show all dependencies
> --
>
> Key: MSHARED-84
> URL: https://jira.codehaus.org/browse/MSHARED-84
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-tree
> Environment: Linux (Ubuntu 8.10), i386, java version "1.6.0_10",
> Java(TM) SE Runtime Environment (build
[jira] [Created] (MPOM-53) turn javadoc quiet
Hervé Boutemy created MPOM-53: - Summary: turn javadoc quiet Key: MPOM-53 URL: https://issues.apache.org/jira/browse/MPOM-53 Project: Maven POMs Issue Type: Improvement Components: maven Affects Versions: MAVEN-24 Reporter: Hervé Boutemy Assignee: Hervé Boutemy Fix For: MAVEN-25 javadoc is too verbose, this makes Maven output completely unusable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] (MNG-5624) Maven API Plugin descriptor xsd does not exist at advertised location
[ https://jira.codehaus.org/browse/MNG-5624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNG-5624. -- Resolution: Fixed Fix Version/s: 3.2.2 Assignee: Herve Boutemy (was: Jason van Zyl) no answer reverted in [3729324a|http://git-wip-us.apache.org/repos/asf/maven/commit/3729324a]: there is no reference to any xsd as done in [19247f363bee07d1afc6f8902f4083fd890fc47a|https://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a] > Maven API Plugin descriptor xsd does not exist at advertised location > - > > Key: MNG-5624 > URL: https://jira.codehaus.org/browse/MNG-5624 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Documentation: General >Affects Versions: 3.2.1 >Reporter: Dave Moten >Assignee: Herve Boutemy >Priority: Minor > Fix For: 3.2.2 > > > The link http://maven.apache.org/ref/3.2.1/maven-plugin-api/plugin.html > refers to the schemaLocation of http://maven.apache.org/xsd/plugin-1.0.0.xsd > which does not exist. Can this be uploaded please. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-752) maven-release-plugin:2.5:prepare fails with âError writing POM: (Access is denied)â
Ohad R created SCM-752: -- Summary: maven-release-plugin:2.5:prepare fails with âError writing POM: (Access is denied)â Key: SCM-752 URL: https://jira.codehaus.org/browse/SCM-752 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-tfs Affects Versions: 1.9 Reporter: Ohad R Priority: Blocker the TFS will never work, because TFS requires "edit mode" in order to change files. Currently, TfsScmProvider has no own implementation for requiresEditMode(), and its super (AbstractScmProvider) returns false. so upon release:prepare phase, on phase called 'rewrite-poms-for-release', which is the phase where maven tries to change poms into release, it fails. on ACCESS DENIED see this: http://stackoverflow.com/questions/23809214/maven-release-plugin2-5prepare-fails-with-error-writing-pom-access-is-denie -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-752) maven-release-plugin:2.5:prepare fails with âError writing POM: (Access is denied)â
[ https://jira.codehaus.org/browse/SCM-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ohad R updated SCM-752: --- Description: the TFS-provider will never work, because TFS requires "edit mode" in order to change files. Currently, TfsScmProvider has no own implementation for requiresEditMode(), and its super (AbstractScmProvider) returns false. so upon release:prepare phase, on phase called 'rewrite-poms-for-release', which is the phase where maven tries to change poms into release, it fails. on ACCESS DENIED see this: http://stackoverflow.com/questions/23809214/maven-release-plugin2-5prepare-fails-with-error-writing-pom-access-is-denie was: the TFS will never work, because TFS requires "edit mode" in order to change files. Currently, TfsScmProvider has no own implementation for requiresEditMode(), and its super (AbstractScmProvider) returns false. so upon release:prepare phase, on phase called 'rewrite-poms-for-release', which is the phase where maven tries to change poms into release, it fails. on ACCESS DENIED see this: http://stackoverflow.com/questions/23809214/maven-release-plugin2-5prepare-fails-with-error-writing-pom-access-is-denie > maven-release-plugin:2.5:prepare fails with âError writing POM: (Access is > denied)â > --- > > Key: SCM-752 > URL: https://jira.codehaus.org/browse/SCM-752 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-tfs >Affects Versions: 1.9 >Reporter: Ohad R >Priority: Blocker > > the TFS-provider will never work, because TFS requires "edit mode" in order > to change files. Currently, TfsScmProvider has no own implementation for > requiresEditMode(), and its super (AbstractScmProvider) returns false. so > upon release:prepare phase, on phase called 'rewrite-poms-for-release', which > is the phase where maven tries to change poms into release, it fails. on > ACCESS DENIED > see this: > http://stackoverflow.com/questions/23809214/maven-release-plugin2-5prepare-fails-with-error-writing-pom-access-is-denie -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-666) TfsEditCommand should not report error if the file is also checked out by others
[
https://jira.codehaus.org/browse/SCM-666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347047#comment-347047
]
Ohad R commented on SCM-666:
anyone solved this? any git' pull-request? is there a work-around?
> TfsEditCommand should not report error if the file is also checked out by
> others
>
>
> Key: SCM-666
> URL: https://jira.codehaus.org/browse/SCM-666
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-tfs
>Affects Versions: 1.6
>Reporter: John Wu
>
> While checking out a file for editing, the {{TfsEditCommand}} reports error,
> if the file is already checked out by others, as the following:
> {noformat}
> $/path/to/the/file:
>opened for edit in ;
> {noformat}
> One file is checked out and being editing by multiple people is quite common
> in a team environment, which should not prevent yet another from checking it
> out for editing successfully.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-750) TFS-plugin fails in cases of 'TFS policies' is required by TFS upon checkin
[ https://jira.codehaus.org/browse/SCM-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ohad R updated SCM-750: --- Environment: TFS-2010 > TFS-plugin fails in cases of 'TFS policies' is required by TFS upon checkin > --- > > Key: SCM-750 > URL: https://jira.codehaus.org/browse/SCM-750 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-tfs >Affects Versions: 1.9 > Environment: TFS-2010 >Reporter: Ohad R > > In TFS, there is an option of "checkin policies". In this case, whenever a > developer checks-in his code, another dialog pops-up , and asks to enter a > comment. I really do not know who really uses this feature and actually > enters a real comment (since the comment that is related to the check-in was > entered in a previous dialog), but in my case the organization's SCM forces > this extra-dialog. The problem: when I try to check in a file using a command > line, I HAVE TO add an extra argument to the command (see example below). > Hence, the scm-tfs plugin does not work, since it lacks this 'extra' > argument. As far as i saw the code, I understand that the command is > hard-coded, and unfortunately it is not configurable, > This is an example command-line for check-in (only a single pom.xml): > tf checkin -noprompt "-comment:[maven-release-plugin] prepare release > some-comment-for-checkin" D:\.\pom.xml /override:";Auto-Build: Version > Update"; > in this example, '/override:";Auto-Build: Version Update";' is the > extra-argument. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-752) maven-release-plugin:2.5:prepare fails with 'Error writing POM: (Access is denied)'
[ https://jira.codehaus.org/browse/SCM-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ohad R updated SCM-752: --- Environment: TFS-2010 Summary: maven-release-plugin:2.5:prepare fails with 'Error writing POM: (Access is denied)' (was: maven-release-plugin:2.5:prepare fails with âError writing POM: (Access is denied)â) > maven-release-plugin:2.5:prepare fails with 'Error writing POM: (Access is > denied)' > --- > > Key: SCM-752 > URL: https://jira.codehaus.org/browse/SCM-752 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-tfs >Affects Versions: 1.9 > Environment: TFS-2010 >Reporter: Ohad R >Priority: Blocker > > the TFS-provider will never work, because TFS requires "edit mode" in order > to change files. Currently, TfsScmProvider has no own implementation for > requiresEditMode(), and its super (AbstractScmProvider) returns false. so > upon release:prepare phase, on phase called 'rewrite-poms-for-release', which > is the phase where maven tries to change poms into release, it fails. on > ACCESS DENIED > see this: > http://stackoverflow.com/questions/23809214/maven-release-plugin2-5prepare-fails-with-error-writing-pom-access-is-denie -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-752) maven-release-plugin:2.5:prepare fails with 'Error writing POM: (Access is denied)'
[ https://jira.codehaus.org/browse/SCM-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ohad R updated SCM-752: --- Description: maven-release-plugin cannot work with the TFS-provider, because TFS requires "edit mode" in order to change files. Currently, TfsScmProvider has no own implementation for requiresEditMode(), and its super (AbstractScmProvider) returns false. so upon release:prepare phase, on phase called 'rewrite-poms-for-release', which is the phase where maven tries to change poms into release, it fails. on ACCESS DENIED see this: http://stackoverflow.com/questions/23809214/maven-release-plugin2-5prepare-fails-with-error-writing-pom-access-is-denie was: the TFS-provider will never work, because TFS requires "edit mode" in order to change files. Currently, TfsScmProvider has no own implementation for requiresEditMode(), and its super (AbstractScmProvider) returns false. so upon release:prepare phase, on phase called 'rewrite-poms-for-release', which is the phase where maven tries to change poms into release, it fails. on ACCESS DENIED see this: http://stackoverflow.com/questions/23809214/maven-release-plugin2-5prepare-fails-with-error-writing-pom-access-is-denie > maven-release-plugin:2.5:prepare fails with 'Error writing POM: (Access is > denied)' > --- > > Key: SCM-752 > URL: https://jira.codehaus.org/browse/SCM-752 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-tfs >Affects Versions: 1.9 > Environment: TFS-2010 >Reporter: Ohad R >Priority: Blocker > > maven-release-plugin cannot work with the TFS-provider, because TFS requires > "edit mode" in order to change files. Currently, TfsScmProvider has no own > implementation for requiresEditMode(), and its super (AbstractScmProvider) > returns false. so upon release:prepare phase, on phase called > 'rewrite-poms-for-release', which is the phase where maven tries to change > poms into release, it fails. on ACCESS DENIED > see this: > http://stackoverflow.com/questions/23809214/maven-release-plugin2-5prepare-fails-with-error-writing-pom-access-is-denie -- This message was sent by Atlassian JIRA (v6.1.6#6162)
