Re second checkouts, you're already hurting some (admittedly minority of) users (not me) with LARGE source trees by doing this at all. Keep this in mind and at least make any checking out optional...
Perhaps if the SCM plugins were "ignore aware" they could read this info and compare it with some sort of "build output" file pattern list as part of the "are we clean" process, then delete the build output up front. This assumes the setup is misconfigured to not put EVERYTHING in target/, though. So possibly massive overkill. Delete target/, build to verify it, delete target/ again, setup versions, build release. Why the checkout? Fred. On Sun, Jul 7, 2013 at 9:52 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > 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 <seb...@gmail.com <javascript:;>> > > wrote: > > > > > On 7 July 2013 13:45, Chris Graham <chrisgw...@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-unsubscr...@maven.apache.org<javascript:;> > > > For additional commands, e-mail: dev-h...@maven.apache.org > <javascript:;> > > > > > > > > > > > > -- > > ----- > > Arnaud Héritier > > http://aheritier.net > > Mail/GTalk: aheritier AT gmail DOT com > > Twitter/Skype : aheritier > > > > > -- > Sent from my phone >
