>> Using MRP as I described would not confuse any tool >Depends on the tool. The problem would be that a source checkout at the commit/tag would, if loaded as a project rather than a deployed artifact, have a version different from the artifact. (Also true in JEP-229 components by default, but you can simply pass a fixed and unconditional `-Dset.changelist` and the resulting version is deterministic.)
I beleive we are not understanding each other. if a tool would be broken by what I am suggesting then it is a broken tool period in that it would have exactly the same issue with a project released today by running "mvn release:prepare release:perform" the tag contains the fully resolved pom you are still tagging the commit "[maven-release-plugin] prepare release project-a.bcd" the only difference is that these commits never appear on the mainline branch (master) and are only in the tag. thus this would actually be in a better state than JEP-229 currently is. > And as mentioned previously <https://github.com/jenkins-infra/jenkins-maven-cd-action/pull/14#issuecomment-986806625>, if you drop that constraint, you can flatten and trivially `deploy` any version string you like (and tag it) without going through all the complexity of MRP. The only reason to deal with MRP is to get the two junk commits that rewrite `<version>` (and `<tag>`) in a tagged SCM commit. but we do not want to drop that containt - that is the biggest issue we have with JEP229 currently and I am proposiing a solution does not have the "junk commits" on master, nor has the "tagged sources are junk" issue. happy to jump on a Hangout if you want further explanation. /James On Tuesday, December 14, 2021 at 11:50:10 PM UTC Jesse Glick wrote: > On Tue, Dec 14, 2021 at 6:04 PM James Nord <james...@gmail.com> wrote: > >> the flatten plugin confuses tools > > > Which? I think we have ironed out any problems as lots of components have > picked up JEP-305. Even seems to work fine on BOMs; the last things I am > hesitant > <https://github.com/jenkins-infra/repository-permissions-updater/pull/2223#issue-1069743433> > > to flatten without more careful testing are parent POMs. > > Using MRP as I described would not confuse any tool >> > > Depends on the tool. The problem would be that a source checkout at the > commit/tag would, if loaded as a project rather than a deployed artifact, > have a version different from the artifact. (Also true in JEP-229 > components by default, but you can simply pass a fixed and unconditional > `-Dset.changelist` and the resulting version is deterministic.) > > And as mentioned previously > <https://github.com/jenkins-infra/jenkins-maven-cd-action/pull/14#issuecomment-986806625>, > > if you drop that constraint, you can flatten and trivially `deploy` any > version string you like (and tag it) without going through all the > complexity of MRP. The only reason to deal with MRP is to get the two junk > commits that rewrite `<version>` (and `<tag>`) in a tagged SCM commit. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/57d949f7-842c-47d0-baee-1a5e31061fc3n%40googlegroups.com.
