ah ok, I better understand your intend with provides: it's not a way to find implementers (like expected by Igor and I), but a way to avoid collisions
I didn't think at such an approach for the moment: need to thk=ink more at it but at a first glance, I find your idea better than what I feared previously :) Regards, Hervé Le dimanche 24 novembre 2013 16:16:33 Stephen Connolly a écrit : > On Sunday, 24 November 2013, Igor Fedorenko wrote: > > How do you find all artifacts that provide gav="javax:servlet-api:3.0"? > > You don't need to. > > You just need to treat it as a global excludes on javax:servlet-api > > The difference is that it also excludes any other poms that get pulled in > transitively and also have the same provides... > > You only need to look at the poms that are resolved via the current pom for > which we are evaluating the dependency tree > > > One option is to download entire repository index to the client, but > > Central index will likely be in 100x of megabytes, which makes this > > approach impractical. The only other option is to keep the index on the > > server and have server-side helper to answer index queries. > > > > -- > > Regards, > > Igor > > > > On 11/24/2013, 10:38, Stephen Connolly wrote: > > > > On Sunday, 24 November 2013, Igor Fedorenko wrote: > > I think we are saying the same thing -- we evolve project model used > > > > during the build but deploy both the new and backwards compatible models. > > > > One quick note on representing dependencies as provided/required > > capabilities. > > > > > > > > I think it needs to be deterministic, which means it should not need an > > active server-side assist. > > > > A pom could declare > > > > <provides> > > > > <provide gav="javax:servlet-api:3.0"/> > > > > </provides> > > > > That means if you declare *that* pom as a dependency of yours it will (by > > being nearer in the graph) replace any servlet-api dependencies in your > > graph. > > > > You can also do similar with dependencies, eg > > > > <dependency gav="org.slf4j:log4j-over-slf4j:1.7"> > > > > <provides> > > > > <provide gav="log4j:log4j:1.2"/> > > > > </provides> > > > > </dependency> > > > > Either form is deterministic and does not introduce dynamic resolution > > into > > the model... But they make the things people want to do a lot easier IMHO > > > > Although I like this idea in general, I believe it will > > > > require completely new repository layout to be able to efficiently > > find capability providers. Single repository-wide metadata index file, > > the approach implemented in P2 for example, won't scale for repositories > > of the size of Central, so most likely the new repository layout will > > require active server-side component to assist dependency resolution. > > > > -- > > Regards, > > Igor > > > > On 11/24/2013, 4:25, Stephen Connolly wrote: > > > > On Sunday, 24 November 2013, Igor Fedorenko wrote: > > > > > > > > On 11/23/2013, 23:08, Jason van Zyl wrote: > > > > > > On Nov 23, 2013, at 5:44 PM, Stephen Connolly > > > > <stephen.alan.conno...@gmail.com> wrote: > > Before I forget, here are some of my thoughts on moving towards > > > > Model Version 5.0.0 > > > > The pom that we build with need not be the pom that gets > > deployed... thus the pom that is built with need not be the same > > format as the pom that gets deployed. > > > > Can you explain why you think this is useful? To me all the > > > > information that is carried with the POM after deployment is > > primarily for the consumption of tools, and there are a lot of tools > > that expect more than the dependency information. Removing all other > > elements in the POM is equivalent to being massively backward > > incompatible for an API. And if the subsequent consumption after > > deployment is primarily by programs, then why does it matter what > > gets deployed. I don't really see much benefit, but will create all > > sorts of technical problems where we need multiple readers and all > > that entails and the massive number of problems this will cause > > people who have created tooling, especially IDE integration. > > > > > > > The way I see it, what is deployed describes how the artifact needs to > > be consumed. This is artifact's "public API", if you will, it will be > > consumed by wide range of tools that resolve dependencies from Maven > > repositories and descriptor format should be very stable. Mostly likely > > we have no choice but use (a subset of) the current 4.0.0 model version. > > > > > > > > I would be very sad if we are limited to a subset. > > > > There are some critical concepts that in my view are missing from pom > > files. > > > > Number one on my hit list is a <provides> concept. > > > > Where you declare that an artifact *provides* the same api as another GAV. > > > > Technically you'd need to be able to specify this both at the root of a > > pom > > and also flag specific dependencies (because the api they provide was not > > specified when that pom was deployed) > > > > Thus the Geronimo specs poms could all <provides> the corresponding JavaEE > > specs and excludes issues or other hacks would no longer be required. > > > > Look at the issues you will have if you use the excludes wildcards in your > > pom... Namely *anyone* who uses your artifact as a dependency will need to > > be using Maven 3 or newer... does ivy read those wildcards correctly? Does > > sbt? Does Buildr? > > > > They are a tempting siren... And from another PoV they will force others > > to > > follow... *but* if we are forcing them to follow should we not pick a > > nicer > > format to follow... Not one consisting of many layers of hacks? > > > > The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) so that > > legacy clients can still make some sense... If a modelVersion 5.0.0 > > feature > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
