On Wed, May 13, 2015 at 04:56PM, Dmitriy Setrakyan wrote: > On Wed, May 13, 2015 at 1:40 PM, Konstantin Boudnik <[email protected]> wrote: > > > I've been pocking around the latest release candidate and here's a couple > > of > > issues I see: > > - version change commit message has missing closing double quote, e.g. the > > message says > > "Version changed > > which is an indication that something is wrong with the script that > > invokes mvn release > > > > Good catch! I think we can fix it in the next release. > > > > - bin/ignite.sh line 61 has this > > > > . "${SCRIPTS_HOME}"/include/build-classpath.sh # Will be removed in > > release. > > > > This should say: "Will be removed in the binary release". Fixed in sprint-5. > > > > which means that release's zip file will contain different scripts than > > that of the release tag, right? And there's a whole bunch of other > > massaging that's done to the scripts and pom during the package phase of > > release process. While binaries (aka packages) aren't of any concern to > > the > > Apache, the practice does look quite funky to me. Is there guarantee > > that > > published release pom will be _exactly_ the same as the one in source > > code? > > > > POM files are not being augmented, they are being flattened. To answer your > question, we cannot publish the same POM files we have in the source tree > because of the hierarchical structure of the project and dependencies on > the parent POM files. We use an existing Maven plugin for flattening POM > files before publishing them.
Why's reference to the parent POM is an issue? the ignite-core maven artifact is getting downloaded from the maven-central anyway. So, why not to get the project's top level POM definition? Cos
