yes, we'll need to find clear terms for each concept: I now understand what you meant by consumer pom, which is not what I meant :)
there are 2 ideas: - publishing classical Maven pom without build information (pom generated by flatten plugin or alike), to be able to add new build features in Maven pom model version 5 without wreaking havoc in Central for the whole consumer eco- system (Maven2 & 3 and other build tools) - creating a new descriptor format for repositories to be able to consume artifacts more efficiently The good news is that IMHO, these ideas are complementary: we just need to solve the name conflict regarding "comsumer pom". Regards, Hervé Le jeudi 25 août 2016 21:14:09 Robert Scholte a écrit : > The current pom will still be there, always, consumer pom is an extra file > for more effective artifact resolution. So yes, that's why I suggested > consumer dom to ensure it is not confused with the current pom. > > Robert > > On Thu, 25 Aug 2016 20:16:08 +0200, Chas Honton <c...@honton.org> wrote: > > I use the current Pom to automate checking license policy and checking > > owasp database for known security flaws. The scm and website metadata is > > also very useful. Automated download of source for debugging is > > essential. As a consumer, I don't want to lose these abilities. > > > > Chas > > > >> On Aug 25, 2016, at 10:11 AM, Paul Benedict <pbened...@apache.org> > >> wrote: > >> > >> Is it really correct to call a dependency-only (more of less) file a > >> POM if > >> it ceases to contain project information? A project is (or should be!) > >> synonymous with a build. Is that why someone referred to it as a DOM? A > >> DOM > >> makes way more sense to me than overloading the usage of POM and > >> calling it > >> a "consumer POM" > >> > >> Cheers, > >> Paul > >> > >> On Thu, Aug 25, 2016 at 11:53 AM, Robert Scholte <rfscho...@apache.org> > >> > >> wrote: > >>> For both the flattened-pom and consumer-pom the idea is to remove build > >>> related information. Most of it is only used during build. > >>> The question is: is there other information which should be added? > >>> e.g. In case of JARs: the major version number of the class file format > >>> being used. Is it interesting to know this BEFORE downloading the jar? > >>> And > >>> if so, there should be a possibility to make choices based on that > >>> information. The choice-option doesn't exist and would make it all too > >>> complex. > >>> I would say that it is indeed all about dependencies. > >>> > >>> thanks, > >>> Robert > >>> > >>> > >>> On Thu, 25 Aug 2016 18:25:36 +0200, Paul Benedict > >>> <pbened...@apache.org> > >>> wrote: > >>> > >>> The only (minor?) issue I have with the term "consumer POM" is that it > >>> > >>>> implies one type of consumption. What is the kind of consumption we're > >>>> addressing -- is it merely the GAV and dependencies? > >>>> > >>>> Cheers, > >>>> Paul > >>>> > >>>> On Thu, Aug 25, 2016 at 3:34 AM, Robert Scholte <rfscho...@apache.org> > >>>> wrote: > >>>> > >>>> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly < > >>>> > >>>>> stephen.alan.conno...@gmail.com> wrote: > >>>>>> 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'd prefer consumer pom too, but it has led to confusion due to the > >>>>> assumption that consumer pom and flattened pom are the same thing. > >>>>> To me > >>>>> it > >>>>> makes sense to consider a new fileformat for the consumer pom which > >>>>> matches > >>>>> better the requirements. And yes, the "provides" would fit here. > >>>>> > >>>>> > >>>>> > >>>>> 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: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 < > >>>>>>> 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 > >>>>>>> > >>>>>>> > >>>>>>> -------------------------------------------------------------------- > >>>>>>> - > >>>>> > >>>>> 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 > > --------------------------------------------------------------------- > 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
