On Mon, Jul 8, 2013 at 5:31 AM, sebb <seb...@gmail.com> wrote: > On 7 July 2013 13:45, Chris Graham <chrisgw...@gmail.com> wrote: > > In this instance, these files are derived files, so does it matter? > > I already said that this particular file is probably not an issue. > > I think that you missed my point, namely the case of derived files.
The issue is that the release process is clearly not infallible. > > There is nothing wrong with the process. One of the core tennants of SCM is reproducability. If you were to check the tag out and rebuild it, you should achieve the same result. If you do not, then, and only then do you have a _process_ issue. And only then, if you are not able to explain any differences (timestamps in files here is a leading cause of differences). In this case we have a _configuration_ issue, not a _process_ issue. The assembly plugin does not identify every file it needs to include, > so spurious files can be picked up if they happen to be in the wrong > place. > As happened here. > Furthermore, AFAIK it does not report include failures, so a required > file could be omitted. > In this case, there was an issue with a test creating the spurious > file. If test cases delete work files after use, it's not impossible > to imagine that the wrong file is deleted. > > But regardless of the process used to create the release candidate, I > think the way to check whether it has the correct contents is to > compare it against the SCM from which it was derived. The comparison > will identify missing and spurious files. > Files that match the SCM also have a traceable provenance, and SCM > files should already have been validated for license compatibility. > > I see this as basic quality control. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
