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?
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]
-- Alexey A. Petrenko Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
