Am 09/26/16 um 15:29 schrieb Stephen Connolly: > <!-- > provides is a marker that we have duplication of content. > This could be because we are much like the many servlet-api jar > files where there are many GAV's of the same > javax.servlet:servlet-api:3.0 thus we could have the case where > > > org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar:1.0.2.Final > PROVIDES javax.servlet:servlet-api:3.0 > > org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar:1.0.1.Final > PROVIDES javax.servlet:servlet-api:3.0 > > org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar:1.0.0.Final > PROVIDES javax.servlet:servlet-api:3.0 > org.mortbay.jetty:servlet-api-3.0:jar:7.0.0pre2 PROVIDES > javax.servlet:servlet-api:3.0 > > similarly > > org.slf4j:log4j-over-slf4j:jar:1.7.21 PROVIDES > log4j:log4j:[1.0,2)
Looking at the very common API/impl separation, we maybe also should think about providing a way to add dependencies on some abstract implementation without needing to tell the exact implementation to use. Some kind of "virtual" (in need for a better name?) dependency at build pom level. So that 'org.slf4j:slf4j-api' can add a dependency on some virtual 'org.slf4j:slf4j-impl' for which no artifact exists and which is provided by the various slf4j implementations. Currently, when someone adds 'slf4j-api' to a project and uses it, a consumer must manually handle choosing an implementation. If 'slf4j-api' could hold that information (if using slf4j-api, you need to add an artifact providing a 'slf4j-impl' as well), Maven could e.g. display a list of available implementations to choose from or just fail with a friendly error message stating that an implementation artifact is missing for an API artifact. So the 'provides' need not necessarily represent an existing artifact but rather some kind of concept. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
