Hi Xiangdong, I think I know what the general problem is: From that page (not much I can actually understand much) But it does mention the release:perform step and immediately after that I mentions the source and binary distributions. Also it mentions validating the source and binaries build by the prepare step and does the release perform after that.
You have to execute the perform step and then validate the signatures of the artifacts built by that. So you should move the source and bin distribution validation guilde to after the release:perform. And you should guide the RM to the target/checkout/target directory instead of the target directory. Chris Am 02.12.19, 14:42 schrieb "Xiangdong Huang" <[email protected]>: Hi Chris, I am sure that I ran `mvn release:perform` after ran `mvn release:prepare`. On page [1], step 3.1 and 3.2 are `mvn release:prepare` and `mvn release:perform` As I am going to generate RC2 of 0.8.2, I can try once again. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=130027555 Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Christofer Dutz <[email protected]> 于2019年12月2日周一 下午4:59写道： > Hi Xiangdong, > > the "mvn release:prepare" step does the following: > - Checks if there are uncommitted filed > - Updates the version to the release version > - Checks if there are remaining SNAPSHOT dependencies > - Runs a full build including tests with this version > - If this build succeeds, It commits the changes and tags this commit > - Then it changes the versions to the next development version > - Then it commits this version too > - Then it pushes the changes > > The step you have to do now is run the "mvn release:perform" > - Check out the tagged version from git into the main "target/checkout" > directory > - Spawns a "mvn -P apache-release deploy" build in that directory > - This builds the source bundle in "target/checkout/target" and creates > the hashes and signs the artifacts > - During the build it also deploys the maven artifacts to the apache nexus > > As soon as that's done, you: > - Go to the Apache nexus and close the staging repo > - Create a new staged release by uploading the RELEASE_NOTES, README and > the source bundle together with the hashes and signatures to SVN > > To me it looks as if you're simply uploading the stuff created in the > first step, which is not correct as it isn't > executed from a clean checkout and it will contain other stuff that's just > laying around in your workspace. > > Chris > > > Am 01.12.19, 15:35 schrieb "Xiangdong Huang" <[email protected]>: > > Hi, > > > it will checkout the git revision the prepare goal tagged as release > version. It will checkout this into the target/checkout directory. > If so, it is quite strange that why there was something incorrect in > previous releases.. > > Now the command is `mvn release:prepare -DautoVersionSubmodules=true`, > I am > not sure whether it download source code from github first, I need to > check > it when I run release next time.. > > > So I guess you re-ran the release build more than once > Yes it may be. Sometime I ran `mvn release:prepare` .... and if I find > failures, I ran `mvn release:rollback` and run `relrease:prepare` again > after fixing problems and didnot ran `mvn clean`.. > > >The other problem you are having is that the build is generating > things > outside the target directory. > A PR is available[1], which is proposed by a new contributor. A PPCM > has > reviewed the codes and approved on github. > But we need to guarantee that new committers also obey the rule in the > future. So be careful in the code review stage. > > By the way, I think an assembly file is useful for the following > scenario: > > > What is more, it is very helpful when we switch different branches > for > releasing. for example, in v0.9.0, there is a module called session, > which > does not exist in 0.8.0. So, if I switch the branch from 0.9 to 0.8 (or > rel/0.8) for a minor version releasing (e.g., 0.8.2), I have to remove > the > session folder manually. If I forgot that, a dirty source-release.zip > is > generated. But if we have an assembly.xml, it will avoid that. > > As I am using IDEAJ, there is a plain text file `session.iml` (like > .classpath and .project in Eclipse) in session's directory. The file > does > not disappear when I switch to 0.8, and even `mvn clean` does not > delete > the file. > I am not sure whether `mvn release:prepare > -DautoVersionSubmodules=true` > will ignore it ( yes if the command download source codes from > github), but > if I try `mvn package -Papache-release -DskipTests`, the file will be > packed, which is incorrect. > > [1] https://github.com/apache/incubator-iotdb/pull/578 > > Best, > ----------------------------------- > Xiangdong Huang > School of Software, Tsinghua University > > 黄向东 > 清华大学 软件学院 > > > Christofer Dutz <[email protected]> 于2019年12月1日周日 下午8:57写道： > > > HI all, > > > > I think the problem was that you were not doing the releases right > or not > > staging the right artifacts. > > If you run release:perform ... it will checkout the git revision the > > prepare goal tagged as release version. > > It will checkout this into the target/checkout directory. There it > will > > run a "mvn deploy" build without the maven-wrapper. > > > > As it is doing this there simply can't be any class or jar file in > the > > .mvn directory of the checkout directory. > > So then the assembly packs up everything in there, it simply can't > pack up > > any class or jar files. > > > > The other problem you are having is that the build is generating > things > > outside the target directory. > > That's a problem you definitely have to fix. As soon as that's done, > there > > shouldn't be any problems as the target directories are automatically > > excluded. > > But in general the assembly would build the source bundle before > actually > > running any tests and therefore there shouldn't be any binary > resources. > > So I guess you re-ran the release build more than once ... > > > > So instead of fixing the symptoms, I would suggest to fix the cause. > The > > cause is that you're not executing the release steps for Maven builds > > correctly. > > > > Chris > > > > > > > > But I definitely > > > > Am 01.12.19, 06:46 schrieb "Xiangdong Huang" <[email protected]>: > > > > Sorry the PR link is [1]. > > > > [1] https://github.com/apache/incubator-iotdb/pull/610 > > > > Best, > > ----------------------------------- > > Xiangdong Huang > > School of Software, Tsinghua University > > > > 黄向东 > > 清华大学 软件学院 > > > > > > Xiangdong Huang <[email protected]> 于2019年12月1日周日 下午1:45写道： > > > > > Hi, > > > > > > Considering we packed some incorrect files in the last release > (RC1 > > to > > > RC4), I think writing an assembly.xml file for generating the > > > source-release.zip is a good way to avoid that. > > > > > > What is more, it is very helpful when we switch different > branches > > for > > > releasing. for example, in v0.9.0, there is a module called > session, > > which > > > does not exist in 0.8.0. So, if I switch the branch from 0.9 > to 0.8 > > (or > > > rel/0.8) for a minor version releasing (e.g., 0.8.2), I have to > > remove the > > > session folder manually. If I forgot that, a dirty > > source-release.zip is > > > generated. But if we have an assembly.xml, it will avoid that. > > > > > > I have written the source-assembly.xml now in PR [1]. The > assembly > > file > > > looks ugly because we have to declare the files one by one. (I > tried > > the > > > <moduleSet> tag, which is more convenient. But because our > > > module.artifactId != module.folder name, there is some issues > that I > > can > > > not solve. Finally I gave up using <moduleSet> tag). > > > > > > If the PR is accepted, then for all contributors please notice > that: > > > > > > (1) If you add new source files into a src/ docs/ license > folder, it > > is ok. > > > (2) If you add a new module, create a new folder, or write a > plain > > text > > > file under the project's (or a module's) root directory, you > have to > > > maintain the source-assembly.xml file.. Otherwise the new added > > files will > > > not be packed into source-release.zip. > > > > > > Hope in this way, we can no longer get dirty > source-release.zip > > files. > > > > > > [1] > > > Best, > > > ----------------------------------- > > > Xiangdong Huang > > > School of Software, Tsinghua University > > > > > > 黄向东 > > > 清华大学 软件学院 > > > > > > > > > > > >
