[ 
https://issues.apache.org/jira/browse/SANDBOX-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102956#comment-13102956
 ] 

Simone Tripodi commented on SANDBOX-341:
----------------------------------------

Hi Liviu!
no pain at all - smart and volunteering people like you are lifeblood for 
community's health, so I am more than happy to put contributors in the position 
of working in the better way ;)

So, to produce those reports, it is enough you run {{mvn clean site && open 
target/site/checkstyle.html}}, it will produce a page like the one actually 
online[1].
Then, if you {{open target/site/cobertura/index.html}} you can have a look at 
the generated cobertura report.
Just take care of classes you put in the summarize and aggregate package, no 
need to take care of the rest - I'm doing it during the spare time, feel free 
to fill a new issue with a new patch anyway ;)

Documentation: take a look at existing pages, the xdoc format[2] is ~html, so 
not hard to write. And yes, just an overview of added classes, samples, 
patterns... under both PoVs of users (how to write client code) and developers 
(extending APIs, if allowed, etc)

Pom: you did write, sorry for the mistake, actually {{{<contributors>}} is the 
right place where adding your name - hopefully you will become a committer :)

Last: the right place where sharing thoughts and discussing is the dev@ ML, in 
Apache there's the mantra "if it didn't happen in the list, it didn't happen", 
JIRA is more like a "wall stories" reminder ;)

Looking forward for the next patch, have a nice day!

[1] http://commons.apache.org/sandbox/functor/checkstyle.html
[2] http://commons.apache.org/sandbox/functor/cobertura/index.html
[3] http://maven.apache.org/doxia/references/xdoc-format.html

> [functor] New components: summarize and aggregate
> -------------------------------------------------
>
>                 Key: SANDBOX-341
>                 URL: https://issues.apache.org/jira/browse/SANDBOX-341
>             Project: Commons Sandbox
>          Issue Type: Improvement
>          Components: Functor
>         Environment: JDK 1.6.0_25 but should work with any JDK 5+ (possibly 
> 1.4 though I haven't tested).
>            Reporter: Liviu Tudor
>            Priority: Minor
>              Labels: features
>         Attachments: commons-functor-aggregate+summarizer.zip, 
> commons-functor.patch.bz2
>
>
> This is the next step from https://issues.apache.org/jira/browse/SANDBOX-340 
> -- as instructed I'm finally hoping to get the code in the right place and 
> hopefully this is something that the functor component could do with.
> Whereas initially I just started with the summarizer component, I have added 
> now the second one, the "aggregator" as they are somehow related. If this 
> code proves to be useful to functor in any way, it would actually be good to 
> get some feedback on these 2 to see if the class hierarchy can in fact be 
> changed to share some common functionality as I feel (probably due to the 
> similar needs that lead to writing/using these components) that somehow they 
> should share a common base.
> In brief, the 2 components:
> * aggregator: this just allows for data to be aggregated in a user defined 
> way (e.g. stored in a list for the purpose of averaging, computing the 
> arithmetic median etc). The classes provided actually offer the 
> implementation for storing data in a list and computing the above-mentioned 
> values or summing up everything.
> * timed summarizer: this is another variation of the aggreator, however, it 
> adds the idea of regular "flushes", so based on a timer it will reset the 
> value and start summing/aggregating the data again. Rather than using an 
> aggregator which would store the whole data series (possibly for applying 
> more complex formulas), this component just computes on the fly on each 
> request the formula and stores the result of it. (Which does mean things like 
> computing arithmetic mean, median etc would be difficult to compute without 
> knowing upfront how many calls will be received -- i.e. how many elements we 
> will be required to summarize/aggregate.) So the memory footprint of running 
> this is much smaller -- even though, as I said, it achieves similar results. 
> I have only provided a summarizer which operates on integers, but obviously 
> others for float, double etc can be created if we go ahead with this design.
> Hopefully the above make sense; this code has resulted from finding myself 
> writing similar components to these a few times and because it's always been 
> either one type (e.g. aggregator) or another (summarizer) I haven't given 
> quite possibly enough thought to the class design to join these 2. Also, 
> unfortunately, the time I sat down to make these components a bit more 
> general and submitted issue 340 was nearly 3 months ago so I'm trying to 
> remember myself all the ideas I had at a time so bear with me please if these 
> are still  a bit fuzzy :) However, if you can make use of these I'm quite 
> happy to elaborate on areas that are unclear and obviously put some effort 
> into getting these components to the standards required to put these into a 
> release.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to