Alexey Petrenko wrote: > I think that it will be better to add another target to build for this > check. > Because of two reasons: > 1. It is unclear that clean is also checks something > 2. If it will fail and leave some files in build dirs how should I > clean the repository?
I think Mark's point is that if it leaves files behind, that is a 'bug' that will be found in the next build cycle -- and be fixed by the person who introduced it. Regards, Tim > 2006/9/28, Mark Hindess <[EMAIL PROTECTED]>: >> >> On 28 September 2006 at 11:07, Tim Ellison <[EMAIL PROTECTED]> wrote: >> > Sounds reasonable. The alternative is to not make clean fail, just >> > print the warning and tidy up the remainder. That may be too easy to >> > ignore though. >> >> Yes. I considered that and had the same concern. Even if I wrote the >> code to print the warning, I think I'd ignore it since it would scroll >> too quickly off the top of my screen at the beginning of the build. >> >> -Mark. >> >> > Regards, >> > Tim >> > >> > Mark Hindess wrote: >> > > Yesterday, while looking at something unrelated, I noticed that some >> > > of the patternsets that are used to select the jars for the classlib >> > > modules were not up to date with the result that some classes >> would be >> > > missing from the resulting jars[0]. >> > > >> > > While it makes me slightly uneasy having a clean target that might >> fail, >> > > it turns out that this is one place where it is quite easy to check >> > > whether the patternsets are out of date. (Because if after the >> modules >> > > have cleaned classes in their patternsets there are still files left >> > > over then something is being create that isn't accounted for by the >> > > patternsets.) >> > > >> > > So the clean target will now fail with a message like (tested >> > > by reverting yesterdays change to the sound patternset): >> > > >> > > Built files still exist after module clean targets have run. This >> > > probably means that one or more patternsets are incomplete. The >> > > remaining files are: >> > > >> > > >> /classlib/build/classes/org/apache/harmony/sound/utils/ProviderService.cl >> > ass >> > > >> > > I'm sure there are other ways to solve this problem but this >> seemed like >> > > a sensible quick fix to help catch these problems a little sooner[1]. >> > > >> > > Regards, >> > > Mark. >> > > >> > > [0] This might explain some of the awt/swing test failures so perhaps >> > > it is worth checking the exclude lists again? >> > > >> > > [1] Though I guess since we clean at the beginning of a build (not >> the >> > > end) then we might still find them in the build after the one that >> > > caused the break but that's better than only finding them by >> accident. >> > > >> > > >> > > >> > > --------------------------------------------------------------------- >> > > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > For additional commands, e-mail: >> [EMAIL PROTECTED] >> > > >> > > >> > >> > -- >> > >> > Tim Ellison ([EMAIL PROTECTED]) >> > IBM Java technology centre, UK. >> > >> > --------------------------------------------------------------------- >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
