Re: [VOTE] Release Apache Parent POM version 22
+1 On 5-1-2020 18:45:55, Hervé BOUTEMY wrote: Hi, We solved N issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12343925=Text https://github.com/apache/maven-apache-parent/compare/apache-21...apache-22 Staging repo: https://repository.apache.org/content/repositories/orgapacheapache-1017/ https://repository.apache.org/content/repositories/orgapacheapache-1017/org/apache/apache/22/apache-22-source-release.zip Source release checksum(s): apache-22-source-release.zip sha512: 180896d6ada20d029203791d594f657e3874730eaa6ebf5288325766728fee4bb55e1dc8666207ed9d88e735edfe1e3e660492d234d248f5202575edbeb5b7a9 Staging site: https://maven.apache.org/pom-archives/asf-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at least 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Parent POM version 22
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 05.01.20 18:45, Hervé BOUTEMY wrote: Hi, We solved N issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12343925=Text https://github.com/apache/maven-apache-parent/compare/apache-21...apache-22 Staging repo: https://repository.apache.org/content/repositories/orgapacheapache-1017/ https://repository.apache.org/content/repositories/orgapacheapache-1017/org/apache/apache/22/apache-22-source-release.zip Source release checksum(s): apache-22-source-release.zip sha512: 180896d6ada20d029203791d594f657e3874730eaa6ebf5288325766728fee4bb55e1dc8666207ed9d88e735edfe1e3e660492d234d248f5202575edbeb5b7a9 Staging site: https://maven.apache.org/pom-archives/asf-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at least 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Parent POM version 22
+1 (non binding) Enrico Il dom 5 gen 2020, 19:48 Mark Struberg ha scritto: > +1 > > LieGrue, > strub > > > > Am 05.01.2020 um 18:45 schrieb Hervé BOUTEMY : > > > > Hi, > > > > We solved N issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12343925=Text > > > > > https://github.com/apache/maven-apache-parent/compare/apache-21...apache-22 > > > > Staging repo: > > https://repository.apache.org/content/repositories/orgapacheapache-1017/ > > > https://repository.apache.org/content/repositories/orgapacheapache-1017/org/apache/apache/22/apache-22-source-release.zip > > > > Source release checksum(s): > > apache-22-source-release.zip sha512: > 180896d6ada20d029203791d594f657e3874730eaa6ebf5288325766728fee4bb55e1dc8666207ed9d88e735edfe1e3e660492d234d248f5202575edbeb5b7a9 > > > > Staging site: > > https://maven.apache.org/pom-archives/asf-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > > > > > - > > 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 > >
Re: [DISCUSS] Merging small plugins
Hi, On 05.01.20 19:33, Benjamin Marwell wrote: Hi, thanks for sharing your idea. While I can see the benefits, I also do see some drawbacks. If only one part of the plugin has an invalid state, it will be impossible to create a release. Also, the Unix philosophy (make a tool which does one thing well) would be broken. Yes very good philosophy... If voting is a drawback for small plugins, maybe change the voting system for smaller plugins instead? Than I would ask: What is a "small" plugin? Not really I just want to note that... As a new contributer, I found it easy to find a plugin I could contribute to. That would not have been that easy if there was one repository with one plugin that does a lot of things. I'd stick to the current layout for this reason. Maybe let's talk about voting instead? The VOTEing has a very good background see https://www.apache.org/foundation/voting.html but if we might need we could change it.. > And maybe talk about more automatisms for updating the poms and dependencies, maybe even use a github bot? Automated updates for dependencies is a very good idea.. I already have done a lot to more automate my tooling... The final step is check which dependencies could be updated...and the rest can be automated as I already did... At the moment I only call my script "createdependencyupgradeissue.sh" from the appropriate plugin/lib with supplemental explanation (This could be automated)..This will create a branch for the change / JIRA Issue etc. I only need to manually change the version of the dependency...and wait for the successful build and afterwards "gitmergeandclean.sh" which merges the branch, fixes the JIRA issue etc. So the interesting part is: Identify which dependency has to be updated? Something like "versions:display-dependency-updates" which can deliver the needed informationI think that might a way to go or maybe GitHub DependendaBot... On Sun, 5 Jan 2020, 17:31 Enrico Olivelli, wrote: Hi community, I just want to share this idea, maybe it is silly but why not talk about it. We have tens of plugins, most of them are rarely updated and released. So it happens that users contribute patches in order to fix real problems but they have to wait an indefinite time before seeing the fix released, because we are not doing a release just for one issue. Another problem is that making a release is quite an heavyweight task: - update parent pom, update dependencies This is independant of the release. - stage a release That's not the real problem. The signing of the artifacts is the part which is the issue cause the rest could be automated via Jenkins/WhatEver...but the Problem is related to the private PGP key to sign the artifacts. - make the VOTE, wait, make at least 3 PMC vote.. Yes ... - finalize... Could be done via button ...(Need some work, but doable)... Also creating the announcement mail etc. What about creating some maven-ext-plugins git repository with a parent and reactor pom and move all of those plugins that are really never released? I am thinking to side plugins like jdeps, checkstyle, pmd, enforcernot compiler, assembly, surefire... If we merge them into one single code base we can: - have releases for all of them, even with some minimal (but blocker) fix - save time and resources (one committer does the work once and PMC votes only once, and we release 10 or more plugins...) Which means one plugin could block all others. We have some plugins like maven-compiler, maven-shade, maven-pmd which needed to be released with each Java version ...other are not that problem.. We could even think to time based release schedule How long could be the time between the releases? days, weeks, months? I image the big work you did for splitting all of the 100 git repositories from svnbut I think this move can give more vitality to the project We would have to think about jira, websitesI know it won't be easy Best regards Enrico - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Merging small plugins
> We have tens of plugins, most of them are rarely updated and released ... is the key problem you're trying to solve right? Team to actively process issues and PRs and push releases minor releases efficiently is the real wish, right?
Re: [VOTE] Release Apache Parent POM version 22
+1 LieGrue, strub > Am 05.01.2020 um 18:45 schrieb Hervé BOUTEMY : > > Hi, > > We solved N issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12343925=Text > > https://github.com/apache/maven-apache-parent/compare/apache-21...apache-22 > > Staging repo: > https://repository.apache.org/content/repositories/orgapacheapache-1017/ > https://repository.apache.org/content/repositories/orgapacheapache-1017/org/apache/apache/22/apache-22-source-release.zip > > Source release checksum(s): > apache-22-source-release.zip sha512: > 180896d6ada20d029203791d594f657e3874730eaa6ebf5288325766728fee4bb55e1dc8666207ed9d88e735edfe1e3e660492d234d248f5202575edbeb5b7a9 > > Staging site: > https://maven.apache.org/pom-archives/asf-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > > - > 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
Re: [DISCUSS] Merging small plugins
Hi, thanks for sharing your idea. While I can see the benefits, I also do see some drawbacks. If only one part of the plugin has an invalid state, it will be impossible to create a release. Also, the Unix philosophy (make a tool which does one thing well) would be broken. If voting is a drawback for small plugins, maybe change the voting system for smaller plugins instead? As a new contributer, I found it easy to find a plugin I could contribute to. That would not have been that easy if there was one repository with one plugin that does a lot of things. I'd stick to the current layout for this reason. Maybe let's talk about voting instead? And maybe talk about more automatisms for updating the poms and dependencies, maybe even use a github bot? On Sun, 5 Jan 2020, 17:31 Enrico Olivelli, wrote: > Hi community, > I just want to share this idea, maybe it is silly but why not talk about > it. > We have tens of plugins, most of them are rarely updated and released. > > So it happens that users contribute patches in order to fix real problems > but they have to wait an indefinite time before seeing the fix released, > because we are not doing a release just for one issue. > > Another problem is that making a release is quite an heavyweight task: > - update parent pom, update dependencies > - stage a release > - make the VOTE, wait, make at least 3 PMC vote.. > - finalize... > > What about creating some maven-ext-plugins git repository with a parent and > reactor pom and move all of those plugins that are really never released? > > I am thinking to side plugins like jdeps, checkstyle, pmd, enforcernot > compiler, assembly, surefire... > > If we merge them into one single code base we can: > - have releases for all of them, even with some minimal (but blocker) fix > - save time and resources (one committer does the work once and PMC votes > only once, and we release 10 or more plugins...) > We could even think to time based release schedule > > > I image the big work you did for splitting all of the 100 git repositories > from svnbut I think this move can give more vitality to the project > > We would have to think about jira, websitesI know it won't be easy > > Best regards > Enrico >
Re: [DISCUSS] Merging small plugins
I understand the issue you're trying to solve, but I don't think it is the right solution. To me a plugin contains a number of goals that are related to each other. If there are issues, they are very easy to pinpoint. If we start with with a monolithic plugin, you'll likely introduce more issues. Suppose one goal has that feature you're wating for, but you can't use it because of a bug in another goal. Also be aware that the number of releases says nothing about the plugin. It might be (close to) finished, hence no reason to release it. To me there are a couple of things we can do: - give plugins to there related library ( checkstyle, PMD, Antrun, Patch(?), PDF(?) ) - move plugins to mojohaus (but they suffer with the same issues) - archive plugins (I've already done that last year) - attract more contributors. thanks, Robert On 5-1-2020 17:31:13, Enrico Olivelli wrote: Hi community, I just want to share this idea, maybe it is silly but why not talk about it. We have tens of plugins, most of them are rarely updated and released. So it happens that users contribute patches in order to fix real problems but they have to wait an indefinite time before seeing the fix released, because we are not doing a release just for one issue. Another problem is that making a release is quite an heavyweight task: - update parent pom, update dependencies - stage a release - make the VOTE, wait, make at least 3 PMC vote.. - finalize... What about creating some maven-ext-plugins git repository with a parent and reactor pom and move all of those plugins that are really never released? I am thinking to side plugins like jdeps, checkstyle, pmd, enforcernot compiler, assembly, surefire... If we merge them into one single code base we can: - have releases for all of them, even with some minimal (but blocker) fix - save time and resources (one committer does the work once and PMC votes only once, and we release 10 or more plugins...) We could even think to time based release schedule I image the big work you did for splitting all of the 100 git repositories from svnbut I think this move can give more vitality to the project We would have to think about jira, websitesI know it won't be easy Best regards Enrico
Re: Multiple executions of Maven with a single run
If you want to execute a plugin goal apart from a lifecycle, then I think it should be for only one module. So I'd expect the call more to be like -pl module -am That said, if you know you want to execute this goal for 1 specific module, I would like to be able to start from that pom and run "mvn verify do:something -am". With -am you trigger Maven to include all modules below the .mvn folder (the existence of this folder will be a requirement). And for Maven 5 or 6 "mvn do:something" might be all you need. I'm not sure if there's already a JIRA issue for it, but it feels more natural: go to the specific module and run the plugin goal from there. Maven can get all the requirement stuff from there. thanks, Robert On 5-1-2020 17:31:17, Enrico Olivelli wrote: Hello, Sometimes it happens that you have to launch twice Maven to: - build a whole reactor project (warmup) - run some specific mojo only a selection of modules mvn clean install -DskipTests -Dmaven.repo.local=tmprepo mvn do:something -pl module1,module1-Dmaven.repo.local=tmprepo I think that in the general case there is no way to do this with one single execution of Maven, for instance from CI. I am thinking about a simple enhancement to workaround this problem: We can let Maven executable to accept a list of command line execution arguments and loop executing the list, halting at the first failure
[VOTE] Release Apache Parent POM version 22
Hi, We solved N issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12343925=Text https://github.com/apache/maven-apache-parent/compare/apache-21...apache-22 Staging repo: https://repository.apache.org/content/repositories/orgapacheapache-1017/ https://repository.apache.org/content/repositories/orgapacheapache-1017/org/apache/apache/22/apache-22-source-release.zip Source release checksum(s): apache-22-source-release.zip sha512: 180896d6ada20d029203791d594f657e3874730eaa6ebf5288325766728fee4bb55e1dc8666207ed9d88e735edfe1e3e660492d234d248f5202575edbeb5b7a9 Staging site: https://maven.apache.org/pom-archives/asf-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at least 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Updating the apache parent to automatically clean before performing a release?
Hi Herve, he'll only get the same content if everything is done right ... unfortunately for example the IoTDB project had to re-do quite a number of RCs as they were still not 100% doing things the maven way. In PLC4X we just had to cancel a release of a sub-project due to the maven-wrapper.jar being packaged in. There were tests writing things outside the target directory, which they were manually excluding. The maven-wrapper.jar keeps on being packaged by the default apache source assembly. Sometimes GIT excluded temp files are packaged. Only by running the release in the target/checkout directory you can be 100% sure it's a clean structure you're packaging. I know that most problems are due to people not doing things the official "maven way" (TM) ... but I have to admit being involved in a lot of projects, if we could ensure some of the common pitfalls don't have such a severe impact, we could help a lot of projects. Chris Am 05.01.20, 18:33 schrieb "Hervé BOUTEMY" : notice that with Reproducible Builds being active by default, the source archive is reproducible and RM will get the same content in both locations There is only the .asc signature file that contains a different timestamp I'm just launching the long overdue Apache Parent 22 vote that will enable Reproducible Builds by default, we'll see if a new release will be ready soon Regards, Hervé Le dimanche 5 janvier 2020, 14:41:37 CET Christofer Dutz a écrit : > Hi Robert, > > I would be more than happy to assist with making releases with maven easier > for Apache projects ... So if you give me a little update on what needs to > be done, I might be able to spare some time and work on this. > But using the files from the prepare is the issue I'm trying to address ... > the perform build is a clean checkout of the tagged version. The clean > checkout ensures the build is 100% clean ... things like packing in > test-results, packing in maven-wrapper jars etc. only happens because the > source distribution is not built in a clean environment. > I would love if it was possible to extend questions the release-prepare > plugin asks for ... so if it would ask for a RC number, we could add a > call to the scm:checkin goal in the deploy phase of a release-perform build > as part of the "apache-release" profile. The only piece of information > that’s missing, would be the release-candidate number. > > Chris > > > > Am 05.01.20, 14:07 schrieb "Robert Scholte" : > > ASF deserves a customized release strategy, which is now possible with > MRELEASE-956 My idea is that during "prepare" the plugin should upload > several files to the ASF dist folder besides the tagging. During "perform" > it should use these files instead of the tag in SCM (because these files > are the official releases, not the tag). > Just waiting for someone to pick it up. > > thanks, > Robert > > > [1] https://jira.apache.org/jira/browse/MRELEASE-956 > On 5-1-2020 11:28:22, Christofer Dutz > wrote: Hi all, > > I just wanted to suggest something I have noticed a lot of Apache > projects were doing wrong. Especially when unexperienced RMs are doing the > releases. > Several times now after doing a release, the RMs have uploaded the > source bundles from “target” to the SVN. However they should have uploaded > the “target/checkout/target”. It is just too tempting to upload the > versions left over from the release:prepare step as they too have the > release version. > Usually this wouldn’t be a problem and I guess this has happened quite > often in the past. The thing is with the adoption of the maven-wrapper we > can unfortunately see when something’s going wrong. In this case there is > a difference. The source bundles from the prepare step then usually contain > the ./mvn/maven-wrapper.jar … which is usually my indicator for instantly > knowing what went wrong. The version in the target/checkout simply couldn’t > contain this file. > From the discussions with the reproducible builds I learned that you can > define pre and post actions to the prepare and perform steps. So how about > adding a pre-perform action that simply cleans the target directory? > I guess updating the default assembly to exclude the jar and class files > in the “./mvn” directory could cure some symptoms, but people would still > upload the wrong file. > I think this could prevent a lot of RCs being -1ed by Justin ;-) > > > Chris > > -
Re: Updating the apache parent to automatically clean before performing a release?
notice that with Reproducible Builds being active by default, the source archive is reproducible and RM will get the same content in both locations There is only the .asc signature file that contains a different timestamp I'm just launching the long overdue Apache Parent 22 vote that will enable Reproducible Builds by default, we'll see if a new release will be ready soon Regards, Hervé Le dimanche 5 janvier 2020, 14:41:37 CET Christofer Dutz a écrit : > Hi Robert, > > I would be more than happy to assist with making releases with maven easier > for Apache projects ... So if you give me a little update on what needs to > be done, I might be able to spare some time and work on this. > But using the files from the prepare is the issue I'm trying to address ... > the perform build is a clean checkout of the tagged version. The clean > checkout ensures the build is 100% clean ... things like packing in > test-results, packing in maven-wrapper jars etc. only happens because the > source distribution is not built in a clean environment. > I would love if it was possible to extend questions the release-prepare > plugin asks for ... so if it would ask for a RC number, we could add a > call to the scm:checkin goal in the deploy phase of a release-perform build > as part of the "apache-release" profile. The only piece of information > that’s missing, would be the release-candidate number. > > Chris > > > > Am 05.01.20, 14:07 schrieb "Robert Scholte" : > > ASF deserves a customized release strategy, which is now possible with > MRELEASE-956 My idea is that during "prepare" the plugin should upload > several files to the ASF dist folder besides the tagging. During "perform" > it should use these files instead of the tag in SCM (because these files > are the official releases, not the tag). > Just waiting for someone to pick it up. > > thanks, > Robert > > > [1] https://jira.apache.org/jira/browse/MRELEASE-956 > On 5-1-2020 11:28:22, Christofer Dutz > wrote: Hi all, > > I just wanted to suggest something I have noticed a lot of Apache > projects were doing wrong. Especially when unexperienced RMs are doing the > releases. > Several times now after doing a release, the RMs have uploaded the > source bundles from “target” to the SVN. However they should have uploaded > the “target/checkout/target”. It is just too tempting to upload the > versions left over from the release:prepare step as they too have the > release version. > Usually this wouldn’t be a problem and I guess this has happened quite > often in the past. The thing is with the adoption of the maven-wrapper we > can unfortunately see when something’s going wrong. In this case there is > a difference. The source bundles from the prepare step then usually contain > the ./mvn/maven-wrapper.jar … which is usually my indicator for instantly > knowing what went wrong. The version in the target/checkout simply couldn’t > contain this file. > From the discussions with the reproducible builds I learned that you can > define pre and post actions to the prepare and perform steps. So how about > adding a pre-perform action that simply cleans the target directory? > I guess updating the default assembly to exclude the jar and class files > in the “./mvn” directory could cure some symptoms, but people would still > upload the wrong file. > I think this could prevent a lot of RCs being -1ed by Justin ;-) > > > Chris > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Multiple executions of Maven with a single run
Hi Enrico Technically concatenating all goals for all modules will do it but will be quite long - guess it is why we do it in 2 times. That said i always wondered why maven can read commands from a file/stdin as any unix like soft so it would be something like: mvn --commands-file ci.cmdlist Using stdin/echo it would also match ypur ci need maybe? Le dim. 5 janv. 2020 à 17:31, Enrico Olivelli a écrit : > Hello, > Sometimes it happens that you have to launch twice Maven to: > - build a whole reactor project (warmup) > - run some specific mojo only a selection of modules > > mvn clean install -DskipTests -Dmaven.repo.local=tmprepo > > mvn do:something -pl module1,module1-Dmaven.repo.local=tmprepo > > I think that in the general case there is no way to do this with one single > execution of Maven, for instance from CI. > > I am thinking about a simple enhancement to workaround this problem: > We can let Maven executable to accept a list of command line execution > arguments and loop executing the list, halting at the first failure >
[DISCUSS] Merging small plugins
Hi community, I just want to share this idea, maybe it is silly but why not talk about it. We have tens of plugins, most of them are rarely updated and released. So it happens that users contribute patches in order to fix real problems but they have to wait an indefinite time before seeing the fix released, because we are not doing a release just for one issue. Another problem is that making a release is quite an heavyweight task: - update parent pom, update dependencies - stage a release - make the VOTE, wait, make at least 3 PMC vote.. - finalize... What about creating some maven-ext-plugins git repository with a parent and reactor pom and move all of those plugins that are really never released? I am thinking to side plugins like jdeps, checkstyle, pmd, enforcernot compiler, assembly, surefire... If we merge them into one single code base we can: - have releases for all of them, even with some minimal (but blocker) fix - save time and resources (one committer does the work once and PMC votes only once, and we release 10 or more plugins...) We could even think to time based release schedule I image the big work you did for splitting all of the 100 git repositories from svnbut I think this move can give more vitality to the project We would have to think about jira, websitesI know it won't be easy Best regards Enrico
Multiple executions of Maven with a single run
Hello, Sometimes it happens that you have to launch twice Maven to: - build a whole reactor project (warmup) - run some specific mojo only a selection of modules mvn clean install -DskipTests -Dmaven.repo.local=tmprepo mvn do:something -pl module1,module1-Dmaven.repo.local=tmprepo I think that in the general case there is no way to do this with one single execution of Maven, for instance from CI. I am thinking about a simple enhancement to workaround this problem: We can let Maven executable to accept a list of command line execution arguments and loop executing the list, halting at the first failure
Re: Updating the apache parent to automatically clean before performing a release?
You might want to take a peek at what we do over at Apache Commons. We have attempted to make things easier for ourselves with two custom Maven plugins but IMO it is still error prone and a pain. Some of the pain is due to having to perform a "double release" by pushing various files to both Nexus and the dev/release svn repo. Gary On Sun, Jan 5, 2020, 08:41 Christofer Dutz wrote: > Hi Robert, > > I would be more than happy to assist with making releases with maven > easier for Apache projects ... > So if you give me a little update on what needs to be done, I might be > able to spare some time and work on this. > > But using the files from the prepare is the issue I'm trying to address > ... the perform build is a clean checkout of the tagged version. > The clean checkout ensures the build is 100% clean ... things like packing > in test-results, packing in maven-wrapper jars > etc. only happens because the source distribution is not built in a clean > environment. > > I would love if it was possible to extend questions the release-prepare > plugin asks for ... so if it would ask for a RC number, > we could add a call to the scm:checkin goal in the deploy phase of a > release-perform build as part of the "apache-release" profile. > The only piece of information that’s missing, would be the > release-candidate number. > > > Chris > > > > Am 05.01.20, 14:07 schrieb "Robert Scholte" : > > ASF deserves a customized release strategy, which is now possible with > MRELEASE-956 > My idea is that during "prepare" the plugin should upload several > files to the ASF dist folder besides the tagging. > During "perform" it should use these files instead of the tag in SCM > (because these files are the official releases, not the tag). > > Just waiting for someone to pick it up. > > thanks, > Robert > > > [1] https://jira.apache.org/jira/browse/MRELEASE-956 > On 5-1-2020 11:28:22, Christofer Dutz > wrote: > Hi all, > > I just wanted to suggest something I have noticed a lot of Apache > projects were doing wrong. Especially when unexperienced RMs are doing the > releases. > > Several times now after doing a release, the RMs have uploaded the > source bundles from “target” to the SVN. However they should have uploaded > the “target/checkout/target”. > It is just too tempting to upload the versions left over from the > release:prepare step as they too have the release version. > > Usually this wouldn’t be a problem and I guess this has happened quite > often in the past. The thing is with the adoption of the maven-wrapper we > can unfortunately see when something’s going wrong. > In this case there is a difference. The source bundles from the > prepare step then usually contain the ./mvn/maven-wrapper.jar … which is > usually my indicator for instantly knowing what went wrong. > The version in the target/checkout simply couldn’t contain this file. > > From the discussions with the reproducible builds I learned that you > can define pre and post actions to the prepare and perform steps. So how > about adding a pre-perform action that simply cleans the target directory? > > I guess updating the default assembly to exclude the jar and class > files in the “./mvn” directory could cure some symptoms, but people would > still upload the wrong file. > > I think this could prevent a lot of RCs being -1ed by Justin ;-) > > > Chris > > >
Re: Updating the apache parent to automatically clean before performing a release?
Hi Robert, I would be more than happy to assist with making releases with maven easier for Apache projects ... So if you give me a little update on what needs to be done, I might be able to spare some time and work on this. But using the files from the prepare is the issue I'm trying to address ... the perform build is a clean checkout of the tagged version. The clean checkout ensures the build is 100% clean ... things like packing in test-results, packing in maven-wrapper jars etc. only happens because the source distribution is not built in a clean environment. I would love if it was possible to extend questions the release-prepare plugin asks for ... so if it would ask for a RC number, we could add a call to the scm:checkin goal in the deploy phase of a release-perform build as part of the "apache-release" profile. The only piece of information that’s missing, would be the release-candidate number. Chris Am 05.01.20, 14:07 schrieb "Robert Scholte" : ASF deserves a customized release strategy, which is now possible with MRELEASE-956 My idea is that during "prepare" the plugin should upload several files to the ASF dist folder besides the tagging. During "perform" it should use these files instead of the tag in SCM (because these files are the official releases, not the tag). Just waiting for someone to pick it up. thanks, Robert [1] https://jira.apache.org/jira/browse/MRELEASE-956 On 5-1-2020 11:28:22, Christofer Dutz wrote: Hi all, I just wanted to suggest something I have noticed a lot of Apache projects were doing wrong. Especially when unexperienced RMs are doing the releases. Several times now after doing a release, the RMs have uploaded the source bundles from “target” to the SVN. However they should have uploaded the “target/checkout/target”. It is just too tempting to upload the versions left over from the release:prepare step as they too have the release version. Usually this wouldn’t be a problem and I guess this has happened quite often in the past. The thing is with the adoption of the maven-wrapper we can unfortunately see when something’s going wrong. In this case there is a difference. The source bundles from the prepare step then usually contain the ./mvn/maven-wrapper.jar … which is usually my indicator for instantly knowing what went wrong. The version in the target/checkout simply couldn’t contain this file. From the discussions with the reproducible builds I learned that you can define pre and post actions to the prepare and perform steps. So how about adding a pre-perform action that simply cleans the target directory? I guess updating the default assembly to exclude the jar and class files in the “./mvn” directory could cure some symptoms, but people would still upload the wrong file. I think this could prevent a lot of RCs being -1ed by Justin ;-) Chris
Re: Updating the apache parent to automatically clean before performing a release?
ASF deserves a customized release strategy, which is now possible with MRELEASE-956 My idea is that during "prepare" the plugin should upload several files to the ASF dist folder besides the tagging. During "perform" it should use these files instead of the tag in SCM (because these files are the official releases, not the tag). Just waiting for someone to pick it up. thanks, Robert [1] https://jira.apache.org/jira/browse/MRELEASE-956 On 5-1-2020 11:28:22, Christofer Dutz wrote: Hi all, I just wanted to suggest something I have noticed a lot of Apache projects were doing wrong. Especially when unexperienced RMs are doing the releases. Several times now after doing a release, the RMs have uploaded the source bundles from “target” to the SVN. However they should have uploaded the “target/checkout/target”. It is just too tempting to upload the versions left over from the release:prepare step as they too have the release version. Usually this wouldn’t be a problem and I guess this has happened quite often in the past. The thing is with the adoption of the maven-wrapper we can unfortunately see when something’s going wrong. In this case there is a difference. The source bundles from the prepare step then usually contain the ./mvn/maven-wrapper.jar … which is usually my indicator for instantly knowing what went wrong. The version in the target/checkout simply couldn’t contain this file. >From the discussions with the reproducible builds I learned that you can >define pre and post actions to the prepare and perform steps. So how about >adding a pre-perform action that simply cleans the target directory? I guess updating the default assembly to exclude the jar and class files in the “./mvn” directory could cure some symptoms, but people would still upload the wrong file. I think this could prevent a lot of RCs being -1ed by Justin ;-) Chris
Updating the apache parent to automatically clean before performing a release?
Hi all, I just wanted to suggest something I have noticed a lot of Apache projects were doing wrong. Especially when unexperienced RMs are doing the releases. Several times now after doing a release, the RMs have uploaded the source bundles from “target” to the SVN. However they should have uploaded the “target/checkout/target”. It is just too tempting to upload the versions left over from the release:prepare step as they too have the release version. Usually this wouldn’t be a problem and I guess this has happened quite often in the past. The thing is with the adoption of the maven-wrapper we can unfortunately see when something’s going wrong. In this case there is a difference. The source bundles from the prepare step then usually contain the ./mvn/maven-wrapper.jar … which is usually my indicator for instantly knowing what went wrong. The version in the target/checkout simply couldn’t contain this file. From the discussions with the reproducible builds I learned that you can define pre and post actions to the prepare and perform steps. So how about adding a pre-perform action that simply cleans the target directory? I guess updating the default assembly to exclude the jar and class files in the “./mvn” directory could cure some symptoms, but people would still upload the wrong file. I think this could prevent a lot of RCs being -1ed by Justin ;-) Chris
