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
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 most
Hi Matt,
2013/2/12 Matt Benson gudnabr...@gmail.com
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.
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 brit...@apache.org
Hi,
while reviewing sandbox-parent release 10 I stumbled across a comment that
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,
On 12 February 2013 07:05, Matt Benson gudnabr...@gmail.com 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
On 12 February 2013 20:01, Benedikt Ritter brit...@apache.org 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
On 12 February 2013 04:26, Bruno P. Kinoshita ki...@apache.org 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
Hi Sebb
2013/2/12 sebb seb...@gmail.com
On 12 February 2013 20:01, Benedikt Ritter brit...@apache.org 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
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
On 12 February 2013 20:36, Bruno P. Kinoshita
brunodepau...@yahoo.com.br 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
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
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 module
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
On 12 February 2013 21:00, Bruno P. Kinoshita
brunodepau...@yahoo.com.br 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
On 12 February 2013 21:09, Matt Benson gudnabr...@gmail.com 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
Worth taking a look at:
code.google.com/p/spf4j
--z
On Feb 12, 2013, at 4:05 PM, Romain Manni-Bucau rmannibu...@gmail.com 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
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.
jamon or the more recent javasimon, moskito (even if not completely written
and buggy)... are better candidates IMO
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn:
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
Sounds reasonable, I agree.
Matt
On Tue, Feb 12, 2013 at 3:49 PM, Bruno P. Kinoshita ki...@apache.orgwrote:
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
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 https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
On 12 February 2013 21:34, ki...@apache.org 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:
On 12 February 2013 21:38, Bruno P. Kinoshita ki...@apache.org 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)
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]
modelVersion4.0.0/modelVersion
- groupIdorg.apache.commons/groupId
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:
Hi Romain,
2013/2/12 Romain Manni-Bucau rmannibu...@gmail.com
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
27 matches
Mail list logo
