Hi all,
thank you for your answers!
As Thomas suggests, maybe the right solution is to build that stuff in
[graph]. Or maybe even in a new project for computational geometry and
graph drawing! I agree that including [graph] as a dependency for [math]
does not sound quite right; maybe the other way around ...
Also since we're talking of [math+graph], we had another overlap
recently while dealing with properties of weights -- you know,
semigroups, monoids, that kind of stuff. I think at some point we should
"sit together" and understand how to deal with common concepts in a
unified way.
Best,
Claudio
On 23/02/2012 10:30, Thomas Neidhart wrote:
On Wed, Feb 22, 2012 at 1:14 PM, Simone Tripodi<simonetrip...@apache.org>wrote:
Hi Gilles,
having a self-contained library is indeed *really* important, you get
a big +1 from my side.
Anyway, I'd suggest you to adopt a strategy of shading [graph] stuff
useful for math, without duplicating the code nor bring the [graph]
dependency in [math].
[graph] codebase is ATM in a decent state, what we miss is a little
bit of documentation and 2-3 algorithms impl, but in therms of design
I think we found a way and additional stuff can be added later in new
releases.
OTOH, we are still a little far from having arelease in the immediate
future, so I cannot promise "we are ready in 1 month" to release :P
As Gilles said, the self-containment of CM is a strong point, and I doubt
if this policy should be changed.
OTOH, duplicating things does not make sense either, so we will have to
see. If the addition of these new features
results in a o.a.c.m.graph package, then CM is maybe not the right place
for it.
Thomas
--
Claudio Squarcella
PhD student at Roma Tre University
http://www.dia.uniroma3.it/~squarcel
http://squarcella.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
