Release tag ignite-1.1.0-incubating-rc5

[Konstantin Boudnik-2]

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
 - bin/ignite.sh line 61 has this

. "${SCRIPTS_HOME}"/include/build-classpath.sh # Will be removed in release.

   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?

Thanks,
  Cos

[dsetrakyan]

On Wed, May 13, 2015 at 1:40 PM, Konstantin Boudnik <[hidden email]> 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.


>
> Thanks,
>   Cos
>
>

[Konstantin Boudnik-2]

On Wed, May 13, 2015 at 04:56PM, Dmitriy Setrakyan wrote:

> On Wed, May 13, 2015 at 1:40 PM, Konstantin Boudnik <[hidden email]> 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