Consumer-dom is an extraction and enriched version of the pom and will
be
a separate upload to the repository. Build tools who can understand this
file can use it or fall back by downloading all poms.
thanks,
Robert
On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
> The consumer Pom is for machine to machine, it should be human
readable
> because that is nice, but intent is never human generated.
>
> Switching to this separation allows us to be more radical in the
changes
> to
> the build Pom.
>
> The only reason we deploy packaging Pom's build Pom is for
inheritance.
> If
> we didn't have to deal with that we wouldn't need to deploy any build
> poms
> ever.
>
> For using a build Pom as a parent, you implicitly pick up the minimum
> version of maven that your parent requires, so we then are free to
evolve
> the build Pom format without worrying about forward compatibility,
only
> backwards compatibility on the *build* Pom.
>
> The consumer Pom needs partial *forward* compatibility, so that older
> clients are able to *attempt* to consume...
>
> In short there are totally different compatibility constraints on the
> two,
> so they should be separate.
>
> Mixins would probably also be deployed, once we figure out how they
work
> with build poms.
>
> I think we probably need to rethink version ranges. What I'd like is
to
> let
> the consumer Pom treat version ranges more as guidance rather than
hard
> requirements. It's a pain if you depend transitiveky on Foo:[1.0] but
> need
> Foo:[1.0.1,1.1) for the critical security fix... Having to run around
> applying excludes is not a good plan... Yes the build should initially
> fail
> if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be
able to
> resolve the conflict for all my consumers (unless they pull in the
> conflict
> again themselves)
>
> On Tuesday 23 August 2016, Fred Cooke <fred.co...@gmail.com> wrote:
>> I still find it a bit off that the original real POM won't always be
>> directly available anymore.
>>
>> Other tools create fake POMs because they *have* to - there's no
other
>> option.
>>
>> I feel like some fidelity would be lost. Diffability would be lost
>> (from a
>> scenario where there's nothing to diff).
>>
>> Unrelated, really, but kind of related: top level deployable artefact
>> deployments, debs, wars, exes, etc. When ranges are in use it'd be
nice
>> to
>> deploy a sort of strict effective pom with fully hard [] versions for
>> all
>> things. This can be achieved in other ways, though.
>>
>> I guess that is to say, don't forget about non-central deployments. I
>> suppose if there's a way to always deploy pom.xml.build through some
>> plugin
>> or configuration or some such, then that's fine with me.
>>
>> On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <herve.bout...@free.fr
>> <javascript:;>>
>>
>> wrote:
>> > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit :
>> > > Fair call re embedded pom, however it's quite convenient to just
>>
>> browse
>>
>> > to
>> >
>> > > it and read.
>> > >
>> > > I've occasionally gone looking for details from poms of artefacts
>>
>> and
>>
>> > found
>> >
>> > > a mess and missing stuff, and been annoyed. It probably wasn't
>>
>> gradle's
>>
>> > > fault, though. Just a sloppy author. If I'm honest I wouldn't
even
>>
>> know
>>
>> > if
>> >
>> > > I've ever consumed a non-maven artefact, certainly none of mine!
:-)
>> > >
>> > > No, I am sure, I have, at least one, and it's an ant one with a
hard
>> >
>> > coded
>> >
>> > > POM that doesn't always reflect the contents of the jar. Yuck.
>>
>> Clearly
>>
>> > not
>> >
>> > > an issue with automated stuff, though.
>> > >
>> > > My only argument now is ease of reading things like project
>>
>> descriptions,
>>
>> > > contributors, SCM details, etc rather than having to unpack the
jar.
>>
>> And
>>
>> > if
>> >
>> > > you do, and end up with two pom.xmls laying around, that's not
nice.
>> >
>> > Better
>> >
>> > > to just start always suffixing one with pom.xml.build or some
such?
>>
>> I
>>
>> > think
>> >
>> > > so, but I haven't thought deeply about it aside from reading this
>>
>> thread.
>>
>> > our consumer pom will be generated from build pom: we can automate
>>
>> copy
>> of
>>
>> > any
>> > information we want, and for sure, I expect to put at least
>>
>> description,
>>
>> > scm
>> > details, issueManagement, license (of course).
>> > In your list, there is only constributors that I was not counting
on
>>
>> it:
>> > but
>> > it's a detailed decision we'll have to make
>> >
>> > for sure, Maven consumer poms, since generated from Maven build
pom,
>>
>> can
>>
>> > have
>> > much more details (and be sure they are accurrate) than build tools
>>
>> that
>>
>> > don't
>> > generate it from data that exists in their original build format
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY
>>
>> <herve.bout...@free.fr
>> <javascript:;>>
>>
>> > > wrote:
>> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>> > > > > That should have separation between builder Pom and consumer
>>
>> Pom.
>> For
>>
>> > > > > packaging=pom we deploy the builder Pom using
classifier=build
>> > > > > *for all other packaging a we do not deploy the builder Pom*.
>> > > > >
>> > > > > I don't like the sound of this. The deployed artefacts should
>>
>> include
>>
>> > > > > the
>> > > > > exact POM in use to build the project, as a reference, even
if
>>
>> under
>>
>> > a
>> >
>> > > > > different name. Yes, they should be in SCM, however down
stream
>>
>> it's
>>
>> > > > useful
>> > > >
>> > > > > to see these even when the SCM is offline or gone or private
or
>> > > > > whatever.
>> > > > > Or did I misunderstand? If so, please clarify?
>> > > >
>> > > > when you consume an artifact not build with Maven, do you get
the
>>
>> full
>>
>> > > > build
>> > > > script?
>> > > > no
>> > > > I know that, as Maven users, we got used to have the build pom
>> >
>> > published
>> >
>> > > > in
>> > > > central: this is now an issue, but we like that
>> > > >
>> > > > notice: the build pom can be injected in the artifact, in
>> >
>> > META-INF/maven,
>> >
>> > > > like
>> > > > it is currently done
>> > > > but I don't see the point in requiring it to be pbulished
>>
>> separately
>> in
>>
>> > > > central: no other build tool does that, and they don't have any
>>
>> issue
>>
>> > with
>> >
>> > > > that (and eventually it's a feature: don't publish internal
>>
>> details
>> you
>>
>> > > > don't
>> > > > really want people to see)
>> > > >
>> > > > Regards,
>> > > >
>> > > > Hervé
>> > > >
>> > > > > On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly <
>> > > > >
>> > > > > stephen.alan.conno...@gmail.com <javascript:;>> wrote:
>> > > > > > On Tuesday 23 August 2016, Paul Benedict
<pbened...@apache.org
>>
>> <javascript:;>>
>>
>> > wrote:
>> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
>> >
>> > c...@schulte.it <javascript:;>
>> >
>> > > > > > > <javascript:;>> wrote:
>> > > > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict:
>> > > > > > > > > POM and a future major version POM? I am hinting at a
>> >
>> > strategy
>> >
>> > > > for
>> > > >
>> > > > > > > > forward
>> > > > > > > >
>> > > > > > > > > compatibility.
>> > > > > > > >
>> > > > > > > > Is forward compatibility really needed/required?
>> > > > > > >
>> > > > > > > I honestly don't know, which is why I am asking. An
answer
>>
>> of
>> "no
>>
>> > > > > > > compatibility" is possible, too.
>> > > > > > >
>> > > > > > > I can completely see the argument that says POMs must be
>> > > > > > > all-parseable-or-nothing -- for the sake of
>>
>> reproducibility. I
>>
>> > > > actually
>> > > >
>> > > > > > > prefer this answer. I think it is sensible to fail a
build
>>
>> when
>>
>> > > > > > > encountering a POM version too advanced. If your client
only
>> > > >
>> > > > supports up
>> > > >
>> > > > > > to
>> > > > > >
>> > > > > > > model 4.0.0, then all artifacts must be specified by
4.0.0
>> >
>> > models,
>> >
>> > > > too.
>> > > >
>> > > > > > > On the other hand, I wanted to give the benefit of the
>>
>> doubt to
>>
>> > the
>> >
>> > > > > > > opposite argument. At least one person spoke up and said
>>
>> it's
>>
>> > > > > > unacceptable
>> > > > > >
>> > > > > > > to fail a build on configuration you don't understand.
Well,
>> >
>> > that's
>> >
>> > > > an
>> > > >
>> > > > > > > interesting argument, too. That person doesn't want to
tank
>>
>> the
>>
>> > > > > > > build
>> > > > > > > for
>> > > > > > > the 1% of configuration that can't be understood.... but
I
>>
>> fail
>>
>> > to
>> >
>> > > > see
>> > > >
>> > > > > > > an
>> > > > > > > escape hatch here. If a client can't understand what's
being
>> > > >
>> > > > specified,
>> > > >
>> > > > > > > then what else can be done but fail?
>> > > > > >
>> > > > > > Strip the dependencies a and let the user fix up manually
>>
>> (ideally
>>
>> > by
>> >
>> > > > > > logging a warning that you are consuming a dependency
using a
>>
>> newer
>>
>> > > > > > modelVersion)
>> > > > > >
>> > > > > > Everyone forgets that the 4.0.0 ship has sailed already,
so we
>> >
>> > have to
>> >
>> > > > > > deploy best-effort 4.0.0 poms
>> > > > > >
>> > > > > > Now I say that 3.4 should not have a new modelVersion but
>>
>> what it
>>
>> > > > could do
>> > > >
>> > > > > > is be more forgiving of newer modelVersions or try and
>>
>> download
>> and
>>
>> > > > use an
>> > > >
>> > > > > > XSLT to convert newer modelVersions to 4.0.0 (while
logging a
>> >
>> > warning)
>> >
>> > > > > > with
>> > > > > > option flags to allow failing the build if XSLT had to be
>>
>> applied
>>
>> > > > > > So let's bump the modelVersion in Maven 5.0.0 (there is no
>>
>> Maven
>>
>> > 4.x
>> >
>> > > > let's
>> > > >
>> > > > > > align on the modelVersion)
>> > > > > >
>> > > > > > That should have separation between builder Pom and
consumer
>>
>> Pom.
>>
>> > For
>> >
>> > > > > > packaging=pom we deploy the builder Pom using
classifier=build
>>
>> for
>>
>> > all
>> >
>> > > > > > other packaging a we do not deploy the builder Pom.
>> > > > > >
>> > > > > > We deploy a *best effort* conversion of the consumer Pom to
>> > > >
>> > > > modelVersion
>> > > >
>> > > > > > 4.0.0 without a classifier and the consumer Pom gets
deployed
>>
>> as
>>
>> > > > > > classifier
>> > > > > > consumer.
>> > > > > >
>> > > > > > The consumer Pom format allows for XSLT to transform to a
>>
>> parsable
>>
>> > > > syntax,
>> > > >
>> > > > > > if transform is required we log a warning (or fail the
build
>>
>> if
>> the
>>
>> > > > > > builder
>> > > > > > Pom indicates strict modelVersion adherence)
>> > > > > >
>> > > > > > So yeah maven 5.x will be able to parse dependencies with
>> >
>> > modelVersion
>> >
>> > > > 6.x
>> > > >
>> > > > > > while logging warnings that the user may not have the
correct
>> > > >
>> > > > dependency
>> > > >
>> > > > > > tree. That is IMHO acceptable forward compatibility
>> > > > > >
>> > > > > > HTH
>> > > > > >
>> > > > > > -Stephen
>> > > > > >
>> > > > > > Ps I'm really hoping someone has a less crappy solution
that
>> >
>> > this...
>> >
>> > > > But I
>> > > >
>> > > > > > believe this is actually *a* solution... And prior to this
I
>>
>> have
>>
>> > not
>> >
>> > > > seen
>> > > >
>> > > > > > any solution
>> > > > > >
>> > > > > > > Cheers,
>> > > > > > > Paul
>> > > > > >
>> > > > > > --
>> > > > > > Sent from my phone
>> > > >
>> > > > ------------------------------------------------------------
>>
>> ---------
>>
>> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>
>> <javascript:;>
>>
>> > > > For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> <javascript:;>
>>
>> >
---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>
>> <javascript:;>
>>
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> <javascript:;>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
