On 24 August 2016 at 04:50, Robert Scholte <rfscho...@apache.org> wrote:
> I realized last ApacheCon that I wasn't clear about my definiton of the > consumer-pom. > I don't think it should be a flattened pom with only the dependency > information. Instead it shouldn't be a pom (matching the pom.xsd) at all. > I am not in disagreement, but as a concept the name "consumer pom" has more traction. I see the builder pom as probably ending up not even being XML at all. 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:jboss-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 < > 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 > >
