[jira] [Commented] (MNG-5652) "supplies"/"provides"/"proffers" concept proposal
[
https://issues.apache.org/jira/browse/MNG-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748076#comment-17748076
]
Vladimir Sitnikov commented on MNG-5652:
Version ranges often create complexity issues. Would it be enough to use a
fixed capability version rather than a range?
For instance, Gradle supports single-version capabilities for quite some time
now, and it is enough to describe many cases in JVM ecosystem.
See
* [https://docs.gradle.org/current/userguide/component_capabilities.html]
* [https://github.com/gradlex-org/java-ecosystem-capabilities]
At the same time, Gradle Module Metadata can already describe the capabilities
(see
[https://github.com/gradle/gradle/blob/48257a8256a089c426df1a787d1dec5b233cd77b/subprojects/docs/src/docs/design/gradle-module-metadata-latest-specification.md#capabilities-value]
)
> "supplies"/"provides"/"proffers" concept proposal
> -
>
> Key: MNG-5652
> URL: https://issues.apache.org/jira/browse/MNG-5652
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Stephen Connolly
>Priority: Major
>
> The exact name is still undecided. Some candidate names are: "supplies",
> "provides", and "proffers"
> h2. "supplies" concept proposal
> ===
> h3. Introduction
>
> The following is a proposal for Maven in a post-modelVersion-4.0.0 era. The
> aim of this proposal is to simplify the management of dependency trees in the
> decentralised era of artifact production that we find ourselves in.
> The core issue is that different organisations can produce artifacts that may
> overlap. The easiest example is the servlet-api. If we restrict ourselves to
> version 2.5 of the servlet specification there are quite a few artifacts that
> all deliver the exact same content:
> * {{jetty:servlet-api:2.5-6.0.2}}
> * {{org.daisy.libs:servlet-api:2.5.0}}
> * {{org.mortbay.jetty:servlet-api-2.5:6.1.14}}
> * {{org.jboss.spec.javax.servlet:jboss-servlet-api_2.5_spec:1.0.1.Final}}
> * etc
> **Note:** this is a generic problem that is not restricted to the
> servlet-api, the servlet-api just provides the example that will be most
> familiar to everyone.
> So where these multiple artifacts supplying the equivalent content becomes a
> problem is when the dependency tree is being calculated. If you have two
> dependencies each declaring transitive dependencies on different artifacts
> that supply equivalent content, then you end up with two copies of the same
> JAR file in your classpath.
> In the case of the servlet-api, the hack most people use is to declare the
> servlet-api with scope `provided` thus preventing it from being transitive.
> This is, however, a hack. In a more ideal world it would be better to let the
> servlet-api be transitive and only when we get to the WAR module would we
> declare that a specific servlet-api is to be provided in the containers that
> the WAR is targets for deployment into.
> We can take a second example that does not have the luxury of a *de facto*
> hack.
> * {{javax.faces:jsf-api:2.1}}
> * {{org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec:2.1.28.Final}}
> * {{org.apache.myfaces.core:myfaces-api:2.1.13}}
> Now in the case of the JSF API, you are supposed to bundle the JSF API in
> your WAR file. So if I use three JSF component libraries, I could very well
> end up with three different but equivalent JSF API jars in my WAR file.
> Ideally what we want is some way of telling Maven that these artifacts are
> equivalent.
> Proposal
>
> Introduce the concept of "supplies" to the project model. The concept needs
> three changes to the project model:
> 1. An explicit top level construct for a project to explicitly declare
> up-front artifacts that it knows - at the time the project is being authored
> - to contain equivalent content to at least a subset of the project's
> content. Declarations could include a claim from: `subset`, `superset`,
> `disjoint` and `equivalent` with the default being `disjoint`.
> 2. An explicit sub-element of the `dependency` construct to allow consumers
> to *post-facto* declare a specific dependency as supplying equivalent content
> for other dependencies
> 3. An extension to the `dependency/excludes/exclude` construct to allow
> consumers to remove claims a dependency makes with respect to supplying
> equivalent content
> By way of illustration, here are some examples of these constructs mapped to
> a Model Version 4.0.0 like XML schema. As the post-modelVersion-4.0.0 schema
> is not yet known, this represents the best way to illustrate how the concept
> will work, but note that this proposal does not suggest a schema for this
> concept.
> h3. Example 1
> This illustrates how we would want, say, the `myfaces-api`
[jira] [Commented] (MNG-5652) "supplies"/"provides"/"proffers" concept proposal
[
https://issues.apache.org/jira/browse/MNG-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999071#comment-16999071
]
Stephen Connolly commented on MNG-5652:
---
It is in no way obsolete.
1. Java modules are orthogonal in some ways, plus we still have lots of
duplicate artifacts
2. Maven shouldn’t be *just* JVM, and non-JVM needs will require this also
3. I have already integrated this into the PDT proposal
> "supplies"/"provides"/"proffers" concept proposal
> -
>
> Key: MNG-5652
> URL: https://issues.apache.org/jira/browse/MNG-5652
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Stephen Connolly
>Priority: Major
>
> The exact name is still undecided. Some candidate names are: "supplies",
> "provides", and "proffers"
> h2. "supplies" concept proposal
> ===
> h3. Introduction
>
> The following is a proposal for Maven in a post-modelVersion-4.0.0 era. The
> aim of this proposal is to simplify the management of dependency trees in the
> decentralised era of artifact production that we find ourselves in.
> The core issue is that different organisations can produce artifacts that may
> overlap. The easiest example is the servlet-api. If we restrict ourselves to
> version 2.5 of the servlet specification there are quite a few artifacts that
> all deliver the exact same content:
> * {{jetty:servlet-api:2.5-6.0.2}}
> * {{org.daisy.libs:servlet-api:2.5.0}}
> * {{org.mortbay.jetty:servlet-api-2.5:6.1.14}}
> * {{org.jboss.spec.javax.servlet:jboss-servlet-api_2.5_spec:1.0.1.Final}}
> * etc
> **Note:** this is a generic problem that is not restricted to the
> servlet-api, the servlet-api just provides the example that will be most
> familiar to everyone.
> So where these multiple artifacts supplying the equivalent content becomes a
> problem is when the dependency tree is being calculated. If you have two
> dependencies each declaring transitive dependencies on different artifacts
> that supply equivalent content, then you end up with two copies of the same
> JAR file in your classpath.
> In the case of the servlet-api, the hack most people use is to declare the
> servlet-api with scope `provided` thus preventing it from being transitive.
> This is, however, a hack. In a more ideal world it would be better to let the
> servlet-api be transitive and only when we get to the WAR module would we
> declare that a specific servlet-api is to be provided in the containers that
> the WAR is targets for deployment into.
> We can take a second example that does not have the luxury of a *de facto*
> hack.
> * {{javax.faces:jsf-api:2.1}}
> * {{org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec:2.1.28.Final}}
> * {{org.apache.myfaces.core:myfaces-api:2.1.13}}
> Now in the case of the JSF API, you are supposed to bundle the JSF API in
> your WAR file. So if I use three JSF component libraries, I could very well
> end up with three different but equivalent JSF API jars in my WAR file.
> Ideally what we want is some way of telling Maven that these artifacts are
> equivalent.
> Proposal
>
> Introduce the concept of "supplies" to the project model. The concept needs
> three changes to the project model:
> 1. An explicit top level construct for a project to explicitly declare
> up-front artifacts that it knows - at the time the project is being authored
> - to contain equivalent content to at least a subset of the project's
> content. Declarations could include a claim from: `subset`, `superset`,
> `disjoint` and `equivalent` with the default being `disjoint`.
> 2. An explicit sub-element of the `dependency` construct to allow consumers
> to *post-facto* declare a specific dependency as supplying equivalent content
> for other dependencies
> 3. An extension to the `dependency/excludes/exclude` construct to allow
> consumers to remove claims a dependency makes with respect to supplying
> equivalent content
> By way of illustration, here are some examples of these constructs mapped to
> a Model Version 4.0.0 like XML schema. As the post-modelVersion-4.0.0 schema
> is not yet known, this represents the best way to illustrate how the concept
> will work, but note that this proposal does not suggest a schema for this
> concept.
> h3. Example 1
> This illustrates how we would want, say, the `myfaces-api` project model to
> look.
> {code:xml}
>
> org.apache.myfaces.core
> myfaces-api
> 2.1.3
> ...
>
>
> javax.faces
> jsf-api
> [2.1,2.2)
> superset
>
>
> org.jboss.spec.javax.faces
> jboss-jsf-api_2.1_spec
> equivalent
>
>
> ...
>
> {code}
> This indicates that the {{myfaces-api}} artifact is intended to be useable as
> a drop-in replacement for either
[jira] [Commented] (MNG-5652) "supplies"/"provides"/"proffers" concept proposal
[
https://issues.apache.org/jira/browse/MNG-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999020#comment-16999020
]
elharo commented on MNG-5652:
-
This proposal is interesting but it feels obsolete in a Java 9+ world. Would it
be OK to close it? If someone wants to work on it in the future, they'll likely
need to write a new proposal that starts with the Java Platform Module System
and other Java 9+ features.
> "supplies"/"provides"/"proffers" concept proposal
> -
>
> Key: MNG-5652
> URL: https://issues.apache.org/jira/browse/MNG-5652
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Stephen Connolly
>Priority: Major
>
> The exact name is still undecided. Some candidate names are: "supplies",
> "provides", and "proffers"
> h2. "supplies" concept proposal
> ===
> h3. Introduction
>
> The following is a proposal for Maven in a post-modelVersion-4.0.0 era. The
> aim of this proposal is to simplify the management of dependency trees in the
> decentralised era of artifact production that we find ourselves in.
> The core issue is that different organisations can produce artifacts that may
> overlap. The easiest example is the servlet-api. If we restrict ourselves to
> version 2.5 of the servlet specification there are quite a few artifacts that
> all deliver the exact same content:
> * {{jetty:servlet-api:2.5-6.0.2}}
> * {{org.daisy.libs:servlet-api:2.5.0}}
> * {{org.mortbay.jetty:servlet-api-2.5:6.1.14}}
> * {{org.jboss.spec.javax.servlet:jboss-servlet-api_2.5_spec:1.0.1.Final}}
> * etc
> **Note:** this is a generic problem that is not restricted to the
> servlet-api, the servlet-api just provides the example that will be most
> familiar to everyone.
> So where these multiple artifacts supplying the equivalent content becomes a
> problem is when the dependency tree is being calculated. If you have two
> dependencies each declaring transitive dependencies on different artifacts
> that supply equivalent content, then you end up with two copies of the same
> JAR file in your classpath.
> In the case of the servlet-api, the hack most people use is to declare the
> servlet-api with scope `provided` thus preventing it from being transitive.
> This is, however, a hack. In a more ideal world it would be better to let the
> servlet-api be transitive and only when we get to the WAR module would we
> declare that a specific servlet-api is to be provided in the containers that
> the WAR is targets for deployment into.
> We can take a second example that does not have the luxury of a *de facto*
> hack.
> * {{javax.faces:jsf-api:2.1}}
> * {{org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec:2.1.28.Final}}
> * {{org.apache.myfaces.core:myfaces-api:2.1.13}}
> Now in the case of the JSF API, you are supposed to bundle the JSF API in
> your WAR file. So if I use three JSF component libraries, I could very well
> end up with three different but equivalent JSF API jars in my WAR file.
> Ideally what we want is some way of telling Maven that these artifacts are
> equivalent.
> Proposal
>
> Introduce the concept of "supplies" to the project model. The concept needs
> three changes to the project model:
> 1. An explicit top level construct for a project to explicitly declare
> up-front artifacts that it knows - at the time the project is being authored
> - to contain equivalent content to at least a subset of the project's
> content. Declarations could include a claim from: `subset`, `superset`,
> `disjoint` and `equivalent` with the default being `disjoint`.
> 2. An explicit sub-element of the `dependency` construct to allow consumers
> to *post-facto* declare a specific dependency as supplying equivalent content
> for other dependencies
> 3. An extension to the `dependency/excludes/exclude` construct to allow
> consumers to remove claims a dependency makes with respect to supplying
> equivalent content
> By way of illustration, here are some examples of these constructs mapped to
> a Model Version 4.0.0 like XML schema. As the post-modelVersion-4.0.0 schema
> is not yet known, this represents the best way to illustrate how the concept
> will work, but note that this proposal does not suggest a schema for this
> concept.
> h3. Example 1
> This illustrates how we would want, say, the `myfaces-api` project model to
> look.
> {code:xml}
>
> org.apache.myfaces.core
> myfaces-api
> 2.1.3
> ...
>
>
> javax.faces
> jsf-api
> [2.1,2.2)
> superset
>
>
> org.jboss.spec.javax.faces
> jboss-jsf-api_2.1_spec
> equivalent
>
>
> ...
>
> {code}
> This indicates that the {{myfaces-api}} artifact is intended to be useable as
> a drop-in replacement for either
[jira] [Commented] (MNG-5652) "supplies"/"provides"/"proffers" concept proposal
[
https://issues.apache.org/jira/browse/MNG-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15401285#comment-15401285
]
Robert Scholte commented on MNG-5652:
-
http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html Jigsaw/Java9 recognizes
this as well, they introduce {{provides X.Y with Z1.Z2;}}, but they can do it
on a TypeName level.
> "supplies"/"provides"/"proffers" concept proposal
> -
>
> Key: MNG-5652
> URL: https://issues.apache.org/jira/browse/MNG-5652
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Stephen Connolly
>
> The exact name is still undecided. Some candidate names are: "supplies",
> "provides", and "proffers"
> h2. "supplies" concept proposal
> ===
> h3. Introduction
>
> The following is a proposal for Maven in a post-modelVersion-4.0.0 era. The
> aim of this proposal is to simplify the management of dependency trees in the
> decentralised era of artifact production that we find ourselves in.
> The core issue is that different organisations can produce artifacts that may
> overlap. The easiest example is the servlet-api. If we restrict ourselves to
> version 2.5 of the servlet specification there are quite a few artifacts that
> all deliver the exact same content:
> * {{jetty:servlet-api:2.5-6.0.2}}
> * {{org.daisy.libs:servlet-api:2.5.0}}
> * {{org.mortbay.jetty:servlet-api-2.5:6.1.14}}
> * {{org.jboss.spec.javax.servlet:jboss-servlet-api_2.5_spec:1.0.1.Final}}
> * etc
> **Note:** this is a generic problem that is not restricted to the
> servlet-api, the servlet-api just provides the example that will be most
> familiar to everyone.
> So where these multiple artifacts supplying the equivalent content becomes a
> problem is when the dependency tree is being calculated. If you have two
> dependencies each declaring transitive dependencies on different artifacts
> that supply equivalent content, then you end up with two copies of the same
> JAR file in your classpath.
> In the case of the servlet-api, the hack most people use is to declare the
> servlet-api with scope `provided` thus preventing it from being transitive.
> This is, however, a hack. In a more ideal world it would be better to let the
> servlet-api be transitive and only when we get to the WAR module would we
> declare that a specific servlet-api is to be provided in the containers that
> the WAR is targets for deployment into.
> We can take a second example that does not have the luxury of a *de facto*
> hack.
> * {{javax.faces:jsf-api:2.1}}
> * {{org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec:2.1.28.Final}}
> * {{org.apache.myfaces.core:myfaces-api:2.1.13}}
> Now in the case of the JSF API, you are supposed to bundle the JSF API in
> your WAR file. So if I use three JSF component libraries, I could very well
> end up with three different but equivalent JSF API jars in my WAR file.
> Ideally what we want is some way of telling Maven that these artifacts are
> equivalent.
> Proposal
>
> Introduce the concept of "supplies" to the project model. The concept needs
> three changes to the project model:
> 1. An explicit top level construct for a project to explicitly declare
> up-front artifacts that it knows - at the time the project is being authored
> - to contain equivalent content to at least a subset of the project's
> content. Declarations could include a claim from: `subset`, `superset`,
> `disjoint` and `equivalent` with the default being `disjoint`.
> 2. An explicit sub-element of the `dependency` construct to allow consumers
> to *post-facto* declare a specific dependency as supplying equivalent content
> for other dependencies
> 3. An extension to the `dependency/excludes/exclude` construct to allow
> consumers to remove claims a dependency makes with respect to supplying
> equivalent content
> By way of illustration, here are some examples of these constructs mapped to
> a Model Version 4.0.0 like XML schema. As the post-modelVersion-4.0.0 schema
> is not yet known, this represents the best way to illustrate how the concept
> will work, but note that this proposal does not suggest a schema for this
> concept.
> h3. Example 1
> This illustrates how we would want, say, the `myfaces-api` project model to
> look.
> {code:xml}
>
> org.apache.myfaces.core
> myfaces-api
> 2.1.3
> ...
>
>
> javax.faces
> jsf-api
> [2.1,2.2)
> superset
>
>
> org.jboss.spec.javax.faces
> jboss-jsf-api_2.1_spec
> equivalent
>
>
> ...
>
> {code}
> This indicates that the {{myfaces-api}} artifact is intended to be useable as
> a drop-in replacement for either the {{javax.faces:jsf-api}} artifact within
> a bounded range or for any version of the
>
