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
>
>
--
Sent from my phone
