Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 74.125.82.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <51D86793.8040208@commonjava.org>
References: 
 <CAOGo0VZCSLT2jXZD2eqmsjWtLURqOaewc85FMp02FjA_OHyjZg@mail.gmail.com>
	<51D8636A.5050303@commonjava.org>
	<51D86793.8040208@commonjava.org>
Date: Sun, 7 Jul 2013 00:11:45 +0100
Message-ID: 
 <CAOGo0VYprgPXNz6q4uRQ5j7=6FjntD6WPYVAZE8y7VokLEhMaw@mail.gmail.com>
Subject: Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate -
 broken release process?
From: sebb <sebbaz@gmail.com>
To: John Casey <jdcasey@commonjava.org>
Cc: Maven Developers List <dev@maven.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On 6 July 2013 19:53, John Casey <jdcasey@commonjava.org> wrote:
> Hmm, actually, from running a few builds of the source-release archive, I
> can see that the unit tests appear to be creating the
> ${basedir}/maven-archive/ directory. I wonder if this has to do with
> incomplete configuration of the test harness?

Looks like:

http://svn.apache.org/r1498096

was supposed to fix this; seems to be in the release candidate but
looks like the fix did not work.

> In any case, I can see why the source-release assembly did the wrong thing
> here; it's not in target, so not really expected to be a generated file.

Yes, that is basically the point I made early on else-thread.
I said that the release process did not guarantee that the source
archive would contain exactly the correct files - no more, no less.

The issue here is not that this particular file found its way into the
source archive.
Luckily the file looks to be harmless. It might not be next time.
The point is that the the release process is not infallible (in spite
of what people have stated).

Every so often, a vote reviewer needs to check that the source output
from the build process agrees with the source input.
If a discrepancy is found, it can be investigated and fixed.

But the important thing to take from this is that the current release
vote checking process could (and should) be improved.

>
> On 7/6/13 1:35 PM, John Casey wrote:
>>
>> On 7/6/13 11:28 AM, sebb wrote:
>>>
>>> The curent release candidate for Apache Maven War plugin 2.4 contains
>>> the following file in the source zip:
>>>
>>> maven-archiver/pom.properties
>>>
>>> The file is not in SVN or the source jar
>>> As far as I can tell it does not belong in the source zip.
>>>
>>> The file is unlikely to do any harm, however the fact that it somehow
>>> has crept into the source archive points to a problem with the release
>>> process.
>>>
>>> The file is present in all the WAR source zips back to 2.1 (previously
>>> there were no source archives)
>>> AFAICT these WAR source archives were built by several different people.
>>>
>>> It does not seem to be present in sources for the few other plugin
>>> sources that I checked.
>>>
>>> So why does the file end up in the WAR source archive?
>>>
>>> What is broken?
>>
>>
>> I'd be surprised if you didn't find the same file in other
>> source-release archives. I'm guessing it's an exclusion that's missing
>> from the source-release.xml assembly descriptor that we use to construct
>> these archives.
>>
>>>
>>> I found the problem by comparing the source archive with the SVN tag.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>
>
> --
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> GitHub - http://github.com/jdcasey

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org