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:;>
>
>
