don't we have toolchains for such a case?
Regards,
Hervé
Le dimanche 24 novembre 2013 20:13:38 Stephen Connolly a écrit :
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
