maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud Héritier <aherit...@gmail.com>
Subject Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
Date Sun, 07 Jul 2013 19:39:42 GMT
I understand the issue but for me all that problems will never disappear if
we don't find a solution to automate the process.
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.
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 ?
* We could add a control (enforcer ?) that will compare the content of an
archive with an scm tag checkout

Arnaud


On Sun, Jul 7, 2013 at 9:31 PM, sebb <sebbaz@gmail.com> wrote:

> On 7 July 2013 13:45, Chris Graham <chrisgwarp@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.
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message