RE: [Cobertura-devel] Re: Cobertura 1.5

[Seigel, J. <Jam...@av...>]

I will take a look at the code base and see if I can wedge any unit
tests in there and see what can be done with xmlreporttest

=20

Cheers

James.

=20

________________________________

From: cob...@li...
[mailto:cob...@li...] On Behalf Of Jeremy
Thomerson
Sent: Tuesday, August 02, 2005 11:39 PM
To: Grzegorz Lukasik
Cc: cob...@li...
Subject: Re: [Cobertura-devel] Re: Cobertura 1.5

=20

Okay, all the changes are committed for the filesets changes.  Grzegorz,
I couldn't add your changes, I'll let you.  I really wanted to, but
there were so many other changes, it made it daunting. =20

=20

One thing to note:  Mark committed some changes today that were from
various patches, and I had to manually merge a couple of files because
there were so many conflicting changes in the same class (since I pretty
much entirely rewrote a couple of classes).  The only one that I'm
concerned about is instrumenting/Main.java.  I think that came from
Grzegorz's patch if I'm not mistaken.  I think I got everything, but
could you just check to make sure?  It looked like most of your changes
in it revolved around regexes being a Collection rather than a Pattern,
but I had so many changes in that class it was hard to tell.=20

=20

If I messed anyone's patch up, I am sincerely sorry.  I'll owe you a
beer, and I'll do anything I can to help you get it back to what you had
submitted.

=20

Thanks to everyone!  Please test this (with multiple source directories)
and let me know if you find anything that needs to be looked at.  If you
pull down the latest code from CVS and do a build, it includes the
multiple directories so we can see it work.=20

=20

The only regrettable thing that this commit did is commented out our
XMLReportTest.  I didn't have time to look into what it would take to
switch it to be operable with the current ReportTask.  It looked like it
was passing in command line arguments, which has now changed to a
command file, and it was just too much for right then.  If someone want
to convert it (and write any other unit tests for the multi-filesets),
that would be great. =20

=20

JT

=20

On 8/2/05, Grzegorz Lukasik <ha...@gm...> wrote:=20

Jeremy,

I think there are two things from my patch that are easy to reuse in
yours. The first is CommandLineBuilder - it puts building-parsing long=20
command lines in one place. The second is ability of FileStore (yours
FileFinder) to compute complexity. Basically it removes complexity
computation from report classes, and computes complexity exactly for
files the report is generated for, and at most once for each one. Add=20
them to your patch if you like. I will add patches later, if you do
not want to complicate your solution now.

Grzegorz

On 8/1/05, Jeremy Thomerson <jer...@gm... > wrote:
> 1. okay, cool
>  2. agreed - will change
>  3. oops, you're right, it was for reference, forgot to remove
>  4. yeah, i'll remove the jar, too (i think that's the only dependency
--=20
> i'll check
>  5. i'll look to see where I did it -- not sure, but probably b/c my
default
> code template adds a default no-op constructor (something we do at
work, so
> the settings / habits carry over)=20
>  6. great suggestions - the kind of things I would normally do, not
sure why
> I didn't on this one
>  7. I'll add an assert so that we don't get any [potential] JUnit
> warnings.... even though the main point of the test is a no-op, it's
just to=20
> call methods
>
>  I'll look at his patch, too.  I did all of this development offline
> Saturday, so Saturday morning before I left the house, I saved the
fr's and
> bugs from SF to a text file, but forgot to grab the patches to use as=20
> reference / starting point.  Sorry to those of you who submitted
patches
> that I forgot to grab.  I will look at them before committing, though,
and
> merge anything that they include and I forgot.
>
>  Once I get these things done, I'll commit unless anyone objects
before
> that....
>
>  Until then,
>  Jeremy
>
>
> On 8/1/05, Mark Doliner < Mar...@sa...
<mailto:Mar...@sa...> > wrote:
> > I'll number things for reference:
> >
> > 1. I just committed the ChangeLog typo fix to get it out of the way,
> thanks for catching that.
> >=20
> > 2. It might be better if "othersrc" was called "src2," instead.
That way
> it would show up next to "src" in directory listings and people would
notice
> it more.  It also allows for us to have "src3" and higher (I doubt
that'll=20
> ever happen... but who knows).
> >
> > 3. You have a lot of code commented out in reporting.Main... It
looks like
> most of it was replaced with other code, and I guess you were using it
for=20
> reference, but I would definitely remove it before committing (if
people
> want to see an older version of the code then they can check out an
old
> revision from CVS).
> >
> > 4. I like that you stopped using gnu.getopt in reporting.Main.
Getopt is
> kind of overkill, I think, and I'd like to remove that jar.
> >
> > 5. Is there any reason you're adding empty constructors
ocassionally?
> I've just been implicitly using the default/parent's constructor.=20
> >
> > 6. In FileFinder.findFile you convert forward slashes to
backslashes... It
> seems like it would make more sense to do that in addSourceFilePath()
> instead.  And also to create a String filePartReplaced or something
before=20
> the loop in findFile instead of doing the search/replace for every
> iteration.  And I'd also vote for converting back slashes to forward
> slashes, but I'm a Linux guy :-)
> >
> > 7. Your faux TestCase for SomeOtherClass doesn't have an assert, it
seems=20
> like JUnit might warn against that?
> >
> > You might want to work with Grzegorz Lukasik or see if he does
anything in
> his patch that you might want to do in yours:
> >
>
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1245454&grou=
p_i
d=3D130558&atid=3D720017=20
> >
> > -Mark
> >
> >
> > > -----Original Message-----
> > > From: cob...@li...=20
> > > [mailto: cob...@li...]
> On
> > > Behalf Of Jeremy Thomerson
> > > Sent: Saturday, July 30, 2005 10:26 PM=20
> > > To: Mark Doliner
> > > Cc: cob...@li...
> > > Subject: [Cobertura-devel] Re: Cobertura 1.5
> > >
> > > I spent a few hours today making instrumentation and reporting
work
> > > with multiple source directories.  Rather than committing it, I am
> > > sending out the patch, asking for someone to review it.  It also
adds=20
> > > a second directory of source (just one simple faux class) so that
we
> > > have the multiple filesets / multiple source directories in our
> > > instrumentation and reporting build.=20
> > >
> > > I didn't have time to update any documentation that we have for
usage,
> > > so if someone could update that (assuming that everyone likes this
> > > solution), that would be great.  Also, I just realized that the=20
> > > reporting task should be backwards-compatible with the old srcdir
> > > attribute, but I don't think I remembered to do that with the
> > > instrumentation task.  If I didn't, but everyone likes this patch,

> > > I'll commit these changes and add that to the instrumentation
class
> > > for backwards compatibility.
> > >
> > > Please let me know what you think.
> > >=20
> > > Jeremy Thomerson
> > >
> > > On 7/27/05, M C < mor...@ya...> wrote:
> > > > Mark Doliner wrote:
> > > > >Hi, I'm thinking about releasing Cobertura 1.5 soon.
> > > > >It still doesn't supported multiple source
> > > > directories >for reporting (I REALLY need to look at
> > > > that patch), >or multiple class directories for=20
> > > > instrumenting, but >there are a lot of other changes.
> > > > >What do you guys think?
> > > >
> > > > IMHO Without the patch for multiple source directories=20
> > > > I personally do not see the point of a release now.
> > > > Better to wait for the real thing.
> > > >
> > > > Cheers,
> > > > Morten
> >
> >
> >
>
>



=20