I have one more remark to contribute to this. In my view, the first step should be to make a 4.0-beta version of Maven that has a '5.0.0' pom that is _identical_ to the 4.0.0 pom. The difference is that we will document, after the fashion of HTML5, our intent to change it over time. We can then adopt any ideas for a better POM as small increments. Maybe we don't call it 4.0(no beta) until we have incremented to the point of serious new value.
On Sun, Nov 24, 2013 at 10:48 AM, Igor Fedorenko <i...@ifedorenko.com> wrote: > How do you find all artifacts that provide gav="javax:servlet-api:3.0"? > 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 >>> cannot be mapped down to 4.0.0... Well we try our best and that's what >>> you >>> get... We should make it sure that people stuck with older clients can >>> read >>> something semi-sensible and then layer their hacks as normal to get the >>> behaviour they need. >>> >>> Thus <provides> (which is not a scope but a GAV) can be modelled by >>> having >>> the modelVersion 4.0.0 pom list the collapsed dependencies with the >>> appropriate <excludes> added (without wildcards) >>> >>> Other concepts cannot be mapped, so they get dropped. >>> >>> >>> How the artifact is produced, on the other hand, is artifact's >>> implementation detail. It is perfectly reasonable for a project to >>> require minimal version of Maven, for example. Or use completely >>> different format, not related to pom at all. >>> >>> >>> >>> Exactly... The pom used to build can be written in JSON or whatever >>> domain >>> specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML >>> because >>> it will be read my machines. >>> >>> Now for the reason I think deploying a pom as xml may be a good thing... >>> XSLT >>> >>> Suppose we specify a XSLT GAV that will down-map the pom to a >>> modelVersion >>> 5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom to the >>> one >>> GAVCT and a modelVersion 5.0.0 client reads is, sees it is a modelVersion >>> that is not understood, sees the GAV of the XSLT, pulls it down and >>> transforms the model into the version it c >>> >>> >> > > --------------------------------------------------------------------- > 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
