On 24 November 2013 19:42, Robert Patrick <robert.patr...@oracle.com> wrote:
> > Additionally, I think we should refine scopes... there are some that are
> likely missing and some, such as `system` that should be removed.
>
> Pardon my ignorance but while I understand the negative implications of
> using system-scoped dependencies, I believe there are cases at least a few
> use cases where they are required. For example, we have a plugin that
> depends on tools.jar from the JDK. We currently use a system-scoped
> dependency for this. If you were to remove system-scoped dependencies, how
> would you propose that people handle use cases such as this?
>
>
I think that we need a less Java centric concept for this... or at least to
rework it...
Perhaps it is part of the platform specification, since the ext directory
is really a function of the platform in some senses. The current design is
really supposed to only work with ${java.home} paths... and didn't even
work with those for OSX at least until Oracle took over JDK on OSX... too
much abuse of this as a hack leads me to think that its current incarnation
is just bad design... and I would rather strip out bad design if we have
the chance... of course I am but one voice... if others make compelling
arguments against then we can let the project committers vote and decide in
the absence of consensus... but until we get to that point I think we need
a healthy debate... this is a subject we have ignored to our peril for far
far too long
>
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> Sent: Sunday, November 24, 2013 1:34 PM
> To: Maven Developers List
> Subject: Re: Model Version 5.0.0
>
> On 24 November 2013 17:44, Jason van Zyl <ja...@tesla.io> wrote:
>
> >
> > On Nov 24, 2013, at 10:28 AM, Benson Margulies <bimargul...@gmail.com>
> > wrote:
> >
> > > It seems to me that this thread is mixing two topics.
> > >
> > > Topic #1: How to we move to pom 5.0, given a giant ecosystem of
> > > crappy XML-parsing POM consumers?
> > >
> > > Topic #2: To what extent does the pom mix a 'description of contract'
> > > (dependencies, etc) with a 'specification of build'?
> > >
> > > On the first topic, there was a wiki page months ago that explored a
> > > scheme for writing both a v4 pom and a v5 pom when deploying from a
> > > v5 project, so that old tools could see and consume what they
> understand.
> > > To the extent that this scheme made sense, it can be adopted without
> > > (necessarily) touching the second.
> > >
> >
> > If you are referring to this:
> >
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+
> > the+POM+data+model
> >
> > Then I think what this document lacks are the use cases that drive
> > anything. Without actually having some target features you cannot
> > understand what you require technically.
> >
> > I think from the discussion thus far we have the following features:
> >
> > - API provides (from Stephen)
> > - Runtime requirements (from Manfred)
> > - Global excludes (much asked for feature)
> > - Global swaps (much asked for feature)
> >
>
> Additionally, I think we should refine scopes... there are some that are
> likely missing and some, such as `system` that should be removed.
>
> Platform dependency *could* be handled by dependency, e.g.
>
> <dependency gav="java:java:1.8:platform"/>
>
> could indicate that you need java 8 to run...
>
> The question though is how you handle multiple potential platforms, e.g.
> works on java 1.6 or android...
>
> That may require a change to the dependency model... some sort of
> dependency group... whereby any one of the deps in the group can satisfy
> the need...
>
> A potentially better solution would be a specific platform section... but
> is the more generic <dep> based solution perhaps better?
>
>
>
> > Additionally by requirements:
> > - Are we going to allow for extensibility?
> > - Are we going to be future proof?
> > - Are we going to provide backward compatibility?
> >
> > I believe this is where we start. Many of the answers about how the
> > implementation will look will be driven by specific features and
> > answers to requirements questions.
> >
>
> Another point is that if we don't ack that we need to rev the spec and
> this may be the only chance to rev the spec for a while, we won't see the
> features we need.
>
> Hacking the 4.0.0 pom will only make baby steps and lead to hacky
> solutions... opening up the chance to rev the pom spec and schema opens up
> the potential for other ideas
>
>
> >
> > > On the second topic, I'm in agreement that there should be a clear
> > > separation between describing a contract and other things. For
> > > example, why is it a good idea for deployed poms to reference
> > > parents, rather than being self-contained? Why is it a good idea for
> > > deployed poms to include profiles? Why is it a good thing for
> > > deployed poms to include parameter references, thereby in some cases
> > > accidently changing their semantics due to collisions with the
> > > consuming application's pom? The full 'here's how to build' pom, in
> > > my view, is part of the source, and should be deployed with the
> > > source, and any tool that can usefully analyze the details (plugins,
> > > pluginManagement,
> > > etc) is welcome to do so. Having written this, it also seems to me
> > > that one compromise could be that v5 deployed poms could be
> > > self-contained, complete, but organized so as be clear as to the two
> > > categories of contents.
> > >
> > >
> > >
> > > On Sun, Nov 24, 2013 at 9:29 AM, Igor Fedorenko
> > > <i...@ifedorenko.com>
> > 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. 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 can parse
> > >>>
> > >>> Will it be able to parse all the info in the original pom? Nope...
> > It's an
> > >>> older client... Older clients should not expect to grok all the
> > subtleties
> > >>> of newer poms... But it should get the general shape
> > >>>
> > >>> In all of the above, <packaging>pom</packaging> is special... We
> > >>> just deploy that as is in whatever format
> > >>> (JSON/DSL/XML/groovy/etc) as the -build.pom
> > >>>
> > >>> So 4.0.0 => .pom
> > >>> 5.0.0 onward (XSLT down versioning) => -dep.pom And as a parent =<
> > >>> -build.pom
> > >>>
> > >>> Modern clients can ask for the -dep.pom first... And fall back to
> > >>> the
> > .pom
> > >>>
> > >>> It's not perfect, but it should not be the hell of 3.0.0->4.0.0
> > >>> the
> > fear
> > >>> of
> > >>> which has prevented forward progress since
> > >>>
> > >>>
> > >>>> By separating "consumption" and "production" metadata formats,
> > >>>> we'll
> > be
> > >>>> able to evolve production format more aggressively. For example,
> > >>>> it would be nice to have Tycho-specific configuration markup
> > >>>> inside
> > <build>
> > >>>> section. This is not currently possible because all poms must be
> > >>>> compatible with the same model.
> > >>>>
> > >>>> --
> > >>>> Regards,
> > >>>> Igor
> > >>>>
> > >>>>
> > >>>>
> > >>>> Only with <packaging>pom</packaging> do we actually need things
> > >>>> like the
> > >>>>>>
> > >>>>>> <plugins> section in the deployed pom, because it is a reality
> > >>>>>> that
> > for
> > >>>>>> noo-pom packaging we just want the transitive dependencies.
> > >>>>>>
> > >>>>>> Now there is the <extensions> issue where you might be
> > >>>>>> registering a different file type that has different rules with
> > >>>>>> respect to the classpath... but I am unsure if we actually
> > >>>>>> consider those when evaluating the dependency tree... and in
> > >>>>>> any case, once we accept that the deployed pom is not the same
> > >>>>>> as the pom used to build (for non-pom packaging
> > at
> > >>>>>> least) we can transform that dependency tree using the exact
> > >>>>>> rules
> > that
> > >>>>>> have to be known at build time thus closing the extensions issue.
> > >>>>>>
> > >>>>>> For projects with <packaging>pom</packaging> in fact we are
> > >>>>>> only deploying smal files so perhaps we can deploy two pom
> > >>>>>> files... the one that exposes the standard dependency stuff and
> > >>>>>> then a second one that is used for build inheritance.
> > >>>>>>
> > >>>>>> My vision is thus that we deploy between 2 and three pom files
> > >>>>>> for every project.
> > >>>>>>
> > >>>>>> For jar/war/ear/... we deploy:
> > >>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> > >>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies
> > >>>>>> but allows for new scopes)
> > >>>>>>
> > >>>>>> For pom we deploy
> > >>>>>> * a modelVersion 4.0.0 pom as .pom (only lists dependencies)
> > >>>>>> * a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies
> > >>>>>> but allows for new scopes)
> > >>>>>> * the pom itself
> > >>>>>>
> > >>>>>> When building a pom, your parent pom must be of a modelVersion
> > >>>>>> <=
> > your
> > >>>>>> modelVersion.
> > >>>>>>
> > >>>>>
> > >>>>> Thanks,
> > >>>>>
> > >>>>> Jason
> > >>>>>
> > >>>>> ----------------------------------------------------------
> > >>>>> Jason van Zyl
> > >>>>> Founder, Apache Maven
> > >>>>> http://twitter.com/jvanzyl
> > >>>>> ---------------------------------------------------------
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>> -----------------------------------------------------------------
> > >>>> ---- 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
> > >>
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
> > > additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> >
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
