Re: commons-monitoring?

Hi Romain, 2013/2/12 Romain Manni-Bucau > well not enough time right now but i hope in some weeks > > the idea would be to get: > -> something to measure (i think it is already here) > -> some basic aop (abstraction, spring, cdi?) > Commons components usually don't have any dependencies. How w

[ANN] Apache Commons Daemon 1.0.13 released

The Apache Commons Daemon team is pleased to announce the commons-daemon-1.0.13 release! Version 1.0.13 is bug fix release fixing various issues found in 1.0.12 and previous releases. Source and binary distributions are available for download from the Apache Commons download site: http://common

Re: svn commit: r1445397 - in /commons/proper/functor/trunk: build-tools/pom.xml pom.xml

> The parent is using groupId org.apache, because it is NOT the functor > top-level pom. >  > So it is not possible to default to it. I didn't see that, my bad. Matt changed the module to be under commons-functor-parent [1] >>     4.0.0 >> -  org.apache.commons >>     commons-functor-build-tools

Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml

On 12 February 2013 21:38, Bruno P. Kinoshita wrote: >> It looks like functor has not yet been released, so we have free >> choice over groupId (and artifactId). > > Exactly, that's why we're also starting threads about serialization, default > arity, interfaces nomenclature, etc :o) > >> We shou

Re: svn commit: r1445397 - in /commons/proper/functor/trunk: build-tools/pom.xml pom.xml

On 12 February 2013 21:34, wrote: > Author: kinow > Date: Tue Feb 12 21:34:47 2013 > New Revision: 1445397 > > URL: http://svn.apache.org/r1445397 > Log: > Setting groupId org.apache.commons in parent POM, and removing it from modules > > Modified: > commons/proper/functor/trunk/build-tools/p

Re: commons-monitoring?

yep but they have the whole stack i spoke about (even if core if not that good as you said) *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.com/in/rmannibuc

Re: commons-monitoring?

If you want to minimize the impact of recording the measurement I disagree. The last time I looked at jamon recording a measurement was synchronized, so recording a measurement in a multithreaded environment was serialized an impacts your scalability. Also seeing the measurement distribution is

Re: [functor] Change default arity of Function, Predicate and Procedure

Sounds reasonable, I agree. Matt On Tue, Feb 12, 2013 at 3:49 PM, Bruno P. Kinoshita wrote: > Hi Matt! > > I changed the default arity with Eclipse help. After a quick glimpse > everything looked fine in the api module. But in core module, the packages > oacf.adapter and oacf.composite have c

Re: [functor] Change default arity of Function, Predicate and Procedure

Hi Matt! I changed the default arity with Eclipse help. After a quick glimpse everything looked fine in the api module. But in core module,  the packages oacf.adapter and oacf.composite  have classes like And and UnaryAnd, that could be updated to NullaryAnd and And, or NullaryAnd and UnaryAnd.

Re: commons-monitoring?

jamon or the more recent javasimon, moskito (even if not completely written and buggy)... are better candidates IMO *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.l

Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml

> It looks like functor has not yet been released, so we have free > choice over groupId (and artifactId). Exactly, that's why we're also starting threads about serialization, default arity, interfaces nomenclature, etc :o) > We should use org.apache.commons for the groupId. Done in r1445397.

Re: commons-monitoring?

Worth taking a look at: code.google.com/p/spf4j --z On Feb 12, 2013, at 4:05 PM, Romain Manni-Bucau wrote: > well not enough time right now but i hope in some weeks > > the idea would be to get: > -> something to measure (i think it is already here) > -> some basic aop (abstraction, spring

Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml

On 12 February 2013 21:09, Matt Benson wrote: > I think Seb and I are in agreement to add groupId to commons-functor-parent > and remove it from every module pom beneath. Yes. Luckily functor has yet to be released so it won't matter if any of the groupIds disagree ... > Matt > > > On Tue, Feb

Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml

On 12 February 2013 21:00, Bruno P. Kinoshita wrote: > Ops, note to self: see the parent pom before posting to the mailing list or > committing to SVN :) Sorry, I thought commons-functor-parent had already a > groupId. > > Let me know what is the best choice then, and I'll update the trunk. It

Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml

I think Seb and I are in agreement to add groupId to commons-functor-parent and remove it from every module pom beneath. Matt On Tue, Feb 12, 2013 at 3:00 PM, Bruno P. Kinoshita < brunodepau...@yahoo.com.br> wrote: > Ops, note to self: see the parent pom before posting to the mailing list > or

Re: commons-monitoring?

well not enough time right now but i hope in some weeks the idea would be to get: -> something to measure (i think it is already here) -> some basic aop (abstraction, spring, cdi?) -> some basic view of the measures (servlet or even a bootstrap webapp ;) with sortable tables...) -> some basic modu

Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml

Ops, note to self: see the parent pom before posting to the mailing list or committing to SVN :) Sorry, I thought commons-functor-parent had already a groupId. Let me know what is the best choice then, and I'll update the trunk. Cheers   Bruno P. Kinoshita http://kinoshita.eti.br http://tupilab

Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml

On 12 February 2013 20:42, Matt Benson wrote: > Wait, now I think we're all getting out of sync with one another. :) I > can respect Sebastian's point that a Commons component's "top" pom > explicitly declare the groupId, particularly in light of his willingness to > omit it from any subordinate

Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml

On 12 February 2013 20:36, Bruno P. Kinoshita wrote: >> But the groupId varies between components, so I think it's important >> to be specific, even if it happens to be the same as the parent. > > > Ah, I think I got it. The build-tools child module has a different groupId > (it's org.apache.comm

Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml

Wait, now I think we're all getting out of sync with one another. :) I can respect Sebastian's point that a Commons component's "top" pom explicitly declare the groupId, particularly in light of his willingness to omit it from any subordinate modules, so actually the change that precipitated this

Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml

> But the groupId varies between components, so I think it's important > to be specific, even if it happens to be the same as the parent.   Ah, I think I got it. The build-tools child module has a different groupId (it's org.apache.commons:commons-functor-build-tools), thus having the groupId ex

Re: CMS/SvnPubSub for site live ?

FYI: rsync from people.a.o has been stopped. So updating web sites will need to go live with cms/svnpubsub. 2013/1/30 Olivier Lamy : > Hi Folks, > Ok to go live ? > > Something missing ? (maybe sandbox parent release ?) > > What else ? > > Content is available for review here: > http://people.apac

Re: [parent] Move report plugins from sandbox-parent to parent?

Hi Sebb 2013/2/12 sebb > On 12 February 2013 20:01, Benedikt Ritter wrote: > > Hi, > > > > more than 48 hours have passed with no objections. Can I just go ahead > and > > change trunk of commons-parent-pom and commons-sandbox-parent-pom? > > The normal waiting period is a minimum of 72 hours.

Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml

On 12 February 2013 04:26, Bruno P. Kinoshita wrote: >>Although strictly speaking the groupId is not required as it is >>inherited from the parent groupId, I think it's best to be explicit. > > I'm fine with or without the groupId in the child project. I think it's > useful to avoid misspellings

Re: [parent] Move report plugins from sandbox-parent to parent?

On 12 February 2013 20:01, Benedikt Ritter wrote: > Hi, > > more than 48 hours have passed with no objections. Can I just go ahead and > change trunk of commons-parent-pom and commons-sandbox-parent-pom? The normal waiting period is a minimum of 72 hours. > Regards, > Benedikt > > 2013/2/10 Bene

Re: svn commit: r1445005 - /commons/proper/functor/trunk/api/pom.xml

On 12 February 2013 07:05, Matt Benson wrote: > Personally I fall on the side of inheriting as much as possible from parent > POMs. If necessary we can have a Commons-wide vote. Yes, for items that are common to all components we should inherit. But the groupId varies between components, so I t

Re: [functor] Change default arity of Function, Predicate and Procedure

Hi Benedikt,  Thanks for taking a look at the github repo and for posting your thoughts here.  If I understand it correctly, your concern is:  - In the github repo, a BinaryFunction is a Binary, and a Binary is an Arity.  - But at same time, it is intuitive that a BinaryFunction "has" an arity,

Re: [parent] Move report plugins from sandbox-parent to parent?

Hi, more than 48 hours have passed with no objections. Can I just go ahead and change trunk of commons-parent-pom and commons-sandbox-parent-pom? Regards, Benedikt 2013/2/10 Benedikt Ritter > Hi, > > while reviewing sandbox-parent release 10 I stumbled across a comment that > the following rep

Re: commons-monitoring?

2013/2/11 Romain Manni-Bucau : > Hi guys, > > is there any activity (or plans) on commons monitoring? IMHO nothing :-) > > it seems pretty old and a lot of work should be done, i would like to know > if it is a project to make alive or not If you want to contribute why not. As the idea sounds inter

Re: [functor] Change default arity of Function, Predicate and Procedure

Hi Matt, 2013/2/12 Matt Benson > Hi Benedikt, > So what you are pointing out is the "is a" vs. "has a" dichotomy? To an > extent, I see your point. I could argue that the semantics of the word > "implements" perhaps leaves a bit of so-called wiggle room on the is a/has > a subject. Now we

Re: [functor] Change default arity of Function, Predicate and Procedure

Hi Benedikt, So what you are pointing out is the "is a" vs. "has a" dichotomy? To an extent, I see your point. I could argue that the semantics of the word "implements" perhaps leaves a bit of so-called wiggle room on the is a/has a subject. This could devolve into a long discussion of the mos

Re: [functor] Change default arity of Function, Predicate and Procedure

Hi Guys, I've had a look at the github repo and let me say at first that I'm no expert in functional programming. So maybe what I'm talking is complete nonsense :) >From what I learned about the concept of arity at wikipedia it seems that an arity is a property of a functor. One could say: "A bin