harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [classlib] Trying to catch patternset errors earlier
Date Thu, 28 Sep 2006 10:48:25 GMT

On 28 September 2006 at 14:30, "Alexey Petrenko" <alexey.a.petrenko@gmail.com> 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

This simple check can only happen part way through the clean target -
after the modules have done their cleaning and before the top-level
cleanup is done.

The next most simple solution would probably involve creating a fileset
that excludes everything from all the modules filesets and testing what
is left.  I've not tried, but I think this would mean embedding more
information in the top-level build file - a list of patternset files -
and I really want to see this kind of coupling reduced not increased.

And the list of patternsets would be something that would have to be
maintained over time so there is as much chance of the test not being
updated as the patternsets not being updated so we'd need a way to check
that too! ;-)

There are probably more complex solutions that maintain low coupling
between the top-level and modules.  If clean failing bothers you enough,
then I'd be interested in a patch - as I said it "feels" odd to me that
clean can fail but I'd rather have this test than no test at all.

> 2. If it will fail and leave some files in build dirs how should I
> clean the repository?

I've fixed the clean target so that it always completes the cleaning
process even if it fails.

Regards,
 Mark.

> 2006/9/28, Mark Hindess <mark.hindess@googlemail.com>:
> >
> > On 28 September 2006 at 11:07, Tim Ellison <t.p.ellison@gmail.com> 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/ProviderServic
> e.cl
> > > ass
> > > >
> > > > I'm sure there are other ways to solve this problem but this seemed lik
> e
> > > > 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: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> > > --
> > >
> > > Tim Ellison (t.p.ellison@gmail.com)
> > > IBM Java technology centre, UK.
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> 
> 
> -- 
> Alexey A. Petrenko
> Intel Middleware Products Division
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message