[jira] [Commented] (MNG-2766) Refactor DefaultLifecycleExecutor
[
https://issues.apache.org/jira/browse/MNG-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825111#comment-17825111
]
Shannon Carey commented on MNG-2766:
Ok... I guess I don't know enough about Mojos to figure it out. I don't see any
javadoc on the
{{requiresDependencyResolution}} and {{requiresDependencyCollection}}
properties of {{{}@Mojo{}}}.
As I was working on a contribution to the maven-exec-plugin, I noticed it is
still using deprecated methods like {{{}getTestArtifacts(){}}},
{{{}getRuntimeArtifacts(){}}}, etc. within
[https://github.com/mojohaus/exec-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/exec/AbstractExecMojo.java#L133]
but I'm just not sure what that should look like instead. Especially since it
has to collect the artifacts at runtime based on its configuration, as opposed
to the Mojo annotation which is compiled into the plugin itself. I suppose I'll
have to leave it up to the maintainers to figure that out.
> Refactor DefaultLifecycleExecutor
> -
>
> Key: MNG-2766
> URL: https://issues.apache.org/jira/browse/MNG-2766
> Project: Maven
> Issue Type: Task
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-alpha-1
>Reporter: Jason van Zyl
>Assignee: Jason van Zyl
>Priority: Major
> Fix For: 3.0-alpha-3
>
>
> Another large beast that needs to be broken up.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJAVADOC-490) Aggregate goal fails if artifacts not installed
Shannon Carey created MJAVADOC-490:
--
Summary: Aggregate goal fails if artifacts not installed
Key: MJAVADOC-490
URL: https://issues.apache.org/jira/browse/MJAVADOC-490
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 2.10.4
Reporter: Shannon Carey
Using the javadoc aggregate report causes release:perform to fail if the
modules were not already installed into the local repository.
During release:perform's execution of "deploy site-deploy", when
report:aggregate runs it appears to fork executions on all of the reactor
modules ("Forking mymodule 0.0.1"). When it gets to a module which has a
dependency on another module, it cannot find it locally (since that module has
not yet been installed), tries to download it from Nexus, and ultimately fails
with "... Could not resolve dependencies for project ... The following
artifacts could not be resolved ..."
The only way I can think of to fix this is to add "install" to the
"preparationGoals" of release:prepare so that the modules are already installed
before release:perform is run. However, this violates the self-containment of
release:perform's deploy build, and is generally confusing and difficult to
diagnose.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAVADOC-467) Aggregator reports should not require modules to be installed/deployed.
[ https://issues.apache.org/jira/browse/MJAVADOC-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15552750#comment-15552750 ] Shannon Carey commented on MJAVADOC-467: Wouldn't this give inaccurate report information in a multimodule build if, for example, you ran: ``` git checkout v1 mvn compile git checkout v2 mvn clean deploy site-deploy ``` When the second maven command is run, the reactor module will be cleaned, deployed, and then the javadoc:aggregate will be run. However, the child modules have not executed any phases and therefore the aggregate report will gather data based on the "v1" branch previously compiled. Or does this change fix that issue somehow? > Aggregator reports should not require modules to be installed/deployed. > --- > > Key: MJAVADOC-467 > URL: https://issues.apache.org/jira/browse/MJAVADOC-467 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Trivial > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MJAVADOC-467) Aggregator reports should not require modules to be installed/deployed.
[
https://issues.apache.org/jira/browse/MJAVADOC-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15552750#comment-15552750
]
Shannon Carey edited comment on MJAVADOC-467 at 10/6/16 6:30 PM:
-
Wouldn't this give inaccurate report information in a multimodule build if, for
example, you ran:
{code}
git checkout v1
mvn compile
git checkout v2
mvn clean deploy site-deploy
{code}
When the second maven command is run, the reactor module will be cleaned,
deployed, and then the javadoc:aggregate will be run. However, the child
modules have not executed any phases and therefore the aggregate report will
gather data based on the "v1" branch previously compiled.
Or does this change fix that issue somehow?
was (Author: rehevkor5):
Wouldn't this give inaccurate report information in a multimodule build if, for
example, you ran:
```
git checkout v1
mvn compile
git checkout v2
mvn clean deploy site-deploy
```
When the second maven command is run, the reactor module will be cleaned,
deployed, and then the javadoc:aggregate will be run. However, the child
modules have not executed any phases and therefore the aggregate report will
gather data based on the "v1" branch previously compiled.
Or does this change fix that issue somehow?
> Aggregator reports should not require modules to be installed/deployed.
> ---
>
> Key: MJAVADOC-467
> URL: https://issues.apache.org/jira/browse/MJAVADOC-467
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-2766) Refactor DefaultLifecycleExecutor
[ https://issues.apache.org/jira/browse/MNG-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16764613#comment-16764613 ] Shannon Carey commented on MNG-2766: This change ([here|https://github.com/apache/maven/commit/55ecfa65d621150dfffc8add9d08ca469310b35f#diff-12410e6c833b21b8b21bf1475e327a5d]) deprecated MavenProject#getTestDependencies(), but it's not clear what the replacement method is. Anybody know? > Refactor DefaultLifecycleExecutor > - > > Key: MNG-2766 > URL: https://issues.apache.org/jira/browse/MNG-2766 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 3.0-alpha-1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl >Priority: Major > Fix For: 3.0-alpha-3 > > > Another large beast that needs to be broken up. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MRELEASE-1059) Documentation incorrectly states that release.properties is retained
Shannon Carey created MRELEASE-1059:
---
Summary: Documentation incorrectly states that release.properties
is retained
Key: MRELEASE-1059
URL: https://issues.apache.org/jira/browse/MRELEASE-1059
Project: Maven Release Plugin
Issue Type: Improvement
Components: documentation
Reporter: Shannon Carey
[https://maven.apache.org/guides/mini/guide-releasing.html] says:
{quote}The _release.properties_ file is created while preparing the release.
After performing the release the file remains within the project root directory
until the maven user deletes it.
{quote}
However, that is not true. The _release.properties_ file is deleted by the
"perform" step.
Unfortunately, that makes it difficult to determine what version was just
released. But, this Jira is merely requesting for the documentation to be
corrected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286705#comment-17286705 ] Shannon Carey commented on MNG-5761: Another related issue: https://issues.apache.org/jira/browse/SPARK-32385 > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 4.0.x-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shannon Carey updated MNG-5761: --- Comment: was deleted (was: Another related issue: https://issues.apache.org/jira/browse/SPARK-32385 ) > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 4.0.x-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5988) Dependency mediation should prioritize transitive dependencies based on scope.
[
https://issues.apache.org/jira/browse/MNG-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17414579#comment-17414579
]
Shannon Carey commented on MNG-5988:
Btw I see this happening still in 3.6.3.
{quote}is the bug that Maven is not doing what it claims to do
{quote}
Probably not, but I would argue that Maven's document is not very clear about
what it claims. It does explain how version conflicts are resolved, but it also
explains how transitive scope resolution works. And specifically, it says that
if you have a test-scope dependency, the transitive compile-scope dependencies
will be test-scope. That implies that you wouldn't see a test dependency
impacting the compile/runtime classpath as this Jira reports is happening. But,
it's not super clear because the documentation doesn't explain how those
interact.
IMO, an alteration to the test-scope dependencies should have zero impact on
the production (runtime) classpath. It's counterintuitive and creates risk.
{quote}There are multiple solutions to this. The easiest is to just move the
dependency in question up in the hierarchy so that it gets selected.
{quote}
You're right that there are workarounds:
* create an explicit top-level dependency
* use dependency management
* add an to the test dependency (yuck)
However, those workarounds assume some unfriendly things, even from someone
like myself who has been using Maven a long time:
# You've noticed the problem in the first place
# You have to figure out that this is the cause of the problem, which IMO is a
bit mysterious/unexpected
# Every time someone updates a dependency, they have to remember to go through
and copy the transitive dependency versions up to the top-level POM
# Every time someone updates a dependency, they have to remember to go through
the transitive dependencies to figure out whether any should be removed from
the top-level POM
# Every time someone updates a dependency, you may get a sudden mysterious
compilation failure because your now makes the needed library
completely omitted
> Dependency mediation should prioritize transitive dependencies based on scope.
> --
>
> Key: MNG-5988
> URL: https://issues.apache.org/jira/browse/MNG-5988
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.3
>Reporter: Jostein Gogstad
>Priority: Critical
> Fix For: needing-scrub-3.4.0-fallout
>
> Attachments: Collected.svg, MNG-5988.zip, PRE.svg, Resolved.svg
>
>
> The
> [documentation|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]
> states that dependency mediation only supports "nearest definition",
> regardless of the scope of the parent dependency.
> If both compile- and test scoped dependencies shares the same transitive
> dependency, the test-scoped one will win if it has shallower depth. That in
> turn will lead to runtime exceptions since the transitive dependency is no
> longer on the classpath.
> Take the following pom from a typical [Spring
> Boot|http://projects.spring.io/spring-boot/] application. Since the
> {{camel-test-spring}} dependency also depends on spring, it wins and Spring
> is no longer available to the application at runtime.
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.example
> bugreport
> jar
> 1.0.0-SNAPSHOT
>
>
> org.springframework.boot
> spring-boot-starter-web
> 1.3.2.RELEASE
>
>
> org.apache.camel
> camel-test-spring
> 2.16.2
> test
>
>
>
> {code}
> Now look for {{spring-beans}} or {{spring-context}} in the following
> dependency graphs:
> {code:xml|title=mvn dependency:tree (with camel-test-spring)}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ bugreport ---
> [INFO] com.example:bugreport:jar:1.0.0-SNAPSHOT
> [INFO] +-
> org.springframework.boot:spring-boot-starter-web:jar:1.3.2.RELEASE:compile
> [INFO] | +-
> org.springframework.boot:spring-boot-starter:jar:1.3.2.RELEASE:compile
> [INFO] | | +- org.springframework.boot:spring-boot:jar:1.3.2.RELEASE:compile
> [INFO] | | +-
> org.springframework.boot:spring-boot-autoconfigure:jar:1.3.2.RELEASE:compile
> [INFO] | | +-
> org.springframework.boot:spring-boot-starter-logging:jar:1.3.2.RELEASE:compile
> [INFO] | | | +- ch.qos.logback:logback-classic:jar:1.1.3:compile
> [INFO] | | | | \- ch.qos.logback:logback-core:jar:1.1.3:compile
> [INFO] | | | +- org.slf4j:jcl-over-slf4j:jar:1
