[VOTE] Release Maven Doxia version 2.0.0-M7
Hi, we solved 2 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230=12353309 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIA%20AND%20resolution%20%3D%20Unresolved Staging repo: https://repository.apache.org/content/repositories/maven-1967/ https://repository.apache.org/content/repositories/maven-1967/org/apache/maven/doxia/doxia/2.0.0-M7/doxia-2.0.0-M7-source-release.zip Source release checksum(s): doxia-2.0.0-M7-source-release.zip sha512: c353c1148e73a392f425245ffc094bb03f30e364b928f10e62747750006514b319a05b0871272695997513199fee701da77e0d98201a0874aa637ff376768452 Staging site: https://maven.apache.org/doxia/doxia-archives/doxia-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. IMPORTANT: This is expected to be the last milestone before 2.0.0 GA. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] POM model version
Le mer. 21 juin 2023 à 09:27, Hervé Boutemy a écrit : > Le dimanche 18 juin 2023, 21:49:41 CEST Guillaume Nodet a écrit : > > Le dim. 18 juin 2023 à 21:14, Hervé Boutemy a > > > > écrit : > > > I now understand our divergence: you implicitely use Maven 4 with some > > > updates > > > already done on xsd versions that I did not know about, and I don't yet > > > understand what has already be done on build vs consumer POM > > > transformation > > > > > > First, having some feedback from people on the idea of using plugin > > > execution > > > priority would be useful, because even before diving into > implementation > > > details, this approach is to be accepted. > > > > > > If devs agree on the introduction of basic priority, we have 3 ways to > > > implement its introduction: > > > > > > 1. Maven 3 way = add as an XML attribute: > > > Fully compatible with current Maven Central conventions, no need to > change > > > anything > > > done in https://github.com/apache/maven/pull/1173 > > > as you can see, it's a modification of 2 lines + some documentation > > > > Yes, but again, you say it's compatible because you add an attribute vs > > element. This isn't supported by any facts so far: in my mind, and in > the > > model parser used by maven, and in the xml schema spec, there's no > > difference between adding an attribute and adding an element. With that > in > > mind, I find this solution (adding an attribute vs adding an element) > very > > inconsistent (because we don't use attributes in the schema but in a very > > few places) with no real benefits. And yes, it's two lines, but that's an > > abuse of the xml schema, because we will have to publish a newly modified > > schema while saying it's the same as before. How will people actually > know > > if they have the correct one or not ? > please listen: it is a convention at Maven level defined for Maven 3.5.0 > (2017), based on the fact that we don't know the code that consumes Maven > Central > You're right: not facts based on Maven core, a compromise, not clean, you > were > not there, you just need to accept that this is history, it exists, has > reasons, is not fully stupid even if far from perfect, and you can't > change it > just at Maven core level. > The benefit is not for us on Maven core, but for the many unknown code > that > uses pom.xml from Maven Central for 20 years > > > We're using checksums and all sort > > of things for artifacts, but we'd overwrite an existing published schema > in > > a blink ? We don't even want to remove tags of unpublished releases and > we > > wouldn't be scared about overwriting a schema ? and I'm not being > > sarcastic, I do really find that dodgy and weird that we would want to go > > that way. > It's a pure technical "purity" reaction that I fully respect: yes, this > compromise is dodgy from a technical point of view, but it proved to work > (it > did not break the Maven Central ecosystem consuming *.pom nor the Maven > users > writing pom.xml). > This convention has been defined in 2017, after many years searching how > to > evolve without breaking our Maven Central consumer ecosystem, with the > level > of unknown involved into judging what can reasonably be done. > This step lead later to build/consumer idea, and 2 steps: > 1. update build content, but not consumer = what is called Maven 4 > 2. update consumer content (ie in Maven Central) = what is called Maven 5 > = > the real target that will permit to solve our management of unknown POM v4 > consumers land that won't disappear and that we don't want to break. > If we introduce now some updates that were named Maven 5, I'm just trying > to > make sure we adapt our energy on sharing and checking to the increased > risk > on the whole ecosystem: as you already saw, there are edge cases at least > on > parent POMs that need to be published to Maven Central > > > > > > tested with a sample project: > > > https://github.com/hboutemy/MNG-7804-plugin-execution-priority > > > > > > 2. the Maven 5 way: add a new XML element, and manage the fact that it > > > will > > > change all the expectations from a Maven Central perspective > > > = what we were supposed to do in the future, once people have some > > > experience > > > with Maven 4 and build vs consumer POM, plus all what is required to be > > > added > > > as constraints at maven Central level > > > > What I'm trying to say is that I don't understand why we'd need maven 4 + > > maven 5. The consumer POM and the definition of a new schema are two > > separate things and could be both done in maven 4. Also, I don't think > it > > has been described exactly when/how the POM 5 would be used. That's what > > I'm trying to do in this discussion (if we can just forget about the > > numbers, because they have again no real meaning). > Maven 5 term is about making more evolution to the POM schema than adding > a > few attributes only: this has been the convention until now. > And one key basic reason
Re: [DISCUSS] POM model version
Le dimanche 18 juin 2023, 21:49:41 CEST Guillaume Nodet a écrit : > Le dim. 18 juin 2023 à 21:14, Hervé Boutemy a > > écrit : > > I now understand our divergence: you implicitely use Maven 4 with some > > updates > > already done on xsd versions that I did not know about, and I don't yet > > understand what has already be done on build vs consumer POM > > transformation > > > > First, having some feedback from people on the idea of using plugin > > execution > > priority would be useful, because even before diving into implementation > > details, this approach is to be accepted. > > > > If devs agree on the introduction of basic priority, we have 3 ways to > > implement its introduction: > > > > 1. Maven 3 way = add as an XML attribute: > > Fully compatible with current Maven Central conventions, no need to change > > anything > > done in https://github.com/apache/maven/pull/1173 > > as you can see, it's a modification of 2 lines + some documentation > > Yes, but again, you say it's compatible because you add an attribute vs > element. This isn't supported by any facts so far: in my mind, and in the > model parser used by maven, and in the xml schema spec, there's no > difference between adding an attribute and adding an element. With that in > mind, I find this solution (adding an attribute vs adding an element) very > inconsistent (because we don't use attributes in the schema but in a very > few places) with no real benefits. And yes, it's two lines, but that's an > abuse of the xml schema, because we will have to publish a newly modified > schema while saying it's the same as before. How will people actually know > if they have the correct one or not ? please listen: it is a convention at Maven level defined for Maven 3.5.0 (2017), based on the fact that we don't know the code that consumes Maven Central You're right: not facts based on Maven core, a compromise, not clean, you were not there, you just need to accept that this is history, it exists, has reasons, is not fully stupid even if far from perfect, and you can't change it just at Maven core level. The benefit is not for us on Maven core, but for the many unknown code that uses pom.xml from Maven Central for 20 years > We're using checksums and all sort > of things for artifacts, but we'd overwrite an existing published schema in > a blink ? We don't even want to remove tags of unpublished releases and we > wouldn't be scared about overwriting a schema ? and I'm not being > sarcastic, I do really find that dodgy and weird that we would want to go > that way. It's a pure technical "purity" reaction that I fully respect: yes, this compromise is dodgy from a technical point of view, but it proved to work (it did not break the Maven Central ecosystem consuming *.pom nor the Maven users writing pom.xml). This convention has been defined in 2017, after many years searching how to evolve without breaking our Maven Central consumer ecosystem, with the level of unknown involved into judging what can reasonably be done. This step lead later to build/consumer idea, and 2 steps: 1. update build content, but not consumer = what is called Maven 4 2. update consumer content (ie in Maven Central) = what is called Maven 5 = the real target that will permit to solve our management of unknown POM v4 consumers land that won't disappear and that we don't want to break. If we introduce now some updates that were named Maven 5, I'm just trying to make sure we adapt our energy on sharing and checking to the increased risk on the whole ecosystem: as you already saw, there are edge cases at least on parent POMs that need to be published to Maven Central > > > tested with a sample project: > > https://github.com/hboutemy/MNG-7804-plugin-execution-priority > > > > 2. the Maven 5 way: add a new XML element, and manage the fact that it > > will > > change all the expectations from a Maven Central perspective > > = what we were supposed to do in the future, once people have some > > experience > > with Maven 4 and build vs consumer POM, plus all what is required to be > > added > > as constraints at maven Central level > > What I'm trying to say is that I don't understand why we'd need maven 4 + > maven 5. The consumer POM and the definition of a new schema are two > separate things and could be both done in maven 4. Also, I don't think it > has been described exactly when/how the POM 5 would be used. That's what > I'm trying to do in this discussion (if we can just forget about the > numbers, because they have again no real meaning). Maven 5 term is about making more evolution to the POM schema than adding a few attributes only: this has been the convention until now. And one key basic reason was to match the POM version with Maven version to clarify for end users: "POM v4 for Maven 3&4, POM v5 for Maven 5" is the motto You're right that what you're trying to do with only one element addition does not seem to deserve the 5 from core
