Menu
▾
▴
cobertura-devel
|
From: Mark D. <Mar...@sa...> - 2005-05-10 15:03:13
|
*snip* > Anywho - the purpose of this email is to see how I can get > involved. One > gap in the product which I noticed (and may already be planned) is > coverage statistics over time. I was thinking, unless this is on > someone's plate already I could start to get familiar with > the code base > and put together a plan of attack - an impact of sorts - and > propose to > you all. *snip* > Please let me know if this is of interest. BTW - what is the typical > process of getting involved? Hope I am not jumping the gun. You're not jumping the gun at all. I suppose the typical process of get= ting involved is to find something you're interested in fixing/improving= /adding and writing a patch for it. I don't know of anyone working on s= tatistics over time. And it's definitely something that would be nice t= o have. You would definitely want to work with CVS, if you plan on maki= ng any changes. Some of the stuff I mention below applies to CVS but no= t to the last release. I guess the easy way to do it would be to name the XML reports based on = the date and time they were created, and then you could parse a director= y of these files and determine the change over time. This wouldn't even= need to be a part of Cobertura--it could be a completely separate progr= am. Or maybe instead of reading the data from the XML reports, you coul= d read it directly from cobertura.ser files. (The ser file contains bas= ically the same information as the XML reports. The ser file contains s= erialized classes from the package net.sourceforge.cobertura.coveragedat= a. If you choose to go this route, you would need to use these classes = to read the serialized file.) However, it might be better to modify the classes in the coveragedata pa= ckage to natively support a time and date. I'm not sure how this would = work exactly. Maybe you could tag the information in the ser file with = a datestamp and then zero it out before running the next batch of tests. I think it is important that this have a good user interface. How would= the statistics be displayed? As a line graph, maybe? How would the us= er tell Cobertura to create these reports? Would they specify a "start = date" and "end date"? Would the report have a separate display for each= package? For each class? Would it have a way to show differences in t= he source files? Does that help you, any? -Mark |
|
From: Jody B. <jod...@Q1...> - 2005-05-13 10:55:44
|
Sure does - thanks. My first thoughts were - this could be an addon package/application of sorts which can use your .ser file or the XML reports (once successfully completed). I would prefer to not touch your guys code at all if possible and just piggy back on what you have - make enhancements if required. This implies that, the way users run cobertura now would not change at all - providing a single user mode of sorts. Then the new additional task (ant?) could be run to export that data to a central or non volatile data store. (Data store could be RDBMS, flat file or what have you - makes no difference to me - as long as simple and fast). Key things for me are, it needs to be extremely simple to install and maintain. No over complicated configuration etc - keep it as it is today as much as possible. Agree about the UI - has to be clean, intuitive, simple and fast.=20 - Be nice to view reports on product? / project / package / class / ... hierarchy - as you navigate through the hierarchy - graph/plot for where you are - plotting lines of code / coverage over time (Jfreechart has some great plots) - Need to identify and ensure we have the right data in the datastore. A few reports which come to mind are - plain coverage stats - plain coverage stats plotted against lines of code - coverage stats of one project/package/class plotted against the baseline coverage of all projects (how does this project/package/class compare to the running average) ( more advanced :)) For now - I will focus on keeping it simple with two additional ant tasks, one for exporting/updating to non volatile datastore, the other for generating reports from that data. I will put together a more formal list of features / requirements over the next few days. Thoughts? -----Original Message----- From: Mark Doliner [mailto:Mar...@sa...]=20 Sent: Tuesday, May 10, 2005 12:03 PM To: Jody Brownell Cc: cob...@li... Subject: RE: [Cobertura-devel] How can I get involved.... *snip* > Anywho - the purpose of this email is to see how I can get=20 > involved. One > gap in the product which I noticed (and may already be planned) is > coverage statistics over time. I was thinking, unless this is on > someone's plate already I could start to get familiar with=20 > the code base > and put together a plan of attack - an impact of sorts - and=20 > propose to > you all. *snip* > Please let me know if this is of interest. BTW - what is the typical > process of getting involved? Hope I am not jumping the gun. You're not jumping the gun at all. I suppose the typical process of getting involved is to find something you're interested in fixing/improving/adding and writing a patch for it. I don't know of anyone working on statistics over time. And it's definitely something that would be nice to have. You would definitely want to work with CVS, if you plan on making any changes. Some of the stuff I mention below applies to CVS but not to the last release. I guess the easy way to do it would be to name the XML reports based on the date and time they were created, and then you could parse a directory of these files and determine the change over time. This wouldn't even need to be a part of Cobertura--it could be a completely separate program. Or maybe instead of reading the data from the XML reports, you could read it directly from cobertura.ser files. (The ser file contains basically the same information as the XML reports. The ser file contains serialized classes from the package net.sourceforge.cobertura.coveragedata. If you choose to go this route, you would need to use these classes to read the serialized file.) However, it might be better to modify the classes in the coveragedata package to natively support a time and date. I'm not sure how this would work exactly. Maybe you could tag the information in the ser file with a datestamp and then zero it out before running the next batch of tests. I think it is important that this have a good user interface. How would the statistics be displayed? As a line graph, maybe? How would the user tell Cobertura to create these reports? Would they specify a "start date" and "end date"? Would the report have a separate display for each package? For each class? Would it have a way to show differences in the source files? Does that help you, any? -Mark |
|
From: Mark D. <Mar...@sa...> - 2005-05-17 19:40:57
|
It sounds like you have a good idea of what you want to do. I would be = careful to try to keep the data harvesting and the report generation rea= sonably separate from each other. Why? Because historical "change in c= overage over time" graphs would be really cool, and I think it's somethi= ng that could be an impressive addition to Cobertura. If it WAS made a = part of Cobertura, it seems likely that the data harvesting parts of you= r code would need lots of changes, but hopefully the report generation s= tuff could remain largely unchanged. -Mark > -----Original Message----- > From: Jody Brownell [mailto:jod...@Q1...] > Sent: Friday, May 13, 2005 6:56 AM > To: Mark Doliner > Cc: cob...@li...; Adam Morgan > Subject: RE: [Cobertura-devel] How can I get involved.... > > Sure does - thanks. > > My first thoughts were - this could be an addon package/application of > sorts which can use your .ser file or the XML reports (once > successfully > completed). I would prefer to not touch your guys code at all if > possible and just piggy back on what you have - make enhancements if > required. > > This implies that, the way users run cobertura now would not change at > all - providing a single user mode of sorts. Then the new additional > task (ant?) could be run to export that data to a central or non > volatile data store. (Data store could be RDBMS, flat file or > what have > you - makes no difference to me - as long as simple and fast). > > Key things for me are, it needs to be extremely simple to install and > maintain. No over complicated configuration etc - keep it as > it is today > as much as possible. > > Agree about the UI - has to be clean, intuitive, simple and fast. > > - Be nice to view reports on product? / project / package / > class / ... > hierarchy - as you navigate through the hierarchy - > graph/plot for where > you are > - plotting lines of code / coverage over time (Jfreechart has > some great > plots) > - Need to identify and ensure we have the right data in the > datastore. A > few reports which come to mind are > - plain coverage stats > - plain coverage stats plotted against lines of code > - coverage stats of one project/package/class plotted against the > baseline coverage of all projects (how does this project/package/class > compare to the running average) ( more advanced :)) > > For now - I will focus on keeping it simple with two additional ant > tasks, one for exporting/updating to non volatile datastore, the other > for generating reports from that data. I will put together a > more formal > list of features / requirements over the next few days. > > Thoughts? > > -----Original Message----- > From: Mark Doliner [mailto:Mar...@sa...] > Sent: Tuesday, May 10, 2005 12:03 PM > To: Jody Brownell > Cc: cob...@li... > Subject: RE: [Cobertura-devel] How can I get involved.... > > *snip* > > > Anywho - the purpose of this email is to see how I can get > > involved. One > > gap in the product which I noticed (and may already be planned) is > > coverage statistics over time. I was thinking, unless this is on > > someone's plate already I could start to get familiar with > > the code base > > and put together a plan of attack - an impact of sorts - and > > propose to > > you all. > > *snip* > > > Please let me know if this is of interest. BTW - what is the typical > > process of getting involved? Hope I am not jumping the gun. > > You're not jumping the gun at all. I suppose the typical process of > getting involved is to find something you're interested in > fixing/improving/adding and writing a patch for it. I don't know of > anyone working on statistics over time. And it's definitely something > that would be nice to have. You would definitely want to > work with CVS, > if you plan on making any changes. Some of the stuff I mention below > applies to CVS but not to the last release. > > I guess the easy way to do it would be to name the XML > reports based on > the date and time they were created, and then you could parse a > directory of these files and determine the change over time. This > wouldn't even need to be a part of Cobertura--it could be a completely > separate program. Or maybe instead of reading the data from the XML > reports, you could read it directly from cobertura.ser files. > (The ser > file contains basically the same information as the XML reports. The > ser file contains serialized classes from the package > net.sourceforge.cobertura.coveragedata. If you choose to go > this route, > you would need to use these classes to read the serialized file.) > > However, it might be better to modify the classes in the coveragedata > package to natively support a time and date. I'm not sure how this > would work exactly. Maybe you could tag the information in > the ser file > with a datestamp and then zero it out before running the next batch of > tests. > > I think it is important that this have a good user interface. > How would > the statistics be displayed? As a line graph, maybe? How would the > user tell Cobertura to create these reports? Would they specify a > "start date" and "end date"? Would the report have a separate display > for each package? For each class? Would it have a way to show > differences in the source files? > > Does that help you, any? > > -Mark > |
|
From: Jody B. <jod...@Q1...> - 2005-05-17 19:55:22
|
Agreed... Plan is to make it part of cobertura - assuming you accept the patches etc :) I have to get few a number of items at work, then I will start. I will be in touch shortly.=20 BTW - is there anything major happening now on HEAD in cvs? -----Original Message----- From: Mark Doliner [mailto:Mar...@sa...]=20 Sent: Tuesday, May 17, 2005 4:41 PM To: Jody Brownell Cc: cob...@li...; Adam Morgan Subject: RE: [Cobertura-devel] How can I get involved.... It sounds like you have a good idea of what you want to do. I would be careful to try to keep the data harvesting and the report generation reasonably separate from each other. Why? Because historical "change in coverage over time" graphs would be really cool, and I think it's something that could be an impressive addition to Cobertura. If it WAS made a part of Cobertura, it seems likely that the data harvesting parts of your code would need lots of changes, but hopefully the report generation stuff could remain largely unchanged. -Mark=20 > -----Original Message----- > From: Jody Brownell [mailto:jod...@Q1...]=20 > Sent: Friday, May 13, 2005 6:56 AM > To: Mark Doliner > Cc: cob...@li...; Adam Morgan > Subject: RE: [Cobertura-devel] How can I get involved.... >=20 > Sure does - thanks. >=20 > My first thoughts were - this could be an addon package/application of > sorts which can use your .ser file or the XML reports (once=20 > successfully > completed). I would prefer to not touch your guys code at all if > possible and just piggy back on what you have - make enhancements if > required. >=20 > This implies that, the way users run cobertura now would not change at > all - providing a single user mode of sorts. Then the new additional > task (ant?) could be run to export that data to a central or non > volatile data store. (Data store could be RDBMS, flat file or=20 > what have > you - makes no difference to me - as long as simple and fast). >=20 > Key things for me are, it needs to be extremely simple to install and > maintain. No over complicated configuration etc - keep it as=20 > it is today > as much as possible. >=20 > Agree about the UI - has to be clean, intuitive, simple and fast.=20 >=20 > - Be nice to view reports on product? / project / package /=20 > class / ... > hierarchy - as you navigate through the hierarchy -=20 > graph/plot for where > you are > - plotting lines of code / coverage over time (Jfreechart has=20 > some great > plots) > - Need to identify and ensure we have the right data in the=20 > datastore. A > few reports which come to mind are > - plain coverage stats > - plain coverage stats plotted against lines of code > - coverage stats of one project/package/class plotted against the > baseline coverage of all projects (how does this project/package/class > compare to the running average) ( more advanced :)) >=20 > For now - I will focus on keeping it simple with two additional ant > tasks, one for exporting/updating to non volatile datastore, the other > for generating reports from that data. I will put together a=20 > more formal > list of features / requirements over the next few days. >=20 > Thoughts? >=20 > -----Original Message----- > From: Mark Doliner [mailto:Mar...@sa...]=20 > Sent: Tuesday, May 10, 2005 12:03 PM > To: Jody Brownell > Cc: cob...@li... > Subject: RE: [Cobertura-devel] How can I get involved.... >=20 > *snip* >=20 > > Anywho - the purpose of this email is to see how I can get=20 > > involved. One > > gap in the product which I noticed (and may already be planned) is > > coverage statistics over time. I was thinking, unless this is on > > someone's plate already I could start to get familiar with=20 > > the code base > > and put together a plan of attack - an impact of sorts - and=20 > > propose to > > you all. >=20 > *snip* >=20 > > Please let me know if this is of interest. BTW - what is the typical > > process of getting involved? Hope I am not jumping the gun. >=20 > You're not jumping the gun at all. I suppose the typical process of > getting involved is to find something you're interested in > fixing/improving/adding and writing a patch for it. I don't know of > anyone working on statistics over time. And it's definitely something > that would be nice to have. You would definitely want to=20 > work with CVS, > if you plan on making any changes. Some of the stuff I mention below > applies to CVS but not to the last release. >=20 > I guess the easy way to do it would be to name the XML=20 > reports based on > the date and time they were created, and then you could parse a > directory of these files and determine the change over time. This > wouldn't even need to be a part of Cobertura--it could be a completely > separate program. Or maybe instead of reading the data from the XML > reports, you could read it directly from cobertura.ser files.=20 > (The ser > file contains basically the same information as the XML reports. The > ser file contains serialized classes from the package > net.sourceforge.cobertura.coveragedata. If you choose to go=20 > this route, > you would need to use these classes to read the serialized file.) >=20 > However, it might be better to modify the classes in the coveragedata > package to natively support a time and date. I'm not sure how this > would work exactly. Maybe you could tag the information in=20 > the ser file > with a datestamp and then zero it out before running the next batch of > tests. >=20 > I think it is important that this have a good user interface.=20 > How would > the statistics be displayed? As a line graph, maybe? How would the > user tell Cobertura to create these reports? Would they specify a > "start date" and "end date"? Would the report have a separate display > for each package? For each class? Would it have a way to show > differences in the source files? >=20 > Does that help you, any? >=20 > -Mark >=20 |
|
From: Mark D. <Mar...@sa...> - 2005-05-17 19:57:41
|
No, there are no major changes happening in HEAD right now. However, = the changes between 1.2 and HEAD are pretty big--I definitely suggest = developing against CVS HEAD rather than 1.2. -Mark=20 > -----Original Message----- > From: Jody Brownell [mailto:jod...@Q1...]=20 > Sent: Tuesday, May 17, 2005 3:55 PM > To: Mark Doliner > Cc: cob...@li...; Adam Morgan > Subject: RE: [Cobertura-devel] How can I get involved.... >=20 > Agreed... Plan is to make it part of cobertura - assuming you=20 > accept the > patches etc :) I have to get few a number of items at work,=20 > then I will > start. >=20 > I will be in touch shortly.=20 >=20 > BTW - is there anything major happening now on HEAD in cvs? >=20 > -----Original Message----- > From: Mark Doliner [mailto:Mar...@sa...]=20 > Sent: Tuesday, May 17, 2005 4:41 PM > To: Jody Brownell > Cc: cob...@li...; Adam Morgan > Subject: RE: [Cobertura-devel] How can I get involved.... >=20 > It sounds like you have a good idea of what you want to do. =20 > I would be > careful to try to keep the data harvesting and the report generation > reasonably separate from each other. Why? Because historical "change > in coverage over time" graphs would be really cool, and I think it's > something that could be an impressive addition to Cobertura. =20 > If it WAS > made a part of Cobertura, it seems likely that the data=20 > harvesting parts > of your code would need lots of changes, but hopefully the report > generation stuff could remain largely unchanged. >=20 > -Mark=20 >=20 > > -----Original Message----- > > From: Jody Brownell [mailto:jod...@Q1...]=20 > > Sent: Friday, May 13, 2005 6:56 AM > > To: Mark Doliner > > Cc: cob...@li...; Adam Morgan > > Subject: RE: [Cobertura-devel] How can I get involved.... > >=20 > > Sure does - thanks. > >=20 > > My first thoughts were - this could be an addon=20 > package/application of > > sorts which can use your .ser file or the XML reports (once=20 > > successfully > > completed). I would prefer to not touch your guys code at all if > > possible and just piggy back on what you have - make enhancements if > > required. > >=20 > > This implies that, the way users run cobertura now would=20 > not change at > > all - providing a single user mode of sorts. Then the new additional > > task (ant?) could be run to export that data to a central or non > > volatile data store. (Data store could be RDBMS, flat file or=20 > > what have > > you - makes no difference to me - as long as simple and fast). > >=20 > > Key things for me are, it needs to be extremely simple to=20 > install and > > maintain. No over complicated configuration etc - keep it as=20 > > it is today > > as much as possible. > >=20 > > Agree about the UI - has to be clean, intuitive, simple and fast.=20 > >=20 > > - Be nice to view reports on product? / project / package /=20 > > class / ... > > hierarchy - as you navigate through the hierarchy -=20 > > graph/plot for where > > you are > > - plotting lines of code / coverage over time (Jfreechart has=20 > > some great > > plots) > > - Need to identify and ensure we have the right data in the=20 > > datastore. A > > few reports which come to mind are > > - plain coverage stats > > - plain coverage stats plotted against lines of code > > - coverage stats of one project/package/class plotted against the > > baseline coverage of all projects (how does this=20 > project/package/class > > compare to the running average) ( more advanced :)) > >=20 > > For now - I will focus on keeping it simple with two additional ant > > tasks, one for exporting/updating to non volatile=20 > datastore, the other > > for generating reports from that data. I will put together a=20 > > more formal > > list of features / requirements over the next few days. > >=20 > > Thoughts? > >=20 > > -----Original Message----- > > From: Mark Doliner [mailto:Mar...@sa...]=20 > > Sent: Tuesday, May 10, 2005 12:03 PM > > To: Jody Brownell > > Cc: cob...@li... > > Subject: RE: [Cobertura-devel] How can I get involved.... > >=20 > > *snip* > >=20 > > > Anywho - the purpose of this email is to see how I can get=20 > > > involved. One > > > gap in the product which I noticed (and may already be planned) is > > > coverage statistics over time. I was thinking, unless this is on > > > someone's plate already I could start to get familiar with=20 > > > the code base > > > and put together a plan of attack - an impact of sorts - and=20 > > > propose to > > > you all. > >=20 > > *snip* > >=20 > > > Please let me know if this is of interest. BTW - what is=20 > the typical > > > process of getting involved? Hope I am not jumping the gun. > >=20 > > You're not jumping the gun at all. I suppose the typical process of > > getting involved is to find something you're interested in > > fixing/improving/adding and writing a patch for it. I don't know of > > anyone working on statistics over time. And it's=20 > definitely something > > that would be nice to have. You would definitely want to=20 > > work with CVS, > > if you plan on making any changes. Some of the stuff I=20 > mention below > > applies to CVS but not to the last release. > >=20 > > I guess the easy way to do it would be to name the XML=20 > > reports based on > > the date and time they were created, and then you could parse a > > directory of these files and determine the change over time. This > > wouldn't even need to be a part of Cobertura--it could be a=20 > completely > > separate program. Or maybe instead of reading the data from the XML > > reports, you could read it directly from cobertura.ser files.=20 > > (The ser > > file contains basically the same information as the XML=20 > reports. The > > ser file contains serialized classes from the package > > net.sourceforge.cobertura.coveragedata. If you choose to go=20 > > this route, > > you would need to use these classes to read the serialized file.) > >=20 > > However, it might be better to modify the classes in the=20 > coveragedata > > package to natively support a time and date. I'm not sure how this > > would work exactly. Maybe you could tag the information in=20 > > the ser file > > with a datestamp and then zero it out before running the=20 > next batch of > > tests. > >=20 > > I think it is important that this have a good user interface.=20 > > How would > > the statistics be displayed? As a line graph, maybe? How would the > > user tell Cobertura to create these reports? Would they specify a > > "start date" and "end date"? Would the report have a=20 > separate display > > for each package? For each class? Would it have a way to show > > differences in the source files? > >=20 > > Does that help you, any? > >=20 > > -Mark > >=20 >=20 |
|
From: Jeremy R. T. <je...@th...> - 2005-05-17 20:04:06
|
Do we have a proposed release date for 1.3? It seems like we have some pretty significant changes that are awaiting a release. Jeremy Thomerson ----- Original Message ----- From: "Mark Doliner" <Mar...@sa...> To: "Jody Brownell" <jod...@Q1...> Cc: <cob...@li...>; "Adam Morgan" <ada...@Q1...> Sent: Tuesday, May 17, 2005 2:57 PM Subject: RE: [Cobertura-devel] How can I get involved.... No, there are no major changes happening in HEAD right now. However, the changes between 1.2 and HEAD are pretty big--I definitely suggest developing against CVS HEAD rather than 1.2. -Mark > -----Original Message----- > From: Jody Brownell [mailto:jod...@Q1...] > Sent: Tuesday, May 17, 2005 3:55 PM > To: Mark Doliner > Cc: cob...@li...; Adam Morgan > Subject: RE: [Cobertura-devel] How can I get involved.... > > Agreed... Plan is to make it part of cobertura - assuming you > accept the > patches etc :) I have to get few a number of items at work, > then I will > start. > > I will be in touch shortly. > > BTW - is there anything major happening now on HEAD in cvs? > > -----Original Message----- > From: Mark Doliner [mailto:Mar...@sa...] > Sent: Tuesday, May 17, 2005 4:41 PM > To: Jody Brownell > Cc: cob...@li...; Adam Morgan > Subject: RE: [Cobertura-devel] How can I get involved.... > > It sounds like you have a good idea of what you want to do. > I would be > careful to try to keep the data harvesting and the report generation > reasonably separate from each other. Why? Because historical "change > in coverage over time" graphs would be really cool, and I think it's > something that could be an impressive addition to Cobertura. > If it WAS > made a part of Cobertura, it seems likely that the data > harvesting parts > of your code would need lots of changes, but hopefully the report > generation stuff could remain largely unchanged. > > -Mark > > > -----Original Message----- > > From: Jody Brownell [mailto:jod...@Q1...] > > Sent: Friday, May 13, 2005 6:56 AM > > To: Mark Doliner > > Cc: cob...@li...; Adam Morgan > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > Sure does - thanks. > > > > My first thoughts were - this could be an addon > package/application of > > sorts which can use your .ser file or the XML reports (once > > successfully > > completed). I would prefer to not touch your guys code at all if > > possible and just piggy back on what you have - make enhancements if > > required. > > > > This implies that, the way users run cobertura now would > not change at > > all - providing a single user mode of sorts. Then the new additional > > task (ant?) could be run to export that data to a central or non > > volatile data store. (Data store could be RDBMS, flat file or > > what have > > you - makes no difference to me - as long as simple and fast). > > > > Key things for me are, it needs to be extremely simple to > install and > > maintain. No over complicated configuration etc - keep it as > > it is today > > as much as possible. > > > > Agree about the UI - has to be clean, intuitive, simple and fast. > > > > - Be nice to view reports on product? / project / package / > > class / ... > > hierarchy - as you navigate through the hierarchy - > > graph/plot for where > > you are > > - plotting lines of code / coverage over time (Jfreechart has > > some great > > plots) > > - Need to identify and ensure we have the right data in the > > datastore. A > > few reports which come to mind are > > - plain coverage stats > > - plain coverage stats plotted against lines of code > > - coverage stats of one project/package/class plotted against the > > baseline coverage of all projects (how does this > project/package/class > > compare to the running average) ( more advanced :)) > > > > For now - I will focus on keeping it simple with two additional ant > > tasks, one for exporting/updating to non volatile > datastore, the other > > for generating reports from that data. I will put together a > > more formal > > list of features / requirements over the next few days. > > > > Thoughts? > > > > -----Original Message----- > > From: Mark Doliner [mailto:Mar...@sa...] > > Sent: Tuesday, May 10, 2005 12:03 PM > > To: Jody Brownell > > Cc: cob...@li... > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > *snip* > > > > > Anywho - the purpose of this email is to see how I can get > > > involved. One > > > gap in the product which I noticed (and may already be planned) is > > > coverage statistics over time. I was thinking, unless this is on > > > someone's plate already I could start to get familiar with > > > the code base > > > and put together a plan of attack - an impact of sorts - and > > > propose to > > > you all. > > > > *snip* > > > > > Please let me know if this is of interest. BTW - what is > the typical > > > process of getting involved? Hope I am not jumping the gun. > > > > You're not jumping the gun at all. I suppose the typical process of > > getting involved is to find something you're interested in > > fixing/improving/adding and writing a patch for it. I don't know of > > anyone working on statistics over time. And it's > definitely something > > that would be nice to have. You would definitely want to > > work with CVS, > > if you plan on making any changes. Some of the stuff I > mention below > > applies to CVS but not to the last release. > > > > I guess the easy way to do it would be to name the XML > > reports based on > > the date and time they were created, and then you could parse a > > directory of these files and determine the change over time. This > > wouldn't even need to be a part of Cobertura--it could be a > completely > > separate program. Or maybe instead of reading the data from the XML > > reports, you could read it directly from cobertura.ser files. > > (The ser > > file contains basically the same information as the XML > reports. The > > ser file contains serialized classes from the package > > net.sourceforge.cobertura.coveragedata. If you choose to go > > this route, > > you would need to use these classes to read the serialized file.) > > > > However, it might be better to modify the classes in the > coveragedata > > package to natively support a time and date. I'm not sure how this > > would work exactly. Maybe you could tag the information in > > the ser file > > with a datestamp and then zero it out before running the > next batch of > > tests. > > > > I think it is important that this have a good user interface. > > How would > > the statistics be displayed? As a line graph, maybe? How would the > > user tell Cobertura to create these reports? Would they specify a > > "start date" and "end date"? Would the report have a > separate display > > for each package? For each class? Would it have a way to show > > differences in the source files? > > > > Does that help you, any? > > > > -Mark > > > ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=ick _______________________________________________ Cobertura-devel mailing list Cob...@li... https://lists.sourceforge.net/lists/listinfo/cobertura-devel |
|
From: Mark D. <Mar...@sa...> - 2005-05-17 20:10:13
|
No, but how about Thursday? I was hoping to get the inner-class thing resolved before releasing 1.3, = but I think I would rather release it as-in and then make changes later. What's wrong with inner-classes, you ask? In 1.2 the HTML reports ignored inner-classes, and did not show them as = covered/not covered. In CVS the HTML reports show coverage for inner-classes, but they appear = in a separate HTML page instead of being nestled in with their parent, = like a happy baby bird. Ideally, the coverage for the classes HelloWorld and HelloWorld$1 would = both appear on the same HTML page. In summary, CVS handles this better than 1.2 did, but it's still not = perfect. However, if people agree that it's better to release now and = improve it later, then let's do that. -Mark=20 > -----Original Message----- > From: Jeremy Ryan Thomerson [mailto:je...@th...]=20 > Sent: Tuesday, May 17, 2005 4:03 PM > To: Mark Doliner; Jody Brownell > Cc: cob...@li...; Adam Morgan > Subject: Re: [Cobertura-devel] How can I get involved.... >=20 > Do we have a proposed release date for 1.3? It seems like we=20 > have some > pretty significant changes that are awaiting a release. >=20 > Jeremy Thomerson >=20 > ----- Original Message -----=20 > From: "Mark Doliner" <Mar...@sa...> > To: "Jody Brownell" <jod...@Q1...> > Cc: <cob...@li...>; "Adam Morgan" > <ada...@Q1...> > Sent: Tuesday, May 17, 2005 2:57 PM > Subject: RE: [Cobertura-devel] How can I get involved.... >=20 >=20 > No, there are no major changes happening in HEAD right now. =20 > However, the > changes between 1.2 and HEAD are pretty big--I definitely=20 > suggest developing > against CVS HEAD rather than 1.2. > -Mark >=20 > > -----Original Message----- > > From: Jody Brownell [mailto:jod...@Q1...] > > Sent: Tuesday, May 17, 2005 3:55 PM > > To: Mark Doliner > > Cc: cob...@li...; Adam Morgan > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > Agreed... Plan is to make it part of cobertura - assuming you > > accept the > > patches etc :) I have to get few a number of items at work, > > then I will > > start. > > > > I will be in touch shortly. > > > > BTW - is there anything major happening now on HEAD in cvs? > > > > -----Original Message----- > > From: Mark Doliner [mailto:Mar...@sa...] > > Sent: Tuesday, May 17, 2005 4:41 PM > > To: Jody Brownell > > Cc: cob...@li...; Adam Morgan > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > It sounds like you have a good idea of what you want to do. > > I would be > > careful to try to keep the data harvesting and the report generation > > reasonably separate from each other. Why? Because=20 > historical "change > > in coverage over time" graphs would be really cool, and I think it's > > something that could be an impressive addition to Cobertura. > > If it WAS > > made a part of Cobertura, it seems likely that the data > > harvesting parts > > of your code would need lots of changes, but hopefully the report > > generation stuff could remain largely unchanged. > > > > -Mark > > > > > -----Original Message----- > > > From: Jody Brownell [mailto:jod...@Q1...] > > > Sent: Friday, May 13, 2005 6:56 AM > > > To: Mark Doliner > > > Cc: cob...@li...; Adam Morgan > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > Sure does - thanks. > > > > > > My first thoughts were - this could be an addon > > package/application of > > > sorts which can use your .ser file or the XML reports (once > > > successfully > > > completed). I would prefer to not touch your guys code at all if > > > possible and just piggy back on what you have - make=20 > enhancements if > > > required. > > > > > > This implies that, the way users run cobertura now would > > not change at > > > all - providing a single user mode of sorts. Then the new=20 > additional > > > task (ant?) could be run to export that data to a central or non > > > volatile data store. (Data store could be RDBMS, flat file or > > > what have > > > you - makes no difference to me - as long as simple and fast). > > > > > > Key things for me are, it needs to be extremely simple to > > install and > > > maintain. No over complicated configuration etc - keep it as > > > it is today > > > as much as possible. > > > > > > Agree about the UI - has to be clean, intuitive, simple and fast. > > > > > > - Be nice to view reports on product? / project / package / > > > class / ... > > > hierarchy - as you navigate through the hierarchy - > > > graph/plot for where > > > you are > > > - plotting lines of code / coverage over time (Jfreechart has > > > some great > > > plots) > > > - Need to identify and ensure we have the right data in the > > > datastore. A > > > few reports which come to mind are > > > - plain coverage stats > > > - plain coverage stats plotted against lines of code > > > - coverage stats of one project/package/class plotted=20 > against the > > > baseline coverage of all projects (how does this > > project/package/class > > > compare to the running average) ( more advanced :)) > > > > > > For now - I will focus on keeping it simple with two=20 > additional ant > > > tasks, one for exporting/updating to non volatile > > datastore, the other > > > for generating reports from that data. I will put together a > > > more formal > > > list of features / requirements over the next few days. > > > > > > Thoughts? > > > > > > -----Original Message----- > > > From: Mark Doliner [mailto:Mar...@sa...] > > > Sent: Tuesday, May 10, 2005 12:03 PM > > > To: Jody Brownell > > > Cc: cob...@li... > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > *snip* > > > > > > > Anywho - the purpose of this email is to see how I can get > > > > involved. One > > > > gap in the product which I noticed (and may already be=20 > planned) is > > > > coverage statistics over time. I was thinking, unless this is on > > > > someone's plate already I could start to get familiar with > > > > the code base > > > > and put together a plan of attack - an impact of sorts - and > > > > propose to > > > > you all. > > > > > > *snip* > > > > > > > Please let me know if this is of interest. BTW - what is > > the typical > > > > process of getting involved? Hope I am not jumping the gun. > > > > > > You're not jumping the gun at all. I suppose the typical=20 > process of > > > getting involved is to find something you're interested in > > > fixing/improving/adding and writing a patch for it. I=20 > don't know of > > > anyone working on statistics over time. And it's > > definitely something > > > that would be nice to have. You would definitely want to > > > work with CVS, > > > if you plan on making any changes. Some of the stuff I > > mention below > > > applies to CVS but not to the last release. > > > > > > I guess the easy way to do it would be to name the XML > > > reports based on > > > the date and time they were created, and then you could parse a > > > directory of these files and determine the change over time. This > > > wouldn't even need to be a part of Cobertura--it could be a > > completely > > > separate program. Or maybe instead of reading the data=20 > from the XML > > > reports, you could read it directly from cobertura.ser files. > > > (The ser > > > file contains basically the same information as the XML > > reports. The > > > ser file contains serialized classes from the package > > > net.sourceforge.cobertura.coveragedata. If you choose to go > > > this route, > > > you would need to use these classes to read the serialized file.) > > > > > > However, it might be better to modify the classes in the > > coveragedata > > > package to natively support a time and date. I'm not=20 > sure how this > > > would work exactly. Maybe you could tag the information in > > > the ser file > > > with a datestamp and then zero it out before running the > > next batch of > > > tests. > > > > > > I think it is important that this have a good user interface. > > > How would > > > the statistics be displayed? As a line graph, maybe? =20 > How would the > > > user tell Cobertura to create these reports? Would they specify a > > > "start date" and "end date"? Would the report have a > > separate display > > > for each package? For each class? Would it have a way to show > > > differences in the source files? > > > > > > Does that help you, any? > > > > > > -Mark > > > > > >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dick > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel >=20 >=20 >=20 >=20 |
|
From: Jeremy R. T. <je...@th...> - 2005-05-17 20:13:44
|
I'd agree that it's better as described, and ready for release. I'll take a look at it this PM, too, to see if I see any easy fix. JT ----- Original Message ----- From: "Mark Doliner" <Mar...@sa...> To: "Jeremy Ryan Thomerson" <je...@th...>; "Jody Brownell" <jod...@Q1...> Cc: <cob...@li...>; "Adam Morgan" <ada...@Q1...> Sent: Tuesday, May 17, 2005 3:10 PM Subject: RE: [Cobertura-devel] How can I get involved.... No, but how about Thursday? I was hoping to get the inner-class thing resolved before releasing 1.3, but I think I would rather release it as-in and then make changes later. What's wrong with inner-classes, you ask? In 1.2 the HTML reports ignored inner-classes, and did not show them as covered/not covered. In CVS the HTML reports show coverage for inner-classes, but they appear in a separate HTML page instead of being nestled in with their parent, like a happy baby bird. Ideally, the coverage for the classes HelloWorld and HelloWorld$1 would both appear on the same HTML page. In summary, CVS handles this better than 1.2 did, but it's still not perfect. However, if people agree that it's better to release now and improve it later, then let's do that. -Mark > -----Original Message----- > From: Jeremy Ryan Thomerson [mailto:je...@th...] > Sent: Tuesday, May 17, 2005 4:03 PM > To: Mark Doliner; Jody Brownell > Cc: cob...@li...; Adam Morgan > Subject: Re: [Cobertura-devel] How can I get involved.... > > Do we have a proposed release date for 1.3? It seems like we > have some > pretty significant changes that are awaiting a release. > > Jeremy Thomerson > > ----- Original Message ----- > From: "Mark Doliner" <Mar...@sa...> > To: "Jody Brownell" <jod...@Q1...> > Cc: <cob...@li...>; "Adam Morgan" > <ada...@Q1...> > Sent: Tuesday, May 17, 2005 2:57 PM > Subject: RE: [Cobertura-devel] How can I get involved.... > > > No, there are no major changes happening in HEAD right now. > However, the > changes between 1.2 and HEAD are pretty big--I definitely > suggest developing > against CVS HEAD rather than 1.2. > -Mark > > > -----Original Message----- > > From: Jody Brownell [mailto:jod...@Q1...] > > Sent: Tuesday, May 17, 2005 3:55 PM > > To: Mark Doliner > > Cc: cob...@li...; Adam Morgan > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > Agreed... Plan is to make it part of cobertura - assuming you > > accept the > > patches etc :) I have to get few a number of items at work, > > then I will > > start. > > > > I will be in touch shortly. > > > > BTW - is there anything major happening now on HEAD in cvs? > > > > -----Original Message----- > > From: Mark Doliner [mailto:Mar...@sa...] > > Sent: Tuesday, May 17, 2005 4:41 PM > > To: Jody Brownell > > Cc: cob...@li...; Adam Morgan > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > It sounds like you have a good idea of what you want to do. > > I would be > > careful to try to keep the data harvesting and the report generation > > reasonably separate from each other. Why? Because > historical "change > > in coverage over time" graphs would be really cool, and I think it's > > something that could be an impressive addition to Cobertura. > > If it WAS > > made a part of Cobertura, it seems likely that the data > > harvesting parts > > of your code would need lots of changes, but hopefully the report > > generation stuff could remain largely unchanged. > > > > -Mark > > > > > -----Original Message----- > > > From: Jody Brownell [mailto:jod...@Q1...] > > > Sent: Friday, May 13, 2005 6:56 AM > > > To: Mark Doliner > > > Cc: cob...@li...; Adam Morgan > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > Sure does - thanks. > > > > > > My first thoughts were - this could be an addon > > package/application of > > > sorts which can use your .ser file or the XML reports (once > > > successfully > > > completed). I would prefer to not touch your guys code at all if > > > possible and just piggy back on what you have - make > enhancements if > > > required. > > > > > > This implies that, the way users run cobertura now would > > not change at > > > all - providing a single user mode of sorts. Then the new > additional > > > task (ant?) could be run to export that data to a central or non > > > volatile data store. (Data store could be RDBMS, flat file or > > > what have > > > you - makes no difference to me - as long as simple and fast). > > > > > > Key things for me are, it needs to be extremely simple to > > install and > > > maintain. No over complicated configuration etc - keep it as > > > it is today > > > as much as possible. > > > > > > Agree about the UI - has to be clean, intuitive, simple and fast. > > > > > > - Be nice to view reports on product? / project / package / > > > class / ... > > > hierarchy - as you navigate through the hierarchy - > > > graph/plot for where > > > you are > > > - plotting lines of code / coverage over time (Jfreechart has > > > some great > > > plots) > > > - Need to identify and ensure we have the right data in the > > > datastore. A > > > few reports which come to mind are > > > - plain coverage stats > > > - plain coverage stats plotted against lines of code > > > - coverage stats of one project/package/class plotted > against the > > > baseline coverage of all projects (how does this > > project/package/class > > > compare to the running average) ( more advanced :)) > > > > > > For now - I will focus on keeping it simple with two > additional ant > > > tasks, one for exporting/updating to non volatile > > datastore, the other > > > for generating reports from that data. I will put together a > > > more formal > > > list of features / requirements over the next few days. > > > > > > Thoughts? > > > > > > -----Original Message----- > > > From: Mark Doliner [mailto:Mar...@sa...] > > > Sent: Tuesday, May 10, 2005 12:03 PM > > > To: Jody Brownell > > > Cc: cob...@li... > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > *snip* > > > > > > > Anywho - the purpose of this email is to see how I can get > > > > involved. One > > > > gap in the product which I noticed (and may already be > planned) is > > > > coverage statistics over time. I was thinking, unless this is on > > > > someone's plate already I could start to get familiar with > > > > the code base > > > > and put together a plan of attack - an impact of sorts - and > > > > propose to > > > > you all. > > > > > > *snip* > > > > > > > Please let me know if this is of interest. BTW - what is > > the typical > > > > process of getting involved? Hope I am not jumping the gun. > > > > > > You're not jumping the gun at all. I suppose the typical > process of > > > getting involved is to find something you're interested in > > > fixing/improving/adding and writing a patch for it. I > don't know of > > > anyone working on statistics over time. And it's > > definitely something > > > that would be nice to have. You would definitely want to > > > work with CVS, > > > if you plan on making any changes. Some of the stuff I > > mention below > > > applies to CVS but not to the last release. > > > > > > I guess the easy way to do it would be to name the XML > > > reports based on > > > the date and time they were created, and then you could parse a > > > directory of these files and determine the change over time. This > > > wouldn't even need to be a part of Cobertura--it could be a > > completely > > > separate program. Or maybe instead of reading the data > from the XML > > > reports, you could read it directly from cobertura.ser files. > > > (The ser > > > file contains basically the same information as the XML > > reports. The > > > ser file contains serialized classes from the package > > > net.sourceforge.cobertura.coveragedata. If you choose to go > > > this route, > > > you would need to use these classes to read the serialized file.) > > > > > > However, it might be better to modify the classes in the > > coveragedata > > > package to natively support a time and date. I'm not > sure how this > > > would work exactly. Maybe you could tag the information in > > > the ser file > > > with a datestamp and then zero it out before running the > > next batch of > > > tests. > > > > > > I think it is important that this have a good user interface. > > > How would > > > the statistics be displayed? As a line graph, maybe? > How would the > > > user tell Cobertura to create these reports? Would they specify a > > > "start date" and "end date"? Would the report have a > > separate display > > > for each package? For each class? Would it have a way to show > > > differences in the source files? > > > > > > Does that help you, any? > > > > > > -Mark > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_idt12&alloc_id344&op=ick > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > > > |
|
From: Jeremy T. <je...@th...> - 2005-05-18 05:33:30
|
I just committed the necessary changes to accomodate "coverage for the classes HelloWorld and HelloWorld$1 would both appear on the same HTML page". It also removed the map of classes maintained in ProjectData since we're already maintaining all of our classes in individual PackageData instances. Granted, it would've been handy to continue hanging on to ClassData instances in ProjectData, but it would have required copy and paste logic from PackageData determining how to aggregrate data from inner classes into its parent class. I really hate copy and paste wcode, so I refactored it to avoid needing it. However, I think the better way to refactor this in the future is have an object whose job it is to hold on to multiple ClassData instances, and it can be the only place that contains the aggregration logic. Maybe? It's late enough for now. Hope this was what you were looking for Mark. Let me know if it's not. I can back out my changes. Jeremy Thomerson eBay ----- Original Message ----- From: "Mark Doliner" <Mar...@sa...> To: "Jeremy Ryan Thomerson" <je...@th...>; "Jody Brownell" <jod...@Q1...> Cc: <cob...@li...>; "Adam Morgan" <ada...@Q1...> Sent: Tuesday, May 17, 2005 1:10 PM Subject: RE: [Cobertura-devel] How can I get involved.... No, but how about Thursday? I was hoping to get the inner-class thing resolved before releasing 1.3, but I think I would rather release it as-in and then make changes later. What's wrong with inner-classes, you ask? In 1.2 the HTML reports ignored inner-classes, and did not show them as covered/not covered. In CVS the HTML reports show coverage for inner-classes, but they appear in a separate HTML page instead of being nestled in with their parent, like a happy baby bird. Ideally, the coverage for the classes HelloWorld and HelloWorld$1 would both appear on the same HTML page. In summary, CVS handles this better than 1.2 did, but it's still not perfect. However, if people agree that it's better to release now and improve it later, then let's do that. -Mark > -----Original Message----- > From: Jeremy Ryan Thomerson [mailto:je...@th...] > Sent: Tuesday, May 17, 2005 4:03 PM > To: Mark Doliner; Jody Brownell > Cc: cob...@li...; Adam Morgan > Subject: Re: [Cobertura-devel] How can I get involved.... > > Do we have a proposed release date for 1.3? It seems like we > have some > pretty significant changes that are awaiting a release. > > Jeremy Thomerson > > ----- Original Message ----- > From: "Mark Doliner" <Mar...@sa...> > To: "Jody Brownell" <jod...@Q1...> > Cc: <cob...@li...>; "Adam Morgan" > <ada...@Q1...> > Sent: Tuesday, May 17, 2005 2:57 PM > Subject: RE: [Cobertura-devel] How can I get involved.... > > > No, there are no major changes happening in HEAD right now. > However, the > changes between 1.2 and HEAD are pretty big--I definitely > suggest developing > against CVS HEAD rather than 1.2. > -Mark > > > -----Original Message----- > > From: Jody Brownell [mailto:jod...@Q1...] > > Sent: Tuesday, May 17, 2005 3:55 PM > > To: Mark Doliner > > Cc: cob...@li...; Adam Morgan > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > Agreed... Plan is to make it part of cobertura - assuming you > > accept the > > patches etc :) I have to get few a number of items at work, > > then I will > > start. > > > > I will be in touch shortly. > > > > BTW - is there anything major happening now on HEAD in cvs? > > > > -----Original Message----- > > From: Mark Doliner [mailto:Mar...@sa...] > > Sent: Tuesday, May 17, 2005 4:41 PM > > To: Jody Brownell > > Cc: cob...@li...; Adam Morgan > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > It sounds like you have a good idea of what you want to do. > > I would be > > careful to try to keep the data harvesting and the report generation > > reasonably separate from each other. Why? Because > historical "change > > in coverage over time" graphs would be really cool, and I think it's > > something that could be an impressive addition to Cobertura. > > If it WAS > > made a part of Cobertura, it seems likely that the data > > harvesting parts > > of your code would need lots of changes, but hopefully the report > > generation stuff could remain largely unchanged. > > > > -Mark > > > > > -----Original Message----- > > > From: Jody Brownell [mailto:jod...@Q1...] > > > Sent: Friday, May 13, 2005 6:56 AM > > > To: Mark Doliner > > > Cc: cob...@li...; Adam Morgan > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > Sure does - thanks. > > > > > > My first thoughts were - this could be an addon > > package/application of > > > sorts which can use your .ser file or the XML reports (once > > > successfully > > > completed). I would prefer to not touch your guys code at all if > > > possible and just piggy back on what you have - make > enhancements if > > > required. > > > > > > This implies that, the way users run cobertura now would > > not change at > > > all - providing a single user mode of sorts. Then the new > additional > > > task (ant?) could be run to export that data to a central or non > > > volatile data store. (Data store could be RDBMS, flat file or > > > what have > > > you - makes no difference to me - as long as simple and fast). > > > > > > Key things for me are, it needs to be extremely simple to > > install and > > > maintain. No over complicated configuration etc - keep it as > > > it is today > > > as much as possible. > > > > > > Agree about the UI - has to be clean, intuitive, simple and fast. > > > > > > - Be nice to view reports on product? / project / package / > > > class / ... > > > hierarchy - as you navigate through the hierarchy - > > > graph/plot for where > > > you are > > > - plotting lines of code / coverage over time (Jfreechart has > > > some great > > > plots) > > > - Need to identify and ensure we have the right data in the > > > datastore. A > > > few reports which come to mind are > > > - plain coverage stats > > > - plain coverage stats plotted against lines of code > > > - coverage stats of one project/package/class plotted > against the > > > baseline coverage of all projects (how does this > > project/package/class > > > compare to the running average) ( more advanced :)) > > > > > > For now - I will focus on keeping it simple with two > additional ant > > > tasks, one for exporting/updating to non volatile > > datastore, the other > > > for generating reports from that data. I will put together a > > > more formal > > > list of features / requirements over the next few days. > > > > > > Thoughts? > > > > > > -----Original Message----- > > > From: Mark Doliner [mailto:Mar...@sa...] > > > Sent: Tuesday, May 10, 2005 12:03 PM > > > To: Jody Brownell > > > Cc: cob...@li... > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > *snip* > > > > > > > Anywho - the purpose of this email is to see how I can get > > > > involved. One > > > > gap in the product which I noticed (and may already be > planned) is > > > > coverage statistics over time. I was thinking, unless this is on > > > > someone's plate already I could start to get familiar with > > > > the code base > > > > and put together a plan of attack - an impact of sorts - and > > > > propose to > > > > you all. > > > > > > *snip* > > > > > > > Please let me know if this is of interest. BTW - what is > > the typical > > > > process of getting involved? Hope I am not jumping the gun. > > > > > > You're not jumping the gun at all. I suppose the typical > process of > > > getting involved is to find something you're interested in > > > fixing/improving/adding and writing a patch for it. I > don't know of > > > anyone working on statistics over time. And it's > > definitely something > > > that would be nice to have. You would definitely want to > > > work with CVS, > > > if you plan on making any changes. Some of the stuff I > > mention below > > > applies to CVS but not to the last release. > > > > > > I guess the easy way to do it would be to name the XML > > > reports based on > > > the date and time they were created, and then you could parse a > > > directory of these files and determine the change over time. This > > > wouldn't even need to be a part of Cobertura--it could be a > > completely > > > separate program. Or maybe instead of reading the data > from the XML > > > reports, you could read it directly from cobertura.ser files. > > > (The ser > > > file contains basically the same information as the XML > > reports. The > > > ser file contains serialized classes from the package > > > net.sourceforge.cobertura.coveragedata. If you choose to go > > > this route, > > > you would need to use these classes to read the serialized file.) > > > > > > However, it might be better to modify the classes in the > > coveragedata > > > package to natively support a time and date. I'm not > sure how this > > > would work exactly. Maybe you could tag the information in > > > the ser file > > > with a datestamp and then zero it out before running the > > next batch of > > > tests. > > > > > > I think it is important that this have a good user interface. > > > How would > > > the statistics be displayed? As a line graph, maybe? > How would the > > > user tell Cobertura to create these reports? Would they specify a > > > "start date" and "end date"? Would the report have a > > separate display > > > for each package? For each class? Would it have a way to show > > > differences in the source files? > > > > > > Does that help you, any? > > > > > > -Mark > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_idt12&alloc_id344&op=ick > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > > > ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=ick _______________________________________________ Cobertura-devel mailing list Cob...@li... https://lists.sourceforge.net/lists/listinfo/cobertura-devel |
|
From: Jody B. <jod...@Q1...> - 2005-05-17 23:54:36
|
BTW - what is the target JDK for cobertura? Just wondering what I version of the JDK I can introduce dependencies for if I need to.... cheers -----Original Message----- From: Mark Doliner [mailto:Mar...@sa...]=20 Sent: Tuesday, May 17, 2005 4:58 PM To: Jody Brownell Cc: cob...@li...; Adam Morgan Subject: RE: [Cobertura-devel] How can I get involved.... No, there are no major changes happening in HEAD right now. However, the changes between 1.2 and HEAD are pretty big--I definitely suggest developing against CVS HEAD rather than 1.2. -Mark=20 > -----Original Message----- > From: Jody Brownell [mailto:jod...@Q1...]=20 > Sent: Tuesday, May 17, 2005 3:55 PM > To: Mark Doliner > Cc: cob...@li...; Adam Morgan > Subject: RE: [Cobertura-devel] How can I get involved.... >=20 > Agreed... Plan is to make it part of cobertura - assuming you=20 > accept the > patches etc :) I have to get few a number of items at work,=20 > then I will > start. >=20 > I will be in touch shortly.=20 >=20 > BTW - is there anything major happening now on HEAD in cvs? >=20 > -----Original Message----- > From: Mark Doliner [mailto:Mar...@sa...]=20 > Sent: Tuesday, May 17, 2005 4:41 PM > To: Jody Brownell > Cc: cob...@li...; Adam Morgan > Subject: RE: [Cobertura-devel] How can I get involved.... >=20 > It sounds like you have a good idea of what you want to do. =20 > I would be > careful to try to keep the data harvesting and the report generation > reasonably separate from each other. Why? Because historical "change > in coverage over time" graphs would be really cool, and I think it's > something that could be an impressive addition to Cobertura. =20 > If it WAS > made a part of Cobertura, it seems likely that the data=20 > harvesting parts > of your code would need lots of changes, but hopefully the report > generation stuff could remain largely unchanged. >=20 > -Mark=20 >=20 > > -----Original Message----- > > From: Jody Brownell [mailto:jod...@Q1...]=20 > > Sent: Friday, May 13, 2005 6:56 AM > > To: Mark Doliner > > Cc: cob...@li...; Adam Morgan > > Subject: RE: [Cobertura-devel] How can I get involved.... > >=20 > > Sure does - thanks. > >=20 > > My first thoughts were - this could be an addon=20 > package/application of > > sorts which can use your .ser file or the XML reports (once=20 > > successfully > > completed). I would prefer to not touch your guys code at all if > > possible and just piggy back on what you have - make enhancements if > > required. > >=20 > > This implies that, the way users run cobertura now would=20 > not change at > > all - providing a single user mode of sorts. Then the new additional > > task (ant?) could be run to export that data to a central or non > > volatile data store. (Data store could be RDBMS, flat file or=20 > > what have > > you - makes no difference to me - as long as simple and fast). > >=20 > > Key things for me are, it needs to be extremely simple to=20 > install and > > maintain. No over complicated configuration etc - keep it as=20 > > it is today > > as much as possible. > >=20 > > Agree about the UI - has to be clean, intuitive, simple and fast.=20 > >=20 > > - Be nice to view reports on product? / project / package /=20 > > class / ... > > hierarchy - as you navigate through the hierarchy -=20 > > graph/plot for where > > you are > > - plotting lines of code / coverage over time (Jfreechart has=20 > > some great > > plots) > > - Need to identify and ensure we have the right data in the=20 > > datastore. A > > few reports which come to mind are > > - plain coverage stats > > - plain coverage stats plotted against lines of code > > - coverage stats of one project/package/class plotted against the > > baseline coverage of all projects (how does this=20 > project/package/class > > compare to the running average) ( more advanced :)) > >=20 > > For now - I will focus on keeping it simple with two additional ant > > tasks, one for exporting/updating to non volatile=20 > datastore, the other > > for generating reports from that data. I will put together a=20 > > more formal > > list of features / requirements over the next few days. > >=20 > > Thoughts? > >=20 > > -----Original Message----- > > From: Mark Doliner [mailto:Mar...@sa...]=20 > > Sent: Tuesday, May 10, 2005 12:03 PM > > To: Jody Brownell > > Cc: cob...@li... > > Subject: RE: [Cobertura-devel] How can I get involved.... > >=20 > > *snip* > >=20 > > > Anywho - the purpose of this email is to see how I can get=20 > > > involved. One > > > gap in the product which I noticed (and may already be planned) is > > > coverage statistics over time. I was thinking, unless this is on > > > someone's plate already I could start to get familiar with=20 > > > the code base > > > and put together a plan of attack - an impact of sorts - and=20 > > > propose to > > > you all. > >=20 > > *snip* > >=20 > > > Please let me know if this is of interest. BTW - what is=20 > the typical > > > process of getting involved? Hope I am not jumping the gun. > >=20 > > You're not jumping the gun at all. I suppose the typical process of > > getting involved is to find something you're interested in > > fixing/improving/adding and writing a patch for it. I don't know of > > anyone working on statistics over time. And it's=20 > definitely something > > that would be nice to have. You would definitely want to=20 > > work with CVS, > > if you plan on making any changes. Some of the stuff I=20 > mention below > > applies to CVS but not to the last release. > >=20 > > I guess the easy way to do it would be to name the XML=20 > > reports based on > > the date and time they were created, and then you could parse a > > directory of these files and determine the change over time. This > > wouldn't even need to be a part of Cobertura--it could be a=20 > completely > > separate program. Or maybe instead of reading the data from the XML > > reports, you could read it directly from cobertura.ser files.=20 > > (The ser > > file contains basically the same information as the XML=20 > reports. The > > ser file contains serialized classes from the package > > net.sourceforge.cobertura.coveragedata. If you choose to go=20 > > this route, > > you would need to use these classes to read the serialized file.) > >=20 > > However, it might be better to modify the classes in the=20 > coveragedata > > package to natively support a time and date. I'm not sure how this > > would work exactly. Maybe you could tag the information in=20 > > the ser file > > with a datestamp and then zero it out before running the=20 > next batch of > > tests. > >=20 > > I think it is important that this have a good user interface.=20 > > How would > > the statistics be displayed? As a line graph, maybe? How would the > > user tell Cobertura to create these reports? Would they specify a > > "start date" and "end date"? Would the report have a=20 > separate display > > for each package? For each class? Would it have a way to show > > differences in the source files? > >=20 > > Does that help you, any? > >=20 > > -Mark > >=20 >=20 |
|
From: Mark D. <ma...@ki...> - 2005-05-18 00:31:34
|
I guess I'll say 1.3. Currently you need 1.4 or newer for instrumenting and reporting. You _might_ be able to use something older for running instrumented classes. I made a stab at supporting 1.3 a few weeks ago, but I'm having second thoughts. It makes the cobertura distributables gigantic, because of the need for jakarta oro, xml jars, etc. You can see the last attempt of a 1.3 build at http://cobertura.sourceforge.net/buildresults/projectinfo.php?project=Cobertura-jdk1.3.1 I'm willing to accept patches to make it work better. -Mark On Tue, 17 May 2005 20:54:23 -0300, Jody Brownell wrote > BTW - what is the target JDK for cobertura? Just wondering what I > version of the JDK I can introduce dependencies for if I need to.... > > cheers > > -----Original Message----- > From: Mark Doliner [mailto:Mar...@sa...] > Sent: Tuesday, May 17, 2005 4:58 PM > To: Jody Brownell > Cc: cob...@li...; Adam Morgan > Subject: RE: [Cobertura-devel] How can I get involved.... > > No, there are no major changes happening in HEAD right now. However, > the changes between 1.2 and HEAD are pretty big--I definitely suggest > developing against CVS HEAD rather than 1.2. > -Mark > > > -----Original Message----- > > From: Jody Brownell [mailto:jod...@Q1...] > > Sent: Tuesday, May 17, 2005 3:55 PM > > To: Mark Doliner > > Cc: cob...@li...; Adam Morgan > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > Agreed... Plan is to make it part of cobertura - assuming you > > accept the > > patches etc :) I have to get few a number of items at work, > > then I will > > start. > > > > I will be in touch shortly. > > > > BTW - is there anything major happening now on HEAD in cvs? > > > > -----Original Message----- > > From: Mark Doliner [mailto:Mar...@sa...] > > Sent: Tuesday, May 17, 2005 4:41 PM > > To: Jody Brownell > > Cc: cob...@li...; Adam Morgan > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > It sounds like you have a good idea of what you want to do. > > I would be > > careful to try to keep the data harvesting and the report generation > > reasonably separate from each other. Why? Because historical "change > > in coverage over time" graphs would be really cool, and I think it's > > something that could be an impressive addition to Cobertura. > > If it WAS > > made a part of Cobertura, it seems likely that the data > > harvesting parts > > of your code would need lots of changes, but hopefully the report > > generation stuff could remain largely unchanged. > > > > -Mark > > > > > -----Original Message----- > > > From: Jody Brownell [mailto:jod...@Q1...] > > > Sent: Friday, May 13, 2005 6:56 AM > > > To: Mark Doliner > > > Cc: cob...@li...; Adam Morgan > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > Sure does - thanks. > > > > > > My first thoughts were - this could be an addon > > package/application of > > > sorts which can use your .ser file or the XML reports (once > > > successfully > > > completed). I would prefer to not touch your guys code at all if > > > possible and just piggy back on what you have - make enhancements if > > > required. > > > > > > This implies that, the way users run cobertura now would > > not change at > > > all - providing a single user mode of sorts. Then the new additional > > > task (ant?) could be run to export that data to a central or non > > > volatile data store. (Data store could be RDBMS, flat file or > > > what have > > > you - makes no difference to me - as long as simple and fast). > > > > > > Key things for me are, it needs to be extremely simple to > > install and > > > maintain. No over complicated configuration etc - keep it as > > > it is today > > > as much as possible. > > > > > > Agree about the UI - has to be clean, intuitive, simple and fast. > > > > > > - Be nice to view reports on product? / project / package / > > > class / ... > > > hierarchy - as you navigate through the hierarchy - > > > graph/plot for where > > > you are > > > - plotting lines of code / coverage over time (Jfreechart has > > > some great > > > plots) > > > - Need to identify and ensure we have the right data in the > > > datastore. A > > > few reports which come to mind are > > > - plain coverage stats > > > - plain coverage stats plotted against lines of code > > > - coverage stats of one project/package/class plotted against the > > > baseline coverage of all projects (how does this > > project/package/class > > > compare to the running average) ( more advanced :)) > > > > > > For now - I will focus on keeping it simple with two additional ant > > > tasks, one for exporting/updating to non volatile > > datastore, the other > > > for generating reports from that data. I will put together a > > > more formal > > > list of features / requirements over the next few days. > > > > > > Thoughts? > > > > > > -----Original Message----- > > > From: Mark Doliner [mailto:Mar...@sa...] > > > Sent: Tuesday, May 10, 2005 12:03 PM > > > To: Jody Brownell > > > Cc: cob...@li... > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > *snip* > > > > > > > Anywho - the purpose of this email is to see how I can get > > > > involved. One > > > > gap in the product which I noticed (and may already be planned) is > > > > coverage statistics over time. I was thinking, unless this is on > > > > someone's plate already I could start to get familiar with > > > > the code base > > > > and put together a plan of attack - an impact of sorts - and > > > > propose to > > > > you all. > > > > > > *snip* > > > > > > > Please let me know if this is of interest. BTW - what is > > the typical > > > > process of getting involved? Hope I am not jumping the gun. > > > > > > You're not jumping the gun at all. I suppose the typical process of > > > getting involved is to find something you're interested in > > > fixing/improving/adding and writing a patch for it. I don't know of > > > anyone working on statistics over time. And it's > > definitely something > > > that would be nice to have. You would definitely want to > > > work with CVS, > > > if you plan on making any changes. Some of the stuff I > > mention below > > > applies to CVS but not to the last release. > > > > > > I guess the easy way to do it would be to name the XML > > > reports based on > > > the date and time they were created, and then you could parse a > > > directory of these files and determine the change over time. This > > > wouldn't even need to be a part of Cobertura--it could be a > > completely > > > separate program. Or maybe instead of reading the data from the XML > > > reports, you could read it directly from cobertura.ser files. > > > (The ser > > > file contains basically the same information as the XML > > reports. The > > > ser file contains serialized classes from the package > > > net.sourceforge.cobertura.coveragedata. If you choose to go > > > this route, > > > you would need to use these classes to read the serialized file.) > > > > > > However, it might be better to modify the classes in the > > coveragedata > > > package to natively support a time and date. I'm not sure how this > > > would work exactly. Maybe you could tag the information in > > > the ser file > > > with a datestamp and then zero it out before running the > > next batch of > > > tests. > > > > > > I think it is important that this have a good user interface. > > > How would > > > the statistics be displayed? As a line graph, maybe? How would the > > > user tell Cobertura to create these reports? Would they specify a > > > "start date" and "end date"? Would the report have a > > separate display > > > for each package? For each class? Would it have a way to show > > > differences in the source files? > > > > > > Does that help you, any? > > > > > > -Mark > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_idt12&alloc_id344&op=click > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
|
From: Mark D. <Mar...@sa...> - 2005-05-19 19:54:18
|
I talked to Jeremy for a few minutes about this yesterday. I guess we = kind of decided that the fix is an improvement from what it was. After = his patch, Cobertura lumps all inner classes with their parents. So the = HTML reports show everything on one page, but the XML reports no longer = distinguish between inner classes and their parent. I still think that ideally, inner classes would be listed independently = of their parent class in the xml reports. What do other people think? -Mark > -----Original Message----- > From: Jeremy Thomerson [mailto:je...@th...]=20 > Sent: Wednesday, May 18, 2005 3:34 AM > To: Mark Doliner; Jody Brownell > Cc: cob...@li...; Adam Morgan > Subject: Re: [Cobertura-devel] How can I get involved.... >=20 > I just committed the necessary changes to accomodate "coverage for the > classes HelloWorld and HelloWorld$1 would both appear on the same HTML > page". >=20 > It also removed the map of classes maintained in ProjectData=20 > since we're > already maintaining all of our classes in individual=20 > PackageData instances. > Granted, it would've been handy to continue hanging on to ClassData > instances in ProjectData, but it would have required copy and=20 > paste logic > from PackageData determining how to aggregrate data from=20 > inner classes into > its parent class. I really hate copy and paste wcode, so I=20 > refactored it to > avoid needing it. However, I think the better way to=20 > refactor this in the > future is have an object whose job it is to hold on to=20 > multiple ClassData > instances, and it can be the only place that contains the aggregration > logic. Maybe? >=20 > It's late enough for now. Hope this was what you were=20 > looking for Mark. > Let me know if it's not. I can back out my changes. >=20 > Jeremy Thomerson > eBay >=20 > ----- Original Message ----- > From: "Mark Doliner" <Mar...@sa...> > To: "Jeremy Ryan Thomerson" <je...@th...>;=20 > "Jody Brownell" > <jod...@Q1...> > Cc: <cob...@li...>; "Adam Morgan" > <ada...@Q1...> > Sent: Tuesday, May 17, 2005 1:10 PM > Subject: RE: [Cobertura-devel] How can I get involved.... >=20 >=20 > No, but how about Thursday? >=20 > I was hoping to get the inner-class thing resolved before=20 > releasing 1.3, but > I think I would rather release it as-in and then make changes later. >=20 > What's wrong with inner-classes, you ask? > In 1.2 the HTML reports ignored inner-classes, and did not=20 > show them as > covered/not covered. > In CVS the HTML reports show coverage for inner-classes, but=20 > they appear in > a separate HTML page instead of being nestled in with their=20 > parent, like a > happy baby bird. > Ideally, the coverage for the classes HelloWorld and=20 > HelloWorld$1 would both > appear on the same HTML page. >=20 > In summary, CVS handles this better than 1.2 did, but it's still not > perfect. However, if people agree that it's better to release now and > improve it later, then let's do that. >=20 > -Mark >=20 > > -----Original Message----- > > From: Jeremy Ryan Thomerson [mailto:je...@th...] > > Sent: Tuesday, May 17, 2005 4:03 PM > > To: Mark Doliner; Jody Brownell > > Cc: cob...@li...; Adam Morgan > > Subject: Re: [Cobertura-devel] How can I get involved.... > > > > Do we have a proposed release date for 1.3? It seems like we > > have some > > pretty significant changes that are awaiting a release. > > > > Jeremy Thomerson > > > > ----- Original Message ----- > > From: "Mark Doliner" <Mar...@sa...> > > To: "Jody Brownell" <jod...@Q1...> > > Cc: <cob...@li...>; "Adam Morgan" > > <ada...@Q1...> > > Sent: Tuesday, May 17, 2005 2:57 PM > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > No, there are no major changes happening in HEAD right now. > > However, the > > changes between 1.2 and HEAD are pretty big--I definitely > > suggest developing > > against CVS HEAD rather than 1.2. > > -Mark > > > > > -----Original Message----- > > > From: Jody Brownell [mailto:jod...@Q1...] > > > Sent: Tuesday, May 17, 2005 3:55 PM > > > To: Mark Doliner > > > Cc: cob...@li...; Adam Morgan > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > Agreed... Plan is to make it part of cobertura - assuming you > > > accept the > > > patches etc :) I have to get few a number of items at work, > > > then I will > > > start. > > > > > > I will be in touch shortly. > > > > > > BTW - is there anything major happening now on HEAD in cvs? > > > > > > -----Original Message----- > > > From: Mark Doliner [mailto:Mar...@sa...] > > > Sent: Tuesday, May 17, 2005 4:41 PM > > > To: Jody Brownell > > > Cc: cob...@li...; Adam Morgan > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > It sounds like you have a good idea of what you want to do. > > > I would be > > > careful to try to keep the data harvesting and the report=20 > generation > > > reasonably separate from each other. Why? Because > > historical "change > > > in coverage over time" graphs would be really cool, and I=20 > think it's > > > something that could be an impressive addition to Cobertura. > > > If it WAS > > > made a part of Cobertura, it seems likely that the data > > > harvesting parts > > > of your code would need lots of changes, but hopefully the report > > > generation stuff could remain largely unchanged. > > > > > > -Mark > > > > > > > -----Original Message----- > > > > From: Jody Brownell [mailto:jod...@Q1...] > > > > Sent: Friday, May 13, 2005 6:56 AM > > > > To: Mark Doliner > > > > Cc: cob...@li...; Adam Morgan > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > Sure does - thanks. > > > > > > > > My first thoughts were - this could be an addon > > > package/application of > > > > sorts which can use your .ser file or the XML reports (once > > > > successfully > > > > completed). I would prefer to not touch your guys code at all if > > > > possible and just piggy back on what you have - make > > enhancements if > > > > required. > > > > > > > > This implies that, the way users run cobertura now would > > > not change at > > > > all - providing a single user mode of sorts. Then the new > > additional > > > > task (ant?) could be run to export that data to a central or non > > > > volatile data store. (Data store could be RDBMS, flat file or > > > > what have > > > > you - makes no difference to me - as long as simple and fast). > > > > > > > > Key things for me are, it needs to be extremely simple to > > > install and > > > > maintain. No over complicated configuration etc - keep it as > > > > it is today > > > > as much as possible. > > > > > > > > Agree about the UI - has to be clean, intuitive, simple=20 > and fast. > > > > > > > > - Be nice to view reports on product? / project / package / > > > > class / ... > > > > hierarchy - as you navigate through the hierarchy - > > > > graph/plot for where > > > > you are > > > > - plotting lines of code / coverage over time (Jfreechart has > > > > some great > > > > plots) > > > > - Need to identify and ensure we have the right data in the > > > > datastore. A > > > > few reports which come to mind are > > > > - plain coverage stats > > > > - plain coverage stats plotted against lines of code > > > > - coverage stats of one project/package/class plotted > > against the > > > > baseline coverage of all projects (how does this > > > project/package/class > > > > compare to the running average) ( more advanced :)) > > > > > > > > For now - I will focus on keeping it simple with two > > additional ant > > > > tasks, one for exporting/updating to non volatile > > > datastore, the other > > > > for generating reports from that data. I will put together a > > > > more formal > > > > list of features / requirements over the next few days. > > > > > > > > Thoughts? > > > > > > > > -----Original Message----- > > > > From: Mark Doliner [mailto:Mar...@sa...] > > > > Sent: Tuesday, May 10, 2005 12:03 PM > > > > To: Jody Brownell > > > > Cc: cob...@li... > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > *snip* > > > > > > > > > Anywho - the purpose of this email is to see how I can get > > > > > involved. One > > > > > gap in the product which I noticed (and may already be > > planned) is > > > > > coverage statistics over time. I was thinking, unless=20 > this is on > > > > > someone's plate already I could start to get familiar with > > > > > the code base > > > > > and put together a plan of attack - an impact of sorts - and > > > > > propose to > > > > > you all. > > > > > > > > *snip* > > > > > > > > > Please let me know if this is of interest. BTW - what is > > > the typical > > > > > process of getting involved? Hope I am not jumping the gun. > > > > > > > > You're not jumping the gun at all. I suppose the typical > > process of > > > > getting involved is to find something you're interested in > > > > fixing/improving/adding and writing a patch for it. I > > don't know of > > > > anyone working on statistics over time. And it's > > > definitely something > > > > that would be nice to have. You would definitely want to > > > > work with CVS, > > > > if you plan on making any changes. Some of the stuff I > > > mention below > > > > applies to CVS but not to the last release. > > > > > > > > I guess the easy way to do it would be to name the XML > > > > reports based on > > > > the date and time they were created, and then you could parse a > > > > directory of these files and determine the change over=20 > time. This > > > > wouldn't even need to be a part of Cobertura--it could be a > > > completely > > > > separate program. Or maybe instead of reading the data > > from the XML > > > > reports, you could read it directly from cobertura.ser files. > > > > (The ser > > > > file contains basically the same information as the XML > > > reports. The > > > > ser file contains serialized classes from the package > > > > net.sourceforge.cobertura.coveragedata. If you choose to go > > > > this route, > > > > you would need to use these classes to read the=20 > serialized file.) > > > > > > > > However, it might be better to modify the classes in the > > > coveragedata > > > > package to natively support a time and date. I'm not > > sure how this > > > > would work exactly. Maybe you could tag the information in > > > > the ser file > > > > with a datestamp and then zero it out before running the > > > next batch of > > > > tests. > > > > > > > > I think it is important that this have a good user interface. > > > > How would > > > > the statistics be displayed? As a line graph, maybe? > > How would the > > > > user tell Cobertura to create these reports? Would=20 > they specify a > > > > "start date" and "end date"? Would the report have a > > > separate display > > > > for each package? For each class? Would it have a way to show > > > > differences in the source files? > > > > > > > > Does that help you, any? > > > > > > > > -Mark > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by Oracle Space Sweepstakes > > Want to be the first software developer in space? > > Enter now for the Oracle Space Sweepstakes! > > http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dick > > _______________________________________________ > > Cobertura-devel mailing list > > Cob...@li... > > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > > > > > > > >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dick > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel >=20 >=20 |
|
From: Jody B. <jod...@Q1...> - 2005-05-19 19:56:42
|
I think it makes sense to have the inner classes reported within the parent XML.... that is where I would expect to find it anyway. -----Original Message----- From: Mark Doliner [mailto:Mar...@sa...]=20 Sent: Thursday, May 19, 2005 4:54 PM To: Jeremy Thomerson; Jody Brownell Cc: cob...@li...; Adam Morgan Subject: RE: [Cobertura-devel] How can I get involved.... I talked to Jeremy for a few minutes about this yesterday. I guess we kind of decided that the fix is an improvement from what it was. After his patch, Cobertura lumps all inner classes with their parents. So the HTML reports show everything on one page, but the XML reports no longer distinguish between inner classes and their parent. I still think that ideally, inner classes would be listed independently of their parent class in the xml reports. What do other people think? -Mark > -----Original Message----- > From: Jeremy Thomerson [mailto:je...@th...]=20 > Sent: Wednesday, May 18, 2005 3:34 AM > To: Mark Doliner; Jody Brownell > Cc: cob...@li...; Adam Morgan > Subject: Re: [Cobertura-devel] How can I get involved.... >=20 > I just committed the necessary changes to accomodate "coverage for the > classes HelloWorld and HelloWorld$1 would both appear on the same HTML > page". >=20 > It also removed the map of classes maintained in ProjectData=20 > since we're > already maintaining all of our classes in individual=20 > PackageData instances. > Granted, it would've been handy to continue hanging on to ClassData > instances in ProjectData, but it would have required copy and=20 > paste logic > from PackageData determining how to aggregrate data from=20 > inner classes into > its parent class. I really hate copy and paste wcode, so I=20 > refactored it to > avoid needing it. However, I think the better way to=20 > refactor this in the > future is have an object whose job it is to hold on to=20 > multiple ClassData > instances, and it can be the only place that contains the aggregration > logic. Maybe? >=20 > It's late enough for now. Hope this was what you were=20 > looking for Mark. > Let me know if it's not. I can back out my changes. >=20 > Jeremy Thomerson > eBay >=20 > ----- Original Message ----- > From: "Mark Doliner" <Mar...@sa...> > To: "Jeremy Ryan Thomerson" <je...@th...>;=20 > "Jody Brownell" > <jod...@Q1...> > Cc: <cob...@li...>; "Adam Morgan" > <ada...@Q1...> > Sent: Tuesday, May 17, 2005 1:10 PM > Subject: RE: [Cobertura-devel] How can I get involved.... >=20 >=20 > No, but how about Thursday? >=20 > I was hoping to get the inner-class thing resolved before=20 > releasing 1.3, but > I think I would rather release it as-in and then make changes later. >=20 > What's wrong with inner-classes, you ask? > In 1.2 the HTML reports ignored inner-classes, and did not=20 > show them as > covered/not covered. > In CVS the HTML reports show coverage for inner-classes, but=20 > they appear in > a separate HTML page instead of being nestled in with their=20 > parent, like a > happy baby bird. > Ideally, the coverage for the classes HelloWorld and=20 > HelloWorld$1 would both > appear on the same HTML page. >=20 > In summary, CVS handles this better than 1.2 did, but it's still not > perfect. However, if people agree that it's better to release now and > improve it later, then let's do that. >=20 > -Mark >=20 > > -----Original Message----- > > From: Jeremy Ryan Thomerson [mailto:je...@th...] > > Sent: Tuesday, May 17, 2005 4:03 PM > > To: Mark Doliner; Jody Brownell > > Cc: cob...@li...; Adam Morgan > > Subject: Re: [Cobertura-devel] How can I get involved.... > > > > Do we have a proposed release date for 1.3? It seems like we > > have some > > pretty significant changes that are awaiting a release. > > > > Jeremy Thomerson > > > > ----- Original Message ----- > > From: "Mark Doliner" <Mar...@sa...> > > To: "Jody Brownell" <jod...@Q1...> > > Cc: <cob...@li...>; "Adam Morgan" > > <ada...@Q1...> > > Sent: Tuesday, May 17, 2005 2:57 PM > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > No, there are no major changes happening in HEAD right now. > > However, the > > changes between 1.2 and HEAD are pretty big--I definitely > > suggest developing > > against CVS HEAD rather than 1.2. > > -Mark > > > > > -----Original Message----- > > > From: Jody Brownell [mailto:jod...@Q1...] > > > Sent: Tuesday, May 17, 2005 3:55 PM > > > To: Mark Doliner > > > Cc: cob...@li...; Adam Morgan > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > Agreed... Plan is to make it part of cobertura - assuming you > > > accept the > > > patches etc :) I have to get few a number of items at work, > > > then I will > > > start. > > > > > > I will be in touch shortly. > > > > > > BTW - is there anything major happening now on HEAD in cvs? > > > > > > -----Original Message----- > > > From: Mark Doliner [mailto:Mar...@sa...] > > > Sent: Tuesday, May 17, 2005 4:41 PM > > > To: Jody Brownell > > > Cc: cob...@li...; Adam Morgan > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > It sounds like you have a good idea of what you want to do. > > > I would be > > > careful to try to keep the data harvesting and the report=20 > generation > > > reasonably separate from each other. Why? Because > > historical "change > > > in coverage over time" graphs would be really cool, and I=20 > think it's > > > something that could be an impressive addition to Cobertura. > > > If it WAS > > > made a part of Cobertura, it seems likely that the data > > > harvesting parts > > > of your code would need lots of changes, but hopefully the report > > > generation stuff could remain largely unchanged. > > > > > > -Mark > > > > > > > -----Original Message----- > > > > From: Jody Brownell [mailto:jod...@Q1...] > > > > Sent: Friday, May 13, 2005 6:56 AM > > > > To: Mark Doliner > > > > Cc: cob...@li...; Adam Morgan > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > Sure does - thanks. > > > > > > > > My first thoughts were - this could be an addon > > > package/application of > > > > sorts which can use your .ser file or the XML reports (once > > > > successfully > > > > completed). I would prefer to not touch your guys code at all if > > > > possible and just piggy back on what you have - make > > enhancements if > > > > required. > > > > > > > > This implies that, the way users run cobertura now would > > > not change at > > > > all - providing a single user mode of sorts. Then the new > > additional > > > > task (ant?) could be run to export that data to a central or non > > > > volatile data store. (Data store could be RDBMS, flat file or > > > > what have > > > > you - makes no difference to me - as long as simple and fast). > > > > > > > > Key things for me are, it needs to be extremely simple to > > > install and > > > > maintain. No over complicated configuration etc - keep it as > > > > it is today > > > > as much as possible. > > > > > > > > Agree about the UI - has to be clean, intuitive, simple=20 > and fast. > > > > > > > > - Be nice to view reports on product? / project / package / > > > > class / ... > > > > hierarchy - as you navigate through the hierarchy - > > > > graph/plot for where > > > > you are > > > > - plotting lines of code / coverage over time (Jfreechart has > > > > some great > > > > plots) > > > > - Need to identify and ensure we have the right data in the > > > > datastore. A > > > > few reports which come to mind are > > > > - plain coverage stats > > > > - plain coverage stats plotted against lines of code > > > > - coverage stats of one project/package/class plotted > > against the > > > > baseline coverage of all projects (how does this > > > project/package/class > > > > compare to the running average) ( more advanced :)) > > > > > > > > For now - I will focus on keeping it simple with two > > additional ant > > > > tasks, one for exporting/updating to non volatile > > > datastore, the other > > > > for generating reports from that data. I will put together a > > > > more formal > > > > list of features / requirements over the next few days. > > > > > > > > Thoughts? > > > > > > > > -----Original Message----- > > > > From: Mark Doliner [mailto:Mar...@sa...] > > > > Sent: Tuesday, May 10, 2005 12:03 PM > > > > To: Jody Brownell > > > > Cc: cob...@li... > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > *snip* > > > > > > > > > Anywho - the purpose of this email is to see how I can get > > > > > involved. One > > > > > gap in the product which I noticed (and may already be > > planned) is > > > > > coverage statistics over time. I was thinking, unless=20 > this is on > > > > > someone's plate already I could start to get familiar with > > > > > the code base > > > > > and put together a plan of attack - an impact of sorts - and > > > > > propose to > > > > > you all. > > > > > > > > *snip* > > > > > > > > > Please let me know if this is of interest. BTW - what is > > > the typical > > > > > process of getting involved? Hope I am not jumping the gun. > > > > > > > > You're not jumping the gun at all. I suppose the typical > > process of > > > > getting involved is to find something you're interested in > > > > fixing/improving/adding and writing a patch for it. I > > don't know of > > > > anyone working on statistics over time. And it's > > > definitely something > > > > that would be nice to have. You would definitely want to > > > > work with CVS, > > > > if you plan on making any changes. Some of the stuff I > > > mention below > > > > applies to CVS but not to the last release. > > > > > > > > I guess the easy way to do it would be to name the XML > > > > reports based on > > > > the date and time they were created, and then you could parse a > > > > directory of these files and determine the change over=20 > time. This > > > > wouldn't even need to be a part of Cobertura--it could be a > > > completely > > > > separate program. Or maybe instead of reading the data > > from the XML > > > > reports, you could read it directly from cobertura.ser files. > > > > (The ser > > > > file contains basically the same information as the XML > > > reports. The > > > > ser file contains serialized classes from the package > > > > net.sourceforge.cobertura.coveragedata. If you choose to go > > > > this route, > > > > you would need to use these classes to read the=20 > serialized file.) > > > > > > > > However, it might be better to modify the classes in the > > > coveragedata > > > > package to natively support a time and date. I'm not > > sure how this > > > > would work exactly. Maybe you could tag the information in > > > > the ser file > > > > with a datestamp and then zero it out before running the > > > next batch of > > > > tests. > > > > > > > > I think it is important that this have a good user interface. > > > > How would > > > > the statistics be displayed? As a line graph, maybe? > > How would the > > > > user tell Cobertura to create these reports? Would=20 > they specify a > > > > "start date" and "end date"? Would the report have a > > > separate display > > > > for each package? For each class? Would it have a way to show > > > > differences in the source files? > > > > > > > > Does that help you, any? > > > > > > > > -Mark > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by Oracle Space Sweepstakes > > Want to be the first software developer in space? > > Enter now for the Oracle Space Sweepstakes! > > http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dick > > _______________________________________________ > > Cobertura-devel mailing list > > Cob...@li... > > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > > > > > > > >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dick > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel >=20 >=20 |
|
From: Jeremy R. T. <je...@th...> - 2005-05-19 20:01:04
|
In thinking it over since I talked to Mark yesterday, I'd agree. I don't think it makes sense to separate the reporting of the inner classes from their parent in the XML any more than it does in the HTML. To answer my question, I asked myself: "Would I ever want to look in a report and find out just the coverage on an inner (or even anonymous) class and not see the coverage of its' respective top-level class?" My answer was no. But, I can change the patch I committed to allow for this if there is a consensus otherwise. (and if told early enough, I could get it in before a late night release most likely.) Jeremy ----- Original Message ----- From: "Jody Brownell" <jod...@Q1...> To: "Mark Doliner" <Mar...@sa...>; "Jeremy Thomerson" <je...@th...> Cc: <cob...@li...> Sent: Thursday, May 19, 2005 2:56 PM Subject: RE: [Cobertura-devel] How can I get involved.... I think it makes sense to have the inner classes reported within the parent XML.... that is where I would expect to find it anyway. -----Original Message----- From: Mark Doliner [mailto:Mar...@sa...] Sent: Thursday, May 19, 2005 4:54 PM To: Jeremy Thomerson; Jody Brownell Cc: cob...@li...; Adam Morgan Subject: RE: [Cobertura-devel] How can I get involved.... I talked to Jeremy for a few minutes about this yesterday. I guess we kind of decided that the fix is an improvement from what it was. After his patch, Cobertura lumps all inner classes with their parents. So the HTML reports show everything on one page, but the XML reports no longer distinguish between inner classes and their parent. I still think that ideally, inner classes would be listed independently of their parent class in the xml reports. What do other people think? -Mark > -----Original Message----- > From: Jeremy Thomerson [mailto:je...@th...] > Sent: Wednesday, May 18, 2005 3:34 AM > To: Mark Doliner; Jody Brownell > Cc: cob...@li...; Adam Morgan > Subject: Re: [Cobertura-devel] How can I get involved.... > > I just committed the necessary changes to accomodate "coverage for the > classes HelloWorld and HelloWorld$1 would both appear on the same HTML > page". > > It also removed the map of classes maintained in ProjectData > since we're > already maintaining all of our classes in individual > PackageData instances. > Granted, it would've been handy to continue hanging on to ClassData > instances in ProjectData, but it would have required copy and > paste logic > from PackageData determining how to aggregrate data from > inner classes into > its parent class. I really hate copy and paste wcode, so I > refactored it to > avoid needing it. However, I think the better way to > refactor this in the > future is have an object whose job it is to hold on to > multiple ClassData > instances, and it can be the only place that contains the aggregration > logic. Maybe? > > It's late enough for now. Hope this was what you were > looking for Mark. > Let me know if it's not. I can back out my changes. > > Jeremy Thomerson > eBay > > ----- Original Message ----- > From: "Mark Doliner" <Mar...@sa...> > To: "Jeremy Ryan Thomerson" <je...@th...>; > "Jody Brownell" > <jod...@Q1...> > Cc: <cob...@li...>; "Adam Morgan" > <ada...@Q1...> > Sent: Tuesday, May 17, 2005 1:10 PM > Subject: RE: [Cobertura-devel] How can I get involved.... > > > No, but how about Thursday? > > I was hoping to get the inner-class thing resolved before > releasing 1.3, but > I think I would rather release it as-in and then make changes later. > > What's wrong with inner-classes, you ask? > In 1.2 the HTML reports ignored inner-classes, and did not > show them as > covered/not covered. > In CVS the HTML reports show coverage for inner-classes, but > they appear in > a separate HTML page instead of being nestled in with their > parent, like a > happy baby bird. > Ideally, the coverage for the classes HelloWorld and > HelloWorld$1 would both > appear on the same HTML page. > > In summary, CVS handles this better than 1.2 did, but it's still not > perfect. However, if people agree that it's better to release now and > improve it later, then let's do that. > > -Mark > > > -----Original Message----- > > From: Jeremy Ryan Thomerson [mailto:je...@th...] > > Sent: Tuesday, May 17, 2005 4:03 PM > > To: Mark Doliner; Jody Brownell > > Cc: cob...@li...; Adam Morgan > > Subject: Re: [Cobertura-devel] How can I get involved.... > > > > Do we have a proposed release date for 1.3? It seems like we > > have some > > pretty significant changes that are awaiting a release. > > > > Jeremy Thomerson > > > > ----- Original Message ----- > > From: "Mark Doliner" <Mar...@sa...> > > To: "Jody Brownell" <jod...@Q1...> > > Cc: <cob...@li...>; "Adam Morgan" > > <ada...@Q1...> > > Sent: Tuesday, May 17, 2005 2:57 PM > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > No, there are no major changes happening in HEAD right now. > > However, the > > changes between 1.2 and HEAD are pretty big--I definitely > > suggest developing > > against CVS HEAD rather than 1.2. > > -Mark > > > > > -----Original Message----- > > > From: Jody Brownell [mailto:jod...@Q1...] > > > Sent: Tuesday, May 17, 2005 3:55 PM > > > To: Mark Doliner > > > Cc: cob...@li...; Adam Morgan > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > Agreed... Plan is to make it part of cobertura - assuming you > > > accept the > > > patches etc :) I have to get few a number of items at work, > > > then I will > > > start. > > > > > > I will be in touch shortly. > > > > > > BTW - is there anything major happening now on HEAD in cvs? > > > > > > -----Original Message----- > > > From: Mark Doliner [mailto:Mar...@sa...] > > > Sent: Tuesday, May 17, 2005 4:41 PM > > > To: Jody Brownell > > > Cc: cob...@li...; Adam Morgan > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > It sounds like you have a good idea of what you want to do. > > > I would be > > > careful to try to keep the data harvesting and the report > generation > > > reasonably separate from each other. Why? Because > > historical "change > > > in coverage over time" graphs would be really cool, and I > think it's > > > something that could be an impressive addition to Cobertura. > > > If it WAS > > > made a part of Cobertura, it seems likely that the data > > > harvesting parts > > > of your code would need lots of changes, but hopefully the report > > > generation stuff could remain largely unchanged. > > > > > > -Mark > > > > > > > -----Original Message----- > > > > From: Jody Brownell [mailto:jod...@Q1...] > > > > Sent: Friday, May 13, 2005 6:56 AM > > > > To: Mark Doliner > > > > Cc: cob...@li...; Adam Morgan > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > Sure does - thanks. > > > > > > > > My first thoughts were - this could be an addon > > > package/application of > > > > sorts which can use your .ser file or the XML reports (once > > > > successfully > > > > completed). I would prefer to not touch your guys code at all if > > > > possible and just piggy back on what you have - make > > enhancements if > > > > required. > > > > > > > > This implies that, the way users run cobertura now would > > > not change at > > > > all - providing a single user mode of sorts. Then the new > > additional > > > > task (ant?) could be run to export that data to a central or non > > > > volatile data store. (Data store could be RDBMS, flat file or > > > > what have > > > > you - makes no difference to me - as long as simple and fast). > > > > > > > > Key things for me are, it needs to be extremely simple to > > > install and > > > > maintain. No over complicated configuration etc - keep it as > > > > it is today > > > > as much as possible. > > > > > > > > Agree about the UI - has to be clean, intuitive, simple > and fast. > > > > > > > > - Be nice to view reports on product? / project / package / > > > > class / ... > > > > hierarchy - as you navigate through the hierarchy - > > > > graph/plot for where > > > > you are > > > > - plotting lines of code / coverage over time (Jfreechart has > > > > some great > > > > plots) > > > > - Need to identify and ensure we have the right data in the > > > > datastore. A > > > > few reports which come to mind are > > > > - plain coverage stats > > > > - plain coverage stats plotted against lines of code > > > > - coverage stats of one project/package/class plotted > > against the > > > > baseline coverage of all projects (how does this > > > project/package/class > > > > compare to the running average) ( more advanced :)) > > > > > > > > For now - I will focus on keeping it simple with two > > additional ant > > > > tasks, one for exporting/updating to non volatile > > > datastore, the other > > > > for generating reports from that data. I will put together a > > > > more formal > > > > list of features / requirements over the next few days. > > > > > > > > Thoughts? > > > > > > > > -----Original Message----- > > > > From: Mark Doliner [mailto:Mar...@sa...] > > > > Sent: Tuesday, May 10, 2005 12:03 PM > > > > To: Jody Brownell > > > > Cc: cob...@li... > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > *snip* > > > > > > > > > Anywho - the purpose of this email is to see how I can get > > > > > involved. One > > > > > gap in the product which I noticed (and may already be > > planned) is > > > > > coverage statistics over time. I was thinking, unless > this is on > > > > > someone's plate already I could start to get familiar with > > > > > the code base > > > > > and put together a plan of attack - an impact of sorts - and > > > > > propose to > > > > > you all. > > > > > > > > *snip* > > > > > > > > > Please let me know if this is of interest. BTW - what is > > > the typical > > > > > process of getting involved? Hope I am not jumping the gun. > > > > > > > > You're not jumping the gun at all. I suppose the typical > > process of > > > > getting involved is to find something you're interested in > > > > fixing/improving/adding and writing a patch for it. I > > don't know of > > > > anyone working on statistics over time. And it's > > > definitely something > > > > that would be nice to have. You would definitely want to > > > > work with CVS, > > > > if you plan on making any changes. Some of the stuff I > > > mention below > > > > applies to CVS but not to the last release. > > > > > > > > I guess the easy way to do it would be to name the XML > > > > reports based on > > > > the date and time they were created, and then you could parse a > > > > directory of these files and determine the change over > time. This > > > > wouldn't even need to be a part of Cobertura--it could be a > > > completely > > > > separate program. Or maybe instead of reading the data > > from the XML > > > > reports, you could read it directly from cobertura.ser files. > > > > (The ser > > > > file contains basically the same information as the XML > > > reports. The > > > > ser file contains serialized classes from the package > > > > net.sourceforge.cobertura.coveragedata. If you choose to go > > > > this route, > > > > you would need to use these classes to read the > serialized file.) > > > > > > > > However, it might be better to modify the classes in the > > > coveragedata > > > > package to natively support a time and date. I'm not > > sure how this > > > > would work exactly. Maybe you could tag the information in > > > > the ser file > > > > with a datestamp and then zero it out before running the > > > next batch of > > > > tests. > > > > > > > > I think it is important that this have a good user interface. > > > > How would > > > > the statistics be displayed? As a line graph, maybe? > > How would the > > > > user tell Cobertura to create these reports? Would > they specify a > > > > "start date" and "end date"? Would the report have a > > > separate display > > > > for each package? For each class? Would it have a way to show > > > > differences in the source files? > > > > > > > > Does that help you, any? > > > > > > > > -Mark > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by Oracle Space Sweepstakes > > Want to be the first software developer in space? > > Enter now for the Oracle Space Sweepstakes! > > http://ads.osdn.com/?ad_idt12&alloc_id344&op=ick > > _______________________________________________ > > Cobertura-devel mailing list > > Cob...@li... > > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_idt12&alloc_id344&op=ick > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > |
|
From: Mark D. <ma...@ki...> - 2005-05-20 02:17:19
|
Ok, I guess I'm coming around to yous guyses way of thinking. Jeremy's change does a good job of doing what it does. We'll leave it as-is. So the issue with inner classes not being reported is now completely resolved, correct? -Mark On Thu, 19 May 2005 15:00:54 -0500, Jeremy Ryan Thomerson wrote > In thinking it over since I talked to Mark yesterday, I'd agree. I don't > think it makes sense to separate the reporting of the inner classes from > their parent in the XML any more than it does in the HTML. To > answer my question, I asked myself: "Would I ever want to look in a > report and find out just the coverage on an inner (or even anonymous) > class and not see the coverage of its' respective top-level class?" > My answer was no. > > But, I can change the patch I committed to allow for this if there > is a consensus otherwise. (and if told early enough, I could get it > in before a late night release most likely.) > > Jeremy > > ----- Original Message ----- > From: "Jody Brownell" <jod...@Q1...> > To: "Mark Doliner" <Mar...@sa...>; "Jeremy Thomerson" > <je...@th...> > Cc: <cob...@li...> > Sent: Thursday, May 19, 2005 2:56 PM > Subject: RE: [Cobertura-devel] How can I get involved.... > > I think it makes sense to have the inner classes reported within the > parent XML.... that is where I would expect to find it anyway. > > -----Original Message----- > From: Mark Doliner [mailto:Mar...@sa...] > Sent: Thursday, May 19, 2005 4:54 PM > To: Jeremy Thomerson; Jody Brownell > Cc: cob...@li...; Adam Morgan > Subject: RE: [Cobertura-devel] How can I get involved.... > > I talked to Jeremy for a few minutes about this yesterday. I guess > we kind of decided that the fix is an improvement from what it was. > After his patch, Cobertura lumps all inner classes with their > parents. So the HTML reports show everything on one page, but the > XML reports no longer distinguish between inner classes and their parent. > > I still think that ideally, inner classes would be listed independently > of their parent class in the xml reports. What do other people think? > > -Mark > > > -----Original Message----- > > From: Jeremy Thomerson [mailto:je...@th...] > > Sent: Wednesday, May 18, 2005 3:34 AM > > To: Mark Doliner; Jody Brownell > > Cc: cob...@li...; Adam Morgan > > Subject: Re: [Cobertura-devel] How can I get involved.... > > > > I just committed the necessary changes to accomodate "coverage for the > > classes HelloWorld and HelloWorld$1 would both appear on the same HTML > > page". > > > > It also removed the map of classes maintained in ProjectData > > since we're > > already maintaining all of our classes in individual > > PackageData instances. > > Granted, it would've been handy to continue hanging on to ClassData > > instances in ProjectData, but it would have required copy and > > paste logic > > from PackageData determining how to aggregrate data from > > inner classes into > > its parent class. I really hate copy and paste wcode, so I > > refactored it to > > avoid needing it. However, I think the better way to > > refactor this in the > > future is have an object whose job it is to hold on to > > multiple ClassData > > instances, and it can be the only place that contains the aggregration > > logic. Maybe? > > > > It's late enough for now. Hope this was what you were > > looking for Mark. > > Let me know if it's not. I can back out my changes. > > > > Jeremy Thomerson > > eBay > > > > ----- Original Message ----- > > From: "Mark Doliner" <Mar...@sa...> > > To: "Jeremy Ryan Thomerson" <je...@th...>; > > "Jody Brownell" > > <jod...@Q1...> > > Cc: <cob...@li...>; "Adam Morgan" > > <ada...@Q1...> > > Sent: Tuesday, May 17, 2005 1:10 PM > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > No, but how about Thursday? > > > > I was hoping to get the inner-class thing resolved before > > releasing 1.3, but > > I think I would rather release it as-in and then make changes later. > > > > What's wrong with inner-classes, you ask? > > In 1.2 the HTML reports ignored inner-classes, and did not > > show them as > > covered/not covered. > > In CVS the HTML reports show coverage for inner-classes, but > > they appear in > > a separate HTML page instead of being nestled in with their > > parent, like a > > happy baby bird. > > Ideally, the coverage for the classes HelloWorld and > > HelloWorld$1 would both > > appear on the same HTML page. > > > > In summary, CVS handles this better than 1.2 did, but it's still not > > perfect. However, if people agree that it's better to release now and > > improve it later, then let's do that. > > > > -Mark > > > > > -----Original Message----- > > > From: Jeremy Ryan Thomerson [mailto:je...@th...] > > > Sent: Tuesday, May 17, 2005 4:03 PM > > > To: Mark Doliner; Jody Brownell > > > Cc: cob...@li...; Adam Morgan > > > Subject: Re: [Cobertura-devel] How can I get involved.... > > > > > > Do we have a proposed release date for 1.3? It seems like we > > > have some > > > pretty significant changes that are awaiting a release. > > > > > > Jeremy Thomerson > > > > > > ----- Original Message ----- > > > From: "Mark Doliner" <Mar...@sa...> > > > To: "Jody Brownell" <jod...@Q1...> > > > Cc: <cob...@li...>; "Adam Morgan" > > > <ada...@Q1...> > > > Sent: Tuesday, May 17, 2005 2:57 PM > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > > No, there are no major changes happening in HEAD right now. > > > However, the > > > changes between 1.2 and HEAD are pretty big--I definitely > > > suggest developing > > > against CVS HEAD rather than 1.2. > > > -Mark > > > > > > > -----Original Message----- > > > > From: Jody Brownell [mailto:jod...@Q1...] > > > > Sent: Tuesday, May 17, 2005 3:55 PM > > > > To: Mark Doliner > > > > Cc: cob...@li...; Adam Morgan > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > Agreed... Plan is to make it part of cobertura - assuming you > > > > accept the > > > > patches etc :) I have to get few a number of items at work, > > > > then I will > > > > start. > > > > > > > > I will be in touch shortly. > > > > > > > > BTW - is there anything major happening now on HEAD in cvs? > > > > > > > > -----Original Message----- > > > > From: Mark Doliner [mailto:Mar...@sa...] > > > > Sent: Tuesday, May 17, 2005 4:41 PM > > > > To: Jody Brownell > > > > Cc: cob...@li...; Adam Morgan > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > It sounds like you have a good idea of what you want to do. > > > > I would be > > > > careful to try to keep the data harvesting and the report > > generation > > > > reasonably separate from each other. Why? Because > > > historical "change > > > > in coverage over time" graphs would be really cool, and I > > think it's > > > > something that could be an impressive addition to Cobertura. > > > > If it WAS > > > > made a part of Cobertura, it seems likely that the data > > > > harvesting parts > > > > of your code would need lots of changes, but hopefully the report > > > > generation stuff could remain largely unchanged. > > > > > > > > -Mark > > > > > > > > > -----Original Message----- > > > > > From: Jody Brownell [mailto:jod...@Q1...] > > > > > Sent: Friday, May 13, 2005 6:56 AM > > > > > To: Mark Doliner > > > > > Cc: cob...@li...; Adam Morgan > > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > > > Sure does - thanks. > > > > > > > > > > My first thoughts were - this could be an addon > > > > package/application of > > > > > sorts which can use your .ser file or the XML reports (once > > > > > successfully > > > > > completed). I would prefer to not touch your guys code at all if > > > > > possible and just piggy back on what you have - make > > > enhancements if > > > > > required. > > > > > > > > > > This implies that, the way users run cobertura now would > > > > not change at > > > > > all - providing a single user mode of sorts. Then the new > > > additional > > > > > task (ant?) could be run to export that data to a central or non > > > > > volatile data store. (Data store could be RDBMS, flat file or > > > > > what have > > > > > you - makes no difference to me - as long as simple and fast). > > > > > > > > > > Key things for me are, it needs to be extremely simple to > > > > install and > > > > > maintain. No over complicated configuration etc - keep it as > > > > > it is today > > > > > as much as possible. > > > > > > > > > > Agree about the UI - has to be clean, intuitive, simple > > and fast. > > > > > > > > > > - Be nice to view reports on product? / project / package / > > > > > class / ... > > > > > hierarchy - as you navigate through the hierarchy - > > > > > graph/plot for where > > > > > you are > > > > > - plotting lines of code / coverage over time (Jfreechart has > > > > > some great > > > > > plots) > > > > > - Need to identify and ensure we have the right data in the > > > > > datastore. A > > > > > few reports which come to mind are > > > > > - plain coverage stats > > > > > - plain coverage stats plotted against lines of code > > > > > - coverage stats of one project/package/class plotted > > > against the > > > > > baseline coverage of all projects (how does this > > > > project/package/class > > > > > compare to the running average) ( more advanced :)) > > > > > > > > > > For now - I will focus on keeping it simple with two > > > additional ant > > > > > tasks, one for exporting/updating to non volatile > > > > datastore, the other > > > > > for generating reports from that data. I will put together a > > > > > more formal > > > > > list of features / requirements over the next few days. > > > > > > > > > > Thoughts? > > > > > > > > > > -----Original Message----- > > > > > From: Mark Doliner [mailto:Mar...@sa...] > > > > > Sent: Tuesday, May 10, 2005 12:03 PM > > > > > To: Jody Brownell > > > > > Cc: cob...@li... > > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > > > *snip* > > > > > > > > > > > Anywho - the purpose of this email is to see how I can get > > > > > > involved. One > > > > > > gap in the product which I noticed (and may already be > > > planned) is > > > > > > coverage statistics over time. I was thinking, unless > > this is on > > > > > > someone's plate already I could start to get familiar with > > > > > > the code base > > > > > > and put together a plan of attack - an impact of sorts - and > > > > > > propose to > > > > > > you all. > > > > > > > > > > *snip* > > > > > > > > > > > Please let me know if this is of interest. BTW - what is > > > > the typical > > > > > > process of getting involved? Hope I am not jumping the gun. > > > > > > > > > > You're not jumping the gun at all. I suppose the typical > > > process of > > > > > getting involved is to find something you're interested in > > > > > fixing/improving/adding and writing a patch for it. I > > > don't know of > > > > > anyone working on statistics over time. And it's > > > > definitely something > > > > > that would be nice to have. You would definitely want to > > > > > work with CVS, > > > > > if you plan on making any changes. Some of the stuff I > > > > mention below > > > > > applies to CVS but not to the last release. > > > > > > > > > > I guess the easy way to do it would be to name the XML > > > > > reports based on > > > > > the date and time they were created, and then you could parse a > > > > > directory of these files and determine the change over > > time. This > > > > > wouldn't even need to be a part of Cobertura--it could be a > > > > completely > > > > > separate program. Or maybe instead of reading the data > > > from the XML > > > > > reports, you could read it directly from cobertura.ser files. > > > > > (The ser > > > > > file contains basically the same information as the XML > > > > reports. The > > > > > ser file contains serialized classes from the package > > > > > net.sourceforge.cobertura.coveragedata. If you choose to go > > > > > this route, > > > > > you would need to use these classes to read the > > serialized file.) > > > > > > > > > > However, it might be better to modify the classes in the > > > > coveragedata > > > > > package to natively support a time and date. I'm not > > > sure how this > > > > > would work exactly. Maybe you could tag the information in > > > > > the ser file > > > > > with a datestamp and then zero it out before running the > > > > next batch of > > > > > tests. > > > > > > > > > > I think it is important that this have a good user interface. > > > > > How would > > > > > the statistics be displayed? As a line graph, maybe? > > > How would the > > > > > user tell Cobertura to create these reports? Would > > they specify a > > > > > "start date" and "end date"? Would the report have a > > > > separate display > > > > > for each package? For each class? Would it have a way to show > > > > > differences in the source files? > > > > > > > > > > Does that help you, any? > > > > > > > > > > -Mark |
|
From: Jeremy R. T. <je...@th...> - 2005-05-20 02:54:34
|
I believe so. I think you can close that bug in Tracker. So, you're doing to do release 1.3 tonight, correct? Assuming we release tonight, over the weekend I'll aggregate the open bugs / feature requests into an email and estimation of how long each will take to accomplish. Then I'll email it out to everyone early next week, and we can all collaborate on what pieces we can take, and when we think we can have them done. This way we can propose a date for the next release and post it on the site. I for one would like to thank Mark for all the work he did to get this project going and continue improving it. Mark, it's great! And I really enjoy being a part of it. I think from all the emails we've received, everyone that's tried it likes it, and I think with some of the stuff we have coming up on the radar, it will continue to improve and gain traction. Jeremy ----- Original Message ----- From: "Mark Doliner" <ma...@ki...> To: "Jody Brownell" <jod...@Q1...>; <cob...@li...> Sent: Thursday, May 19, 2005 9:19 PM Subject: Re: [Cobertura-devel] How can I get involved.... > Ok, I guess I'm coming around to yous guyses way of thinking. Jeremy's change > does a good job of doing what it does. We'll leave it as-is. So the issue > with inner classes not being reported is now completely resolved, correct? > -Mark > > On Thu, 19 May 2005 15:00:54 -0500, Jeremy Ryan Thomerson wrote > > In thinking it over since I talked to Mark yesterday, I'd agree. I don't > > think it makes sense to separate the reporting of the inner classes from > > their parent in the XML any more than it does in the HTML. To > > answer my question, I asked myself: "Would I ever want to look in a > > report and find out just the coverage on an inner (or even anonymous) > > class and not see the coverage of its' respective top-level class?" > > My answer was no. > > > > But, I can change the patch I committed to allow for this if there > > is a consensus otherwise. (and if told early enough, I could get it > > in before a late night release most likely.) > > > > Jeremy > > > > ----- Original Message ----- > > From: "Jody Brownell" <jod...@Q1...> > > To: "Mark Doliner" <Mar...@sa...>; "Jeremy Thomerson" > > <je...@th...> > > Cc: <cob...@li...> > > Sent: Thursday, May 19, 2005 2:56 PM > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > I think it makes sense to have the inner classes reported within the > > parent XML.... that is where I would expect to find it anyway. > > > > -----Original Message----- > > From: Mark Doliner [mailto:Mar...@sa...] > > Sent: Thursday, May 19, 2005 4:54 PM > > To: Jeremy Thomerson; Jody Brownell > > Cc: cob...@li...; Adam Morgan > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > I talked to Jeremy for a few minutes about this yesterday. I guess > > we kind of decided that the fix is an improvement from what it was. > > After his patch, Cobertura lumps all inner classes with their > > parents. So the HTML reports show everything on one page, but the > > XML reports no longer distinguish between inner classes and their parent. > > > > I still think that ideally, inner classes would be listed independently > > of their parent class in the xml reports. What do other people think? > > > > -Mark > > > > > -----Original Message----- > > > From: Jeremy Thomerson [mailto:je...@th...] > > > Sent: Wednesday, May 18, 2005 3:34 AM > > > To: Mark Doliner; Jody Brownell > > > Cc: cob...@li...; Adam Morgan > > > Subject: Re: [Cobertura-devel] How can I get involved.... > > > > > > I just committed the necessary changes to accomodate "coverage for the > > > classes HelloWorld and HelloWorld$1 would both appear on the same HTML > > > page". > > > > > > It also removed the map of classes maintained in ProjectData > > > since we're > > > already maintaining all of our classes in individual > > > PackageData instances. > > > Granted, it would've been handy to continue hanging on to ClassData > > > instances in ProjectData, but it would have required copy and > > > paste logic > > > from PackageData determining how to aggregrate data from > > > inner classes into > > > its parent class. I really hate copy and paste wcode, so I > > > refactored it to > > > avoid needing it. However, I think the better way to > > > refactor this in the > > > future is have an object whose job it is to hold on to > > > multiple ClassData > > > instances, and it can be the only place that contains the aggregration > > > logic. Maybe? > > > > > > It's late enough for now. Hope this was what you were > > > looking for Mark. > > > Let me know if it's not. I can back out my changes. > > > > > > Jeremy Thomerson > > > eBay > > > > > > ----- Original Message ----- > > > From: "Mark Doliner" <Mar...@sa...> > > > To: "Jeremy Ryan Thomerson" <je...@th...>; > > > "Jody Brownell" > > > <jod...@Q1...> > > > Cc: <cob...@li...>; "Adam Morgan" > > > <ada...@Q1...> > > > Sent: Tuesday, May 17, 2005 1:10 PM > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > > No, but how about Thursday? > > > > > > I was hoping to get the inner-class thing resolved before > > > releasing 1.3, but > > > I think I would rather release it as-in and then make changes later. > > > > > > What's wrong with inner-classes, you ask? > > > In 1.2 the HTML reports ignored inner-classes, and did not > > > show them as > > > covered/not covered. > > > In CVS the HTML reports show coverage for inner-classes, but > > > they appear in > > > a separate HTML page instead of being nestled in with their > > > parent, like a > > > happy baby bird. > > > Ideally, the coverage for the classes HelloWorld and > > > HelloWorld$1 would both > > > appear on the same HTML page. > > > > > > In summary, CVS handles this better than 1.2 did, but it's still not > > > perfect. However, if people agree that it's better to release now and > > > improve it later, then let's do that. > > > > > > -Mark > > > > > > > -----Original Message----- > > > > From: Jeremy Ryan Thomerson [mailto:je...@th...] > > > > Sent: Tuesday, May 17, 2005 4:03 PM > > > > To: Mark Doliner; Jody Brownell > > > > Cc: cob...@li...; Adam Morgan > > > > Subject: Re: [Cobertura-devel] How can I get involved.... > > > > > > > > Do we have a proposed release date for 1.3? It seems like we > > > > have some > > > > pretty significant changes that are awaiting a release. > > > > > > > > Jeremy Thomerson > > > > > > > > ----- Original Message ----- > > > > From: "Mark Doliner" <Mar...@sa...> > > > > To: "Jody Brownell" <jod...@Q1...> > > > > Cc: <cob...@li...>; "Adam Morgan" > > > > <ada...@Q1...> > > > > Sent: Tuesday, May 17, 2005 2:57 PM > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > > > > > No, there are no major changes happening in HEAD right now. > > > > However, the > > > > changes between 1.2 and HEAD are pretty big--I definitely > > > > suggest developing > > > > against CVS HEAD rather than 1.2. > > > > -Mark > > > > > > > > > -----Original Message----- > > > > > From: Jody Brownell [mailto:jod...@Q1...] > > > > > Sent: Tuesday, May 17, 2005 3:55 PM > > > > > To: Mark Doliner > > > > > Cc: cob...@li...; Adam Morgan > > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > > > Agreed... Plan is to make it part of cobertura - assuming you > > > > > accept the > > > > > patches etc :) I have to get few a number of items at work, > > > > > then I will > > > > > start. > > > > > > > > > > I will be in touch shortly. > > > > > > > > > > BTW - is there anything major happening now on HEAD in cvs? > > > > > > > > > > -----Original Message----- > > > > > From: Mark Doliner [mailto:Mar...@sa...] > > > > > Sent: Tuesday, May 17, 2005 4:41 PM > > > > > To: Jody Brownell > > > > > Cc: cob...@li...; Adam Morgan > > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > > > It sounds like you have a good idea of what you want to do. > > > > > I would be > > > > > careful to try to keep the data harvesting and the report > > > generation > > > > > reasonably separate from each other. Why? Because > > > > historical "change > > > > > in coverage over time" graphs would be really cool, and I > > > think it's > > > > > something that could be an impressive addition to Cobertura. > > > > > If it WAS > > > > > made a part of Cobertura, it seems likely that the data > > > > > harvesting parts > > > > > of your code would need lots of changes, but hopefully the report > > > > > generation stuff could remain largely unchanged. > > > > > > > > > > -Mark > > > > > > > > > > > -----Original Message----- > > > > > > From: Jody Brownell [mailto:jod...@Q1...] > > > > > > Sent: Friday, May 13, 2005 6:56 AM > > > > > > To: Mark Doliner > > > > > > Cc: cob...@li...; Adam Morgan > > > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > > > > > Sure does - thanks. > > > > > > > > > > > > My first thoughts were - this could be an addon > > > > > package/application of > > > > > > sorts which can use your .ser file or the XML reports (once > > > > > > successfully > > > > > > completed). I would prefer to not touch your guys code at all if > > > > > > possible and just piggy back on what you have - make > > > > enhancements if > > > > > > required. > > > > > > > > > > > > This implies that, the way users run cobertura now would > > > > > not change at > > > > > > all - providing a single user mode of sorts. Then the new > > > > additional > > > > > > task (ant?) could be run to export that data to a central or non > > > > > > volatile data store. (Data store could be RDBMS, flat file or > > > > > > what have > > > > > > you - makes no difference to me - as long as simple and fast). > > > > > > > > > > > > Key things for me are, it needs to be extremely simple to > > > > > install and > > > > > > maintain. No over complicated configuration etc - keep it as > > > > > > it is today > > > > > > as much as possible. > > > > > > > > > > > > Agree about the UI - has to be clean, intuitive, simple > > > and fast. > > > > > > > > > > > > - Be nice to view reports on product? / project / package / > > > > > > class / ... > > > > > > hierarchy - as you navigate through the hierarchy - > > > > > > graph/plot for where > > > > > > you are > > > > > > - plotting lines of code / coverage over time (Jfreechart has > > > > > > some great > > > > > > plots) > > > > > > - Need to identify and ensure we have the right data in the > > > > > > datastore. A > > > > > > few reports which come to mind are > > > > > > - plain coverage stats > > > > > > - plain coverage stats plotted against lines of code > > > > > > - coverage stats of one project/package/class plotted > > > > against the > > > > > > baseline coverage of all projects (how does this > > > > > project/package/class > > > > > > compare to the running average) ( more advanced :)) > > > > > > > > > > > > For now - I will focus on keeping it simple with two > > > > additional ant > > > > > > tasks, one for exporting/updating to non volatile > > > > > datastore, the other > > > > > > for generating reports from that data. I will put together a > > > > > > more formal > > > > > > list of features / requirements over the next few days. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mark Doliner [mailto:Mar...@sa...] > > > > > > Sent: Tuesday, May 10, 2005 12:03 PM > > > > > > To: Jody Brownell > > > > > > Cc: cob...@li... > > > > > > Subject: RE: [Cobertura-devel] How can I get involved.... > > > > > > > > > > > > *snip* > > > > > > > > > > > > > Anywho - the purpose of this email is to see how I can get > > > > > > > involved. One > > > > > > > gap in the product which I noticed (and may already be > > > > planned) is > > > > > > > coverage statistics over time. I was thinking, unless > > > this is on > > > > > > > someone's plate already I could start to get familiar with > > > > > > > the code base > > > > > > > and put together a plan of attack - an impact of sorts - and > > > > > > > propose to > > > > > > > you all. > > > > > > > > > > > > *snip* > > > > > > > > > > > > > Please let me know if this is of interest. BTW - what is > > > > > the typical > > > > > > > process of getting involved? Hope I am not jumping the gun. > > > > > > > > > > > > You're not jumping the gun at all. I suppose the typical > > > > process of > > > > > > getting involved is to find something you're interested in > > > > > > fixing/improving/adding and writing a patch for it. I > > > > don't know of > > > > > > anyone working on statistics over time. And it's > > > > > definitely something > > > > > > that would be nice to have. You would definitely want to > > > > > > work with CVS, > > > > > > if you plan on making any changes. Some of the stuff I > > > > > mention below > > > > > > applies to CVS but not to the last release. > > > > > > > > > > > > I guess the easy way to do it would be to name the XML > > > > > > reports based on > > > > > > the date and time they were created, and then you could parse a > > > > > > directory of these files and determine the change over > > > time. This > > > > > > wouldn't even need to be a part of Cobertura--it could be a > > > > > completely > > > > > > separate program. Or maybe instead of reading the data > > > > from the XML > > > > > > reports, you could read it directly from cobertura.ser files. > > > > > > (The ser > > > > > > file contains basically the same information as the XML > > > > > reports. The > > > > > > ser file contains serialized classes from the package > > > > > > net.sourceforge.cobertura.coveragedata. If you choose to go > > > > > > this route, > > > > > > you would need to use these classes to read the > > > serialized file.) > > > > > > > > > > > > However, it might be better to modify the classes in the > > > > > coveragedata > > > > > > package to natively support a time and date. I'm not > > > > sure how this > > > > > > would work exactly. Maybe you could tag the information in > > > > > > the ser file > > > > > > with a datestamp and then zero it out before running the > > > > > next batch of > > > > > > tests. > > > > > > > > > > > > I think it is important that this have a good user interface. > > > > > > How would > > > > > > the statistics be displayed? As a line graph, maybe? > > > > How would the > > > > > > user tell Cobertura to create these reports? Would > > > they specify a > > > > > > "start date" and "end date"? Would the report have a > > > > > separate display > > > > > > for each package? For each class? Would it have a way to show > > > > > > differences in the source files? > > > > > > > > > > > > Does that help you, any? > > > > > > > > > > > > -Mark > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel |
|
From: Mark D. <ma...@ki...> - 2005-05-20 03:08:10
|
On Thu, 19 May 2005 21:54:26 -0500, Jeremy Ryan Thomerson wrote > I believe so. I think you can close that bug in Tracker. So, > you're doing to do release 1.3 tonight, correct? Yep. > Assuming we release tonight, over the weekend I'll aggregate the > open bugs / feature requests into an email and estimation of how > long each will take to accomplish. Then I'll email it out to > everyone early next week, and we can all collaborate on what pieces > we can take, and when we think we can have them done. This way we > can propose a date for the next release and post it on the site. I've created 2 HTML pages documenting some of the ant and command line syntax. I'll try to remember to close those feature requests after I put those online. > I for one would like to thank Mark for all the work he did to get > this project going and continue improving it. Mark, it's great! > And I really enjoy being a part of it. I think from all the emails > we've received, everyone that's tried it likes it, and I think with > some of the stuff we have coming up on the radar, it will continue > to improve and gain traction. Thanks :-) And I agree, I like seeing all the emails. > Jeremy > > ----- Original Message ----- > From: "Mark Doliner" <ma...@ki...> > To: "Jody Brownell" <jod...@Q1...>; > <cob...@li...> > Sent: Thursday, May 19, 2005 9:19 PM > Subject: Re: [Cobertura-devel] How can I get involved.... > > > Ok, I guess I'm coming around to yous guyses way of thinking. Jeremy's > change > > does a good job of doing what it does. We'll leave it as-is. So the > issue > > with inner classes not being reported is now completely resolved, correct? > > -Mark |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X