maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
Date Sun, 07 Jul 2013 19:52:25 GMT
On Sunday, 7 July 2013, 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.
> 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 ?


If we bind the execution of the src assembly to the "validate" phase of the
release profile, that would at least be capturing at the start...

Should be possible to move the phase earlier for just the release profile.

The alternative is to do a 2nd nested checkout to compare with...


> * 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 <javascript:;>>
> wrote:
>
> > On 7 July 2013 13:45, Chris Graham <chrisgwarp@gmail.com <javascript:;>>
> 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 <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >
> >
>
>
> --
> -----
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>


-- 
Sent from my phone

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