Hi Chris,

> And you should guide the RM to the target/checkout/target directory
instead of the target directory.

I think this is what makes the error. I used target/*-source-release.zip*
rather than target/checkout/target/ .

Many thanks, and thanks for reading Chinese documents...

Best,
-----------------------------------
Xiangdong Huang
School of Software, Tsinghua University

 黄向东
清华大学 软件学院


Christofer Dutz <christofer.d...@c-ware.de> 于2019年12月2日周一 下午11:46写道:

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

Reply via email to