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 <christofer.d...@c-ware.de> 于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" <saint...@gmail.com>: > > 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 <christofer.d...@c-ware.de> 于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" <saint...@gmail.com>: > > > > 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 <saint...@gmail.com> 于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 > > > > > > 黄向东 > > > 清华大学 软件学院 > > > > > > > > > > > >
