In this instance, these files are derived files, so does it matter?
If you re-run the build, the same files should be generated in the same way, so
you get a consistent build.
That is different issue to differences between different releases.
It is also a separate issue to whether the file should be there in the first
place, which is being looked at.
-Chris
Sent from my iPhone
On 07/07/2013, at 10:06 PM, Olivier Lamy <ol...@apache.org> wrote:
> 2013/7/7 sebb <seb...@gmail.com>:
>> On 6 July 2013 19:53, John Casey <jdca...@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.
>
> ah yes. Strange I will have a look for next release. Grhh this file is
> in svn:ignore property so svn st didn't detect that.
>
> I noticed javadoc plugin source release has the same issue with a file
> called javadoc-options-javadoc-resources.xml which must not be in
> here.
>
>
>>
>>> 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-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> John Casey
>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>> GitHub - http://github.com/jdcasey
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
>
>
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
