[jira] [Commented] (MDEP-557) In dependency analysis, support Spring Boot style intentional transitive compile-time dependencies
[
https://issues.apache.org/jira/browse/MDEP-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288074#comment-17288074
]
M. Justin commented on MDEP-557:
A non-Spring example of this sort of dependency is the {{junit-jupiter}}
dependency (per
[junit5#1629|https://github.com/junit-team/junit5/issues/1629]), which combines
{{junit-jupiter-api}}, {{junit-jupiter-params}} and {{junit-jupiter-engine}},
as they are often used together.
> In dependency analysis, support Spring Boot style intentional transitive
> compile-time dependencies
> --
>
> Key: MDEP-557
> URL: https://issues.apache.org/jira/browse/MDEP-557
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Reporter: M. Justin
>Priority: Minor
> Labels: S2
>
> h1. Request
> It would be useful if using Spring Boot "starter" dependencies as intended
> didn't cause warnings with dependency:analyze (and related goals).
> h1. Background
> Spring Boot has a notion of "starter" dependencies. One of the primary
> purposes of starter dependencies is to transitively bring in numerous other
> dependencies to be used at both runtime and compile time. Per [Spring Boot's
> documentation|http://docs.spring.io/spring-boot/docs/1.5.1.RELEASE/reference/htmlsingle/#using-boot-starter]:
> {quote}
> Starters are a set of convenient dependency descriptors that you can include
> in your application. You get a one-stop-shop for all the Spring and related
> technology that you need, without having to hunt through sample code and copy
> paste loads of dependency descriptors. For example, if you want to get
> started using Spring and JPA for database access, just include the
> spring-boot-starter-data-jpa dependency in your project, and you are good to
> go.
> The starters contain a lot of the dependencies that you need to get a project
> up and running quickly and with a consistent, supported set of managed
> transitive dependencies.
> {quote}
> However, this is at odds with the analysis done by
> [dependency:analyze|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html]
> (and similar goals in the dependency plugin). The analyze goals will warn
> that the starter projects are "unused declared dependencies" and any
> compile-time dependencies that are transitively brought in this way will
> produce "used undeclared dependencies" warnings. Note that this warning
> behavior is consistent with the [Maven dependency
> documentation|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> where it states that it is intended that all compile dependencies be
> explicitly listed, rather than transitively used at compile time:
> {quote}it is intended that \[transitive compile dependencies\] should be
> runtime scope instead, so that all compile dependencies must be explicitly
> listed - however, there is the case where the library you depend on extends a
> class from another library, forcing you to have available at compile time.
> For this reason, compile time dependencies remain as compile scope even when
> they are transitive.{quote}
> As a concrete example, here are the warnings generated by {{mvn
> dependency:analyze}} on Spring Boot's own "[Getting
> Started|https://spring.io/guides/gs/spring-boot/]; example:
> {code}Used undeclared dependencies found:
>org.springframework:spring-web:jar:4.3.6.RELEASE:compile
>org.springframework.boot:spring-boot-test:jar:1.5.1.RELEASE:test
>
> org.springframework.boot:spring-boot-test-autoconfigure:jar:1.5.1.RELEASE:test
>org.springframework:spring-test:jar:4.3.6.RELEASE:test
>org.springframework.boot:spring-boot:jar:1.5.1.RELEASE:compile
>org.hamcrest:hamcrest-library:jar:1.3:test
>org.springframework:spring-context:jar:4.3.6.RELEASE:compile
>junit:junit:jar:4.12:test
>
> org.springframework.boot:spring-boot-autoconfigure:jar:1.5.1.RELEASE:compile
>org.springframework:spring-beans:jar:4.3.6.RELEASE:compile
> Unused declared dependencies found:
>org.springframework.boot:spring-boot-starter-web:jar:1.5.1.RELEASE:compile
>org.springframework.boot:spring-boot-starter-test:jar:1.5.1.RELEASE:test
>
> org.springframework.boot:spring-boot-starter-actuator:jar:1.5.1.RELEASE:compile{code}
> My initial thought was that perhaps Spring Boot was misuing the Maven
> dependency mechanism through their approach, however that is not their
> interpretation (see the discussion at
> [spring-boot#8341|https://github.com/spring-projects/spring-boot/issues/8341]).
> So, assuming I'm interpreting things correctly, it seems like the thought is
> that Spring Boot's usage of dependencies is A-OK. Given this, and the impact
[jira] [Created] (MDEP-557) In dependency analysis, support Spring Boot style intentional transitive compile-time dependencies
M. Justin created MDEP-557:
--
Summary: In dependency analysis, support Spring Boot style
intentional transitive compile-time dependencies
Key: MDEP-557
URL: https://issues.apache.org/jira/browse/MDEP-557
Project: Maven Dependency Plugin
Issue Type: New Feature
Components: analyze
Reporter: M. Justin
Priority: Minor
h1. Request
It would be useful if using Spring Boot "starter" dependencies as intended
didn't cause warnings with dependency:analyze (and related goals).
h1. Background
Spring Boot has a notion of "starter" dependencies. One of the primary
purposes of starter dependencies is to transitively bring in numerous other
dependencies to be used at both runtime and compile time. Per [Spring Boot's
documentation|http://docs.spring.io/spring-boot/docs/1.5.1.RELEASE/reference/htmlsingle/#using-boot-starter]:
{quote}
Starters are a set of convenient dependency descriptors that you can include in
your application. You get a one-stop-shop for all the Spring and related
technology that you need, without having to hunt through sample code and copy
paste loads of dependency descriptors. For example, if you want to get started
using Spring and JPA for database access, just include the
spring-boot-starter-data-jpa dependency in your project, and you are good to go.
The starters contain a lot of the dependencies that you need to get a project
up and running quickly and with a consistent, supported set of managed
transitive dependencies.
{quote}
However, this is at odds with the analysis done by
[dependency:analyze|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html]
(and similar goals in the dependency plugin). The analyze goals will warn
that the starter projects are "unused declared dependencies" and any
compile-time dependencies that are transitively brought in this way will
produce "used undeclared dependencies" warnings. Note that this warning
behavior is consistent with the [Maven dependency
documentation|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
where it states that it is intended that all compile dependencies be
explicitly listed, rather than transitively used at compile time:
{quote}it is intended that \[transitive compile dependencies\] should be
runtime scope instead, so that all compile dependencies must be explicitly
listed - however, there is the case where the library you depend on extends a
class from another library, forcing you to have available at compile time. For
this reason, compile time dependencies remain as compile scope even when they
are transitive.{quote}
As a concrete example, here are the warnings generated by {{mvn
dependency:analyze}} on Spring Boot's own "[Getting
Started|https://spring.io/guides/gs/spring-boot/]; example:
{code}Used undeclared dependencies found:
org.springframework:spring-web:jar:4.3.6.RELEASE:compile
org.springframework.boot:spring-boot-test:jar:1.5.1.RELEASE:test
org.springframework.boot:spring-boot-test-autoconfigure:jar:1.5.1.RELEASE:test
org.springframework:spring-test:jar:4.3.6.RELEASE:test
org.springframework.boot:spring-boot:jar:1.5.1.RELEASE:compile
org.hamcrest:hamcrest-library:jar:1.3:test
org.springframework:spring-context:jar:4.3.6.RELEASE:compile
junit:junit:jar:4.12:test
org.springframework.boot:spring-boot-autoconfigure:jar:1.5.1.RELEASE:compile
org.springframework:spring-beans:jar:4.3.6.RELEASE:compile
Unused declared dependencies found:
org.springframework.boot:spring-boot-starter-web:jar:1.5.1.RELEASE:compile
org.springframework.boot:spring-boot-starter-test:jar:1.5.1.RELEASE:test
org.springframework.boot:spring-boot-starter-actuator:jar:1.5.1.RELEASE:compile{code}
My initial thought was that perhaps Spring Boot was misuing the Maven
dependency mechanism through their approach, however that is not their
interpretation (see the discussion at
[spring-boot#8341|https://github.com/spring-projects/spring-boot/issues/8341]).
So, assuming I'm interpreting things correctly, it seems like the thought is
that Spring Boot's usage of dependencies is A-OK. Given this, and the impact
of Spring Boot in the Java ecosystem, it seems like it would be good for there
to be support for this pattern within Maven's dependency analysis. I'm not
sure what the most appropriate mechanism for this would be, however (and
whether the dependency plugin is the primary place it should be supported). Is
this just something that should be configurable within the dependency:analyze
plugin itself? Are the starter dependencies a new class of dependency that
should be called out within Maven? Is this something where the starter
dependency should be able to declare that its compile-time dependencies are
meant to be exported and directly used?
h1. Workaround
The
[jira] [Commented] (MRELEASE-843) Child modules defined in profiles aren't updated by update-versions
[
https://issues.apache.org/jira/browse/MRELEASE-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14483925#comment-14483925
]
M. Justin commented on MRELEASE-843:
Inactive, per my included example.
Child modules defined in profiles aren't updated by update-versions
---
Key: MRELEASE-843
URL: https://issues.apache.org/jira/browse/MRELEASE-843
Project: Maven Release Plugin
Issue Type: Bug
Components: update-versions
Reporter: M. Justin
When I do a mvn:update-versions for a multi-module project that has one of
its modules defined in a profile, the modules defined in the profile don't
have their versions updated. I would expect these modules to also be updated.
{code:title=pom.xml}project xmlns=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;
modelVersion4.0.0/modelVersion
packagingpom/packaging
groupIdcom.example/groupId
artifactIdexample-parent/artifactId
version1.0.0-SNAPSHOT/version
modules
moduleexample-module1/module
/modules
profiles
profile
idmy-profile/id
modules
moduleexample-module2/module
/modules
/profile
/profiles
scm
developerConnectionscm:git:examplerepo:example.git/developerConnection
/scm
/project
{code}
In this example, when I execute mvn release:update-versions, I get queried to
update example-parent and example-module1, but not example-module2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MRELEASE-843) Child modules defined in profiles aren't updated by update-versions
M. Justin created MRELEASE-843:
--
Summary: Child modules defined in profiles aren't updated by
update-versions
Key: MRELEASE-843
URL: https://jira.codehaus.org/browse/MRELEASE-843
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: update-versions
Reporter: M. Justin
When I do a mvn:update-versions for a multi-module project that has one of its
modules defined in a profile, the modules defined in the profile don't have
their versions updated. I would expect these modules to also be updated.
{code:title=pom.xml}project xmlns=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;
modelVersion4.0.0/modelVersion
packagingpom/packaging
groupIdcom.example/groupId
artifactIdexample-parent/artifactId
version1.0.0-SNAPSHOT/version
modules
moduleexample-module1/module
/modules
profiles
profile
idmy-profile/id
modules
moduleexample-module2/module
/modules
/profile
/profiles
scm
developerConnectionscm:git:examplerepo:example.git/developerConnection
/scm
/project
{code}
In this example, when I execute mvn release:update-versions, I get queried to
update example-parent and example-module1, but not example-module2.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
