[jira] (MSITE-711) add report's goal name to output
[
https://jira.codehaus.org/browse/MSITE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSITE-711:
Description:
actually, report generation is displayed like
{noformat}[INFO] Skipped "About" report (index), file "index.html" already
exists for the English version.
[INFO] Generating "Project Summary" report---
maven-project-info-reports-plugin:2.7{noformat}
adding goal name would help users find the report in documentation:
{noformat}[INFO] Skipped "About" report
(maven-project-info-reports-plugin:2.7:index), file "index.html" already exists
for the English version.
[INFO] Generating "Project Summary" report---
maven-project-info-reports-plugin:2.7:summary{noformat}
was:
actually, report generation is displayed like
{noformat}[INFO] Generating "About" report---
maven-project-info-reports-plugin:2.7{noformat}
adding goal name would help users find the report in documentation:
{noformat}[INFO] Generating "About" report---
maven-project-info-reports-plugin:2.7:summary{noformat}
> add report's goal name to output
>
>
> Key: MSITE-711
> URL: https://jira.codehaus.org/browse/MSITE-711
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: Maven 3
>Affects Versions: 3.3
>Reporter: Herve Boutemy
>
> actually, report generation is displayed like
> {noformat}[INFO] Skipped "About" report (index), file "index.html" already
> exists for the English version.
> [INFO] Generating "Project Summary" report---
> maven-project-info-reports-plugin:2.7{noformat}
> adding goal name would help users find the report in documentation:
> {noformat}[INFO] Skipped "About" report
> (maven-project-info-reports-plugin:2.7:index), file "index.html" already
> exists for the English version.
> [INFO] Generating "Project Summary" report---
> maven-project-info-reports-plugin:2.7:summary{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[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 updated MNG-5625:
Summary: Provide a terse information about the used thread builder (was:
Provide a terse informatoin about the used thread builder)
> 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
>
> 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] (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:comment-tabpanel&focusedCommentId=346024#comment-346024 ] Herve Boutemy edited comment on MNG-5624 at 5/10/14 9:42 AM: - I removed the xsd a few weeks ago, since it is not used in general (descriptor is not hand-written but generated by plugin-tools) and the xsd generated by Modello is known as incomplete (the configuration part is in fact a fake if you try it :) ) here is the commit [19247f363bee07d1afc6f8902f4083fd890fc47a|https://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a] and the site [has already been published with this change|http://maven.apache.org/ref/3-LATEST/maven-plugin-api/plugin.html], ie no more link to an hypothetical xsd Jason restored the xsd generation in [15aef63c4a57a4fc656baa1f4a168e1eed233159|https://github.com/apache/maven/commit/15aef63c4a57a4fc656baa1f4a168e1eed233159], which IMHO is not a good idea: we should revert and consider as the fix [19247f363bee07d1afc6f8902f4083fd890fc47a|https://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a], done before the bug report WDYT? do you really intend to use the xsd? was (Author: hboutemy): I removed the xsd a few weeks ago, since it is not used in general (descriptor is not hand-written but generated by plugin-tools) and the xsd generated by Modello is known as incomplete (the configuration part is in fact a fake if you try it :) ) here is the commit [19247f363bee07d1afc6f8902f4083fd890fc47a|https://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a] and the site [has already been published with this change|http://maven.apache.org/ref/3-LATEST/maven-plugin-api/plugin.html], ie no more link to an hypothetical xsd Jason restored the xsd generation in [15aef63c4a57a4fc656baa1f4a168e1eed233159|https://github.com/apache/maven/commit/15aef63c4a57a4fc656baa1f4a168e1eed233159], which IMHO is not a good idea: we should revert and consider as the fix [19247f363bee07d1afc6f8902f4083fd890fc47a|https://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a], done before the bug report WDYT? > 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: Jason van Zyl >Priority: Minor > > 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] (MNG-5630) improve display of forked executions
[
https://jira.codehaus.org/browse/MNG-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-5630:
---
Description:
actually, we have
{noformat}[INFO]
[INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
forked-lifecycle >>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
forked-lifecycle <<<{noformat}
it doesn't tell what is the forked goal or phase, which would be useful, but
tell twoce which is the executed goal
proposed new format in case of phase:
{noformat}[INFO]
[INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report) > [optional
lifecycle]generate-sources @ forked-lifecycle >>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report) < [optional
lifecycle]generate-sources @ forked-lifecycle <<<{noformat}
and in case of goal:
proposed new format in case of phase:
{noformat}[INFO]
[INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report) > :goal @
forked-lifecycle >>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report) < :goal @
forked-lifecycle <<<{noformat}
was:
actually, we have
{noformat}[INFO]
[INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
forked-lifecycle >>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
forked-lifecycle <<<{noformat}
it doesn't tell what is the forked goal or phase, which would be useful, but
tell twoce which is the executed goal
proposed new format in case of phase:
{noformat}[INFO]
[INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report) > [optional
lifecycle]generate-sources @ forked-lifecycle >>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report) > [optional
lifecycle]generate-sources @ forked-lifecycle <<<{noformat}
and in case of goal:
proposed new format in case of phase:
{noformat}[INFO]
[INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report) > :goal @
forked-lifecycle >>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report) > :goal @
forked-lifecycle <<<{noformat}
> improve display of forked executions
>
>
> Key: MNG-5630
> URL: https://jira.codehaus.org/browse/MNG-5630
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>
> actually, we have
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
> forked-lifecycle >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
> forked-lifecycle <<<{noformat}
> it doesn't tell what is the forked goal or phase, which would be useful, but
> tell twoce which is the executed goal
> proposed new format in case of phase:
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report) > [optional
> lifecycle]generate-sources @ forked-lifecycle >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report) < [optional
> lifecycle]generate-sources @ forked-lifecycle <<<{noformat}
> and in case of goal:
> proposed new format in case of phase:
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report) > :goal @
> forked-lifecycle >>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report) < :goal @
> forked-lifecycle <<<{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-333) display what phase or goal is forked by a report
[
https://jira.codehaus.org/browse/MSHARED-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHARED-333:
--
Summary: display what phase or goal is forked by a report (was: display
what phase is forked by a report)
> display what phase or goal is forked by a report
>
>
> Key: MSHARED-333
> URL: https://jira.codehaus.org/browse/MSHARED-333
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-exec
>Reporter: Herve Boutemy
>
> actually, forked executions don't show what is the precise phase or goal that
> is forked
> {noformat}[INFO]
> [INFO] >>> maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
> forked-lifecycle >>>
> ...
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9.1:aggregate (report:aggregate) @
> forked-lifecycle <<<{noformat}
> it would be useful to know what is the phase or goal that cause the forked
> execution
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-878) Exclude generated dependency-reduced-pom.xml and flattened-pom.xml
Mirko Friedenhagen created MRELEASE-878:
---
Summary: Exclude generated dependency-reduced-pom.xml and
flattened-pom.xml
Key: MRELEASE-878
URL: https://jira.codehaus.org/browse/MRELEASE-878
Project: Maven Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.5
Reporter: Mirko Friedenhagen
As stated in MOJO-2030 and MSHADE-145, both plugins create additional poms in
{{basedir}} to avoid confusion while generating the site.
This will lead to an error during {{release:prepare}}, so just exclude
{{dependency-reduced-pom.xml}} and {{flattened-pom.xml}} by default as well.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-152) Maven websites don't follow ASF rules on License
[ https://jira.codehaus.org/browse/MNGSITE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346271#comment-346271 ] Karl-Heinz Marbaise commented on MNGSITE-152: - Added download.cgi and xdoc/download.xml.vm for org.apache.maven.shared [1594676|http://svn.apache.org/r1594676]. Added missing links in site.xml for org.apache.maven.shared [1594680|http://svn.apache.org/r1594680]. > Maven websites don't follow ASF rules on License > > > Key: MNGSITE-152 > URL: https://jira.codehaus.org/browse/MNGSITE-152 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: SebbASF >Assignee: Karl-Heinz Marbaise > Attachments: screenshot-license.png > > > ASF projects are supposed to provide a prominent link [0] to the ASF licenses > page [1] > AIUI, websites are not supposed to provide their own license pages. > [0] http://apache.org/foundation/marks/pmcs.html#navigation > [1] http://www.apache.org/licenses/ -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNGSITE-152) Maven websites don't follow ASF rules on License
[ https://jira.codehaus.org/browse/MNGSITE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346269#comment-346269 ] Karl-Heinz Marbaise commented on MNGSITE-152: - Added the download.cgi and xdoc/download.xml.vm into all plugins with the state of last change in maven-scm-plublish-plugin. Done in [1594666|http://svn.apache.org/r1594666]. > Maven websites don't follow ASF rules on License > > > Key: MNGSITE-152 > URL: https://jira.codehaus.org/browse/MNGSITE-152 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: SebbASF >Assignee: Karl-Heinz Marbaise > Attachments: screenshot-license.png > > > ASF projects are supposed to provide a prominent link [0] to the ASF licenses > page [1] > AIUI, websites are not supposed to provide their own license pages. > [0] http://apache.org/foundation/marks/pmcs.html#navigation > [1] http://www.apache.org/licenses/ -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNGSITE-152) Maven websites don't follow ASF rules on License
[ https://jira.codehaus.org/browse/MNGSITE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346269#comment-346269 ] Karl-Heinz Marbaise edited comment on MNGSITE-152 at 5/14/14 1:46 PM: -- Added the download.cgi and xdoc/download.xml.vm into all plugins with the state of last change in maven-scm-publish-plugin. Done in [1594666|http://svn.apache.org/r1594666]. was (Author: khmarbaise): Added the download.cgi and xdoc/download.xml.vm into all plugins with the state of last change in maven-scm-plublish-plugin. Done in [1594666|http://svn.apache.org/r1594666]. > Maven websites don't follow ASF rules on License > > > Key: MNGSITE-152 > URL: https://jira.codehaus.org/browse/MNGSITE-152 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: SebbASF >Assignee: Karl-Heinz Marbaise > Attachments: screenshot-license.png > > > ASF projects are supposed to provide a prominent link [0] to the ASF licenses > page [1] > AIUI, websites are not supposed to provide their own license pages. > [0] http://apache.org/foundation/marks/pmcs.html#navigation > [1] http://www.apache.org/licenses/ -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-456) Add an option to allow comparing reference project to generated one regardless of the EOL encoding
[ https://jira.codehaus.org/browse/ARCHETYPE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346248#comment-346248 ] Baptiste Mathus commented on ARCHETYPE-456: --- Any comment in answer to my last one, Stephen? > Add an option to allow comparing reference project to generated one > regardless of the EOL encoding > -- > > Key: ARCHETYPE-456 > URL: https://jira.codehaus.org/browse/ARCHETYPE-456 > Project: Maven Archetype > Issue Type: Improvement > Components: Plugin >Affects Versions: 2.2 >Reporter: Baptiste Mathus > Attachments: ARCHETYPE-ignoreEOLEncoding-v2.patch, > build-archetype-ignore-eol-encoding.zip > > > Mojo : archetype:integration-test > Currently, depending on where you created the reference project to be > compared to the generated one, the test can fail. > This feature would add an option to ask for comparison saying basically you > don't care it's a CR, a LF, or a CRLF EOL, and are only interested in the > rest of the content. > I'm also including a patch (which also includes the corresponding IT for the > invoker-plugin). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346252#comment-346252
]
Paul Benedict commented on MNG-2205:
If this conversation is really about controlling the transitive nature of a
dependency, I think we should introduce a boolean tag. That won't
need a version update since it's a new tag (no one has used it before). Then
instead of inventing new scopes, we can just let programmers determine it for
themselves based on their own needs.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346246#comment-346246
]
Tibor Digana commented on MNG-2205:
---
I agree with Jason that the model version should not change.
I agree with other commiters saying that XML schema should not be changed.
Therefore a new scope should be introduced and we can call it something like
"nonrunnable".
Thus the behavior of scope "provided" should not change in spec.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-431) new options to control output from dependency:analyze(-only)
[ https://jira.codehaus.org/browse/MDEP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346243#comment-346243 ] Robert Platt commented on MDEP-431: --- It has been over six months since this was submitted with a patch with no response or acknowledgement. We've been using the patched version very effectively to detect unmanaged dependencies creeping into the system, and it is a non-breaking change. Seems a no-brainer. > new options to control output from dependency:analyze(-only) > > > Key: MDEP-431 > URL: https://jira.codehaus.org/browse/MDEP-431 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: analyze >Affects Versions: 2.8 >Reporter: Robert Platt > Attachments: mdep.patch > > > Including dependency:analyze-only with failOnWarning into a build can be very > effective at catching dependency issues. However, it is pretty much > all-or-nothing at the moment. In the case of complex or legacy projects it > can be difficult to incorporate the plugin into the build. > This is a patch (see attached mdep.path) to version 2.8 to provide more > control over dependency analysis output, introducing three new configuration > options. In all cases, the default options provide the current plugin > behavior: > 1. warnUnusedDeclared (default true). Unused declared dependencies generate > a warning if this is true, otherwise it is just info. > 2. ignoreManagedUndeclared (default false). If true, then used undeclared > dependencies which are dependency managed are not reported in the warnings. > The reasoning behind this option is that used undeclared dependencies are > less likely to break a build in subtle ways if they are dependency managed, > since the version will not change without developer intervention. Turning > this option on focuses the analysis on compiling against unmanaged transitive > dependencies. > 3. preferManagedVersionOutput (default false). If true, when outputting XML, > versions are left unspecified for managed dependencies. This can be handy > when you aren't using ignoreManagedUndeclared but want to use managed > versions when fixing undeclared dependencies. > Finally, the wording for the output of unused declared dependencies has been > changed to 'Potentially unused declared dependencies found' because, as > documented, their are limitations to this detection process with the default > analyzer. This wording makes it clearer to developers without that working > knowledge. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-431) new options to control output from dependency:analyze(-only)
[ https://jira.codehaus.org/browse/MDEP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Platt updated MDEP-431: -- Component/s: analyze > new options to control output from dependency:analyze(-only) > > > Key: MDEP-431 > URL: https://jira.codehaus.org/browse/MDEP-431 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: analyze >Affects Versions: 2.8 >Reporter: Robert Platt > Attachments: mdep.patch > > > Including dependency:analyze-only with failOnWarning into a build can be very > effective at catching dependency issues. However, it is pretty much > all-or-nothing at the moment. In the case of complex or legacy projects it > can be difficult to incorporate the plugin into the build. > This is a patch (see attached mdep.path) to version 2.8 to provide more > control over dependency analysis output, introducing three new configuration > options. In all cases, the default options provide the current plugin > behavior: > 1. warnUnusedDeclared (default true). Unused declared dependencies generate > a warning if this is true, otherwise it is just info. > 2. ignoreManagedUndeclared (default false). If true, then used undeclared > dependencies which are dependency managed are not reported in the warnings. > The reasoning behind this option is that used undeclared dependencies are > less likely to break a build in subtle ways if they are dependency managed, > since the version will not change without developer intervention. Turning > this option on focuses the analysis on compiling against unmanaged transitive > dependencies. > 3. preferManagedVersionOutput (default false). If true, when outputting XML, > versions are left unspecified for managed dependencies. This can be handy > when you aren't using ignoreManagedUndeclared but want to use managed > versions when fixing undeclared dependencies. > Finally, the wording for the output of unused declared dependencies has been > changed to 'Potentially unused declared dependencies found' because, as > documented, their are limitations to this detection process with the default > analyzer. This wording makes it clearer to developers without that working > knowledge. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MECLIPSE-659) eclipse-plugin does not create .classpath and .project files for projects with packaging pom
[ https://jira.codehaus.org/browse/MECLIPSE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345892#comment-345892 ] Tom Helpstone commented on MECLIPSE-659: My workaround is to import the project with "Import Maven Projects" with marking _all_ pom.xml's. The result is a eclipse setup with a build path, which includes the library dependencies coming from maven. Resolving this bug would be the nicer solution. > eclipse-plugin does not create .classpath and .project files for projects > with packaging pom > > > Key: MECLIPSE-659 > URL: https://jira.codehaus.org/browse/MECLIPSE-659 > Project: Maven Eclipse Plugin > Issue Type: Bug > Components: Core : Multi-projects >Affects Versions: 2.8 > Environment: any >Reporter: Daniele Dellafiore > > mvn eclipse:eclipse does not generate eclipse .project and .classpath files > from any pom.xml file that has packaging set to POM. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5629) ClosedChannelException from DefaultUpdateCheckManager.read
[
https://jira.codehaus.org/browse/MNG-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346218#comment-346218
]
Anthony Whitford commented on MNG-5629:
---
It looks like it is the {{site}} phase that causes this error: {{mvn -X site}}
You can use this project to replicate the issue:
[https://github.com/awhitford/lombok.maven]
Also note that I was able to reproduce the issue on a Mac too, so this isn't
limited to Windows.
And I was not able to replicate the issue with Maven 3.0.5, so this seems
limited to 3.2.1.
> ClosedChannelException from DefaultUpdateCheckManager.read
> --
>
> Key: MNG-5629
> URL: https://jira.codehaus.org/browse/MNG-5629
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.2.1
> Environment: Windows 7, Java 7 updated 25
>Reporter: Anthony Whitford
>
> I ran a build in debug mode ({{mvn -X}}) and noticed the following bug
> (repeatedly):
> {noformat}
> [DEBUG] Error releasing shared lock for resolution tracking file:
> C:\Users\awhitford\.m2\repository\org\apache\maven\plugins\maven-war-plugin\resolver-status.properties
> java.nio.channels.ClosedChannelException
> at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:58)
> at
> org.apache.maven.repository.legacy.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:396)
> at
> org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:323)
> at
> org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:159)
> at
> org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired(DefaultUpdateCheckManager.java:148)
> at
> org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:127)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:435)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:425)
> at
> org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupArtifactVersions(DefaultVersionsHelper.java:229)
> at
> org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginUpdates(DefaultVersionsHelper.java:727)
> at
> org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginsUpdates(DefaultVersionsHelper.java:706)
> at
> org.codehaus.mojo.versions.PluginUpdatesReport.doGenerateReport(PluginUpdatesReport.java:103)
> at
> org.codehaus.mojo.versions.AbstractVersionsReport.executeReport(AbstractVersionsReport.java:253)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:
