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
