Rather IMHO it will end up being a DSL that is easy to author and
not
verbose... and certainly not XML
So the consumer pom should be stripped back to include two sets of
information:
* dependencies - we are mostly familiar with this... though we may
not
expose all the scopes... depends on how we think about things and
how we
view scopes moving forward
* provides - this is vitally important IMHO and not handled
currently.
To understand provides we have to look at things like JavaEE (but
the
concept has general utility... though I suspect only for about
10-25% of
projects)
If I have a project that says: provides
javax.servlet:servlet-api:3.1
then
that is saying that my project is providing the equivalent content
as in
javax.servlet:servlet-api:3.1 so for example
org.jboss.spec.javax.servlet:
jboss-servlet-api_3.1_spec:1.0.0.Final would say
javax.servlet:servlet-api:3.1
When resolving the dependency tree, maven then knows that any
transitive
requirement for javax.servlet:servlet-api:3.1 has already been met
by my
direct dependency on org.jboss.spec.javax.servlet:j
boss-servlet-api_3.1_spec
:1.0.0.Final if we have a direct dependency on
org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
javax.servlet:servlet-api:3.1) then Maven can report an error and
fail
the
build due to dependency conflict.
There are lots of other improvements we can add, but to start we
need to
have a way to declare when a project includes duplicate content of
another
artifact. Convention will be required to make this work correctly...
perhaps we can even introduce a new project type that provides
needs to
point at so that a provides has to point at an "empty" specification
project...
Finally, for the consumer pom refactoring I believe we need to
address
architecture specific artifacts as these are a sort of implicit
provides.
Maybe it should be called something like consumer-dom (dependency
object
model, though dom is confusing...).
It should be the most fast and efficient way to resolve the
dependency
tree. That means it should do less roundtrips like Maven must do do
right
now: for every dependency download the pom, for all transitive
dependencies
download all poms, etc.
Why can't it be a pom? I'd like to add the (file)extension too.
Otherwise
Maven needs to initialize the matching ArtifactHandler and
translate
the
type to the proper extension.
I think the consumer pom needs to embed some of the artifact handler
information for it self as otherwise non-maven tooling cannot be
expected
to understand those details... also we should be making the
consumer pom
both Maven and Java agnostic... but this is a grand problem alright!
The pom doesn't have room for this.
I saw the whole flattened pom experiment as mostly a waste of time
for
the
consumer pom effort as I envision the consumer pom not looking
anything
like the current pom at all... but it is a project model...
Oh and the consumer pom should include information for the
side-artifacts
(which would help with reusing tests as we could attach the test
dependencies to the test artifact details in the consumer pom)
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 <
[email protected]> 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 <[email protected]>
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 <
[email protected]
<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 <
[email protected]
<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 <
[email protected] <javascript:;>> wrote:
On Tuesday 23 August 2016, Paul Benedict <
[email protected]
<javascript:;>>
wrote:
On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <
[email protected] <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: [email protected]
<javascript:;>
For additional commands, e-mail: [email protected]
<javascript:;>
------------------------------------------------------------
---------
To unsubscribe, e-mail: [email protected]
<javascript:;>
For additional commands, e-mail: [email protected]
<javascript:;>
------------------------------------------------------------
---------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
