maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
Date Sun, 07 Jul 2013 19:53:02 GMT
On 7 July 2013 20:39, Arnaud Héritier <> wrote:
> I understand the issue but for me all that problems will never disappear if
> we don't find a solution to automate the process.

The point is that processes and people are not infallible

> Yes PMCs (and devs) are responsible to do various controls as you mentioned
> but I suppose that we aren't different to others projects and our time
> spent in OSS projects is often limited.

It does not take long to do a comparison - assuming that the tag is
provided in the vote e-mail.

> About the problem of sources content I have two things in mind :
> * The release:perform goal is doing a checkout of the tag and then does the
> build/deploy of released stuffs. The problem is that the assembly which is
> creating the sources archive is doing it after the build instead of doing
> it just after the checkout. How could we change this to be sure that in the
> archive we just have what we just checkouted ?

That would reduce the window of opportunity for errors, but I'm
convinced that Murphy's law can be entirely avoided.

> * We could add a control (enforcer ?) that will compare the content of an
> archive with an scm tag checkout

There is already a Perl tool to compare directory structures:

I use that, as well as a GUI compare tool.

> Arnaud
> On Sun, Jul 7, 2013 at 9:31 PM, sebb <> wrote:
>> On 7 July 2013 13:45, Chris Graham <> 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.
>> The issue is that the release process is clearly not infallible.
>> 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:
>> For additional commands, e-mail:
> --
> -----
> Arnaud Héritier
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message