You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simone Tripodi <si...@apache.org> on 2013/05/26 17:35:24 UTC
[Graph] the future of commons-graph and modularization
Hi all, mates,
after a long while I haven't touched commons-graph, I had the
opportunity to get influenced by some activities at my paid work that
made me think twice on what as been already done in that component,
and would like to bring new experiences in.
So, what I still like about it:
* graph APIs: the use of generics make the usage of graphes
extensible and adaptable;
* fluent APIs: this is the most powerful feature IMHO that simplifies
the APIs usage;
What I *don't* like anymore:
* poor modularization: commons-graph is ATM a big fat monolith;
* one single entry-point; for each new family of algorithm(s), new
methods have to be added in the main Commons-Graph class.
What I would like to propose to work _in a separated branch_, is
trying to split the big monolith in smaller modules and separate APIs
from related implementation as much as possible.
Questions are:
* WDYT? :)
* About release process: would it be acceptable, here in commons,
release a single module - the only one that has been changed, I mean -
without releasing the whole project?
* In case the answer to previous question is "no", would it make
sense moving commons-graph to the Incubator (and possibly to TLP)?
TIA, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Graph] the future of commons-graph and modularization
Posted by Simone Tripodi <si...@apache.org>.
Hello Claudio!
nice to read that commons-graph has a real production use case! :)
So, don't worry about APIs breakage: as I mentioned, I'll prepare my
proposal in a separated branch, so you can continue using the current
codebase in your lab without breaking your build :P
Thanks a lot, have a nice day!
All the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, May 26, 2013 at 10:28 PM, Claudio Squarcella
<sq...@dia.uniroma3.it> wrote:
> Hi Simone and all,
>
> good to see activity on commons-graph :-)
>
> I am currently using it for a research project in my lab, so hopefully I'll
> be able to come back with more feedback. In the meantime I agree with what
> you guys wrote so far.
>
> Cheers,
> Claudio
>
>
> On 26/05/2013 20:46, Simone Tripodi wrote:
>>
>> Hi Rodion,
>>
>>> Might the API look like this?
>>> [...]
>>
>> more or less :) Introducing kind of "PathFinder" interface, as main
>> entry point for shortest path algorithms, but keeping the current chin
>> builders - as you notice, `withEuristhic` makes sense for A* only,
>> when current fluent interfaces drive users on choosing the right
>> algorithm, with right inputs, via a "state-machine" which is clever
>> than a simple builder pattern.
>>
>> Anyway
>>
>>> This would seem like eliminating the need for CommonsGraph -monolith at
>>> the
>>> cost of introducing new interfaces/abstract base classes for every type
>>> of
>>> algos out there, plus the actual implementation classes implementing the
>>> API.
>>
>> you got the idea, nice to see we are on the same path!!! :)
>>
>> I'll prepare a more concrete proposal in a branch, hope to read
>> reviews from your side! :)
>>
>> All the best,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Sun, May 26, 2013 at 6:10 PM, Rodion Efremov
>> <ro...@cs.helsinki.fi> wrote:
>>>
>>> Simone Tripodi kirjoitti 26.05.2013 18:35:
>>>
>>>> Hi all, mates,
>>>>
>>>> after a long while I haven't touched commons-graph, I had the
>>>> opportunity to get influenced by some activities at my paid work that
>>>> made me think twice on what as been already done in that component,
>>>> and would like to bring new experiences in.
>>>>
>>>> So, what I still like about it:
>>>>
>>>> * graph APIs: the use of generics make the usage of graphes
>>>> extensible and adaptable;
>>>>
>>>> * fluent APIs: this is the most powerful feature IMHO that simplifies
>>>> the APIs usage;
>>>>
>>>> What I *don't* like anymore:
>>>>
>>>> * poor modularization: commons-graph is ATM a big fat monolith;
>>>>
>>>> * one single entry-point; for each new family of algorithm(s), new
>>>> methods have to be added in the main Commons-Graph class.
>>>>
>>>> What I would like to propose to work _in a separated branch_, is
>>>> trying to split the big monolith in smaller modules and separate APIs
>>>> from related implementation as much as possible.
>>>>
>>>> Questions are:
>>>>
>>>> * WDYT? :)
>>>
>>>
>>> Might the API look like this?
>>>
>>> public interface PathFinder<V, E, W> {
>>> public Path<V, E> search();
>>> public PathFinder<V, E, W> from( V source );
>>> public PathFinder<V, E, W> to( V target );
>>> public PathFinder<V, E, W> withHeuristic( HeuristicFunction<V, W> f
>>> );
>>> // for A* search.
>>> }
>>>
>>> ... and then we would have, say, A* as follows:
>>>
>>> public class AStarFinder<V, E, W> implements PathFinder<V, E, W> {
>>> public Path<V, E> search() {
>>> // A* magic here.
>>> }
>>>
>>> ... implement the rest.
>>> }
>>>
>>> ... with usage as follows:
>>>
>>> Path<V, E> path = new AStarFinder<V, E, W>().withHeuristic(
>>> myFunkyHeuristic
>>> ).from( source ).to( target ).search();
>>>
>>> This would seem like eliminating the need for CommonsGraph -monolith at
>>> the
>>> cost of introducing new interfaces/abstract base classes for every type
>>> of
>>> algos out there, plus the actual implementation classes implementing the
>>> API.
>>>
>>>> * About release process: would it be acceptable, here in commons,
>>>> release a single module - the only one that has been changed, I mean -
>>>> without releasing the whole project?
>>>>
>>>> * In case the answer to previous question is "no", would it make
>>>> sense moving commons-graph to the Incubator (and possibly to TLP)?
>>>>
>>>> TIA, all the best!
>>>> -Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> --
> Claudio Squarcella
> PhD student at Roma Tre University
> http://www.dia.uniroma3.it/~squarcel
> http://twitter.com/hyperboreans
> http://claudiosquarcella.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Graph] the future of commons-graph and modularization
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
Hi Simone and all,
good to see activity on commons-graph :-)
I am currently using it for a research project in my lab, so hopefully
I'll be able to come back with more feedback. In the meantime I agree
with what you guys wrote so far.
Cheers,
Claudio
On 26/05/2013 20:46, Simone Tripodi wrote:
> Hi Rodion,
>
>> Might the API look like this?
>> [...]
> more or less :) Introducing kind of "PathFinder" interface, as main
> entry point for shortest path algorithms, but keeping the current chin
> builders - as you notice, `withEuristhic` makes sense for A* only,
> when current fluent interfaces drive users on choosing the right
> algorithm, with right inputs, via a "state-machine" which is clever
> than a simple builder pattern.
>
> Anyway
>
>> This would seem like eliminating the need for CommonsGraph -monolith at the
>> cost of introducing new interfaces/abstract base classes for every type of
>> algos out there, plus the actual implementation classes implementing the
>> API.
> you got the idea, nice to see we are on the same path!!! :)
>
> I'll prepare a more concrete proposal in a branch, hope to read
> reviews from your side! :)
>
> All the best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Sun, May 26, 2013 at 6:10 PM, Rodion Efremov
> <ro...@cs.helsinki.fi> wrote:
>> Simone Tripodi kirjoitti 26.05.2013 18:35:
>>
>>> Hi all, mates,
>>>
>>> after a long while I haven't touched commons-graph, I had the
>>> opportunity to get influenced by some activities at my paid work that
>>> made me think twice on what as been already done in that component,
>>> and would like to bring new experiences in.
>>>
>>> So, what I still like about it:
>>>
>>> * graph APIs: the use of generics make the usage of graphes
>>> extensible and adaptable;
>>>
>>> * fluent APIs: this is the most powerful feature IMHO that simplifies
>>> the APIs usage;
>>>
>>> What I *don't* like anymore:
>>>
>>> * poor modularization: commons-graph is ATM a big fat monolith;
>>>
>>> * one single entry-point; for each new family of algorithm(s), new
>>> methods have to be added in the main Commons-Graph class.
>>>
>>> What I would like to propose to work _in a separated branch_, is
>>> trying to split the big monolith in smaller modules and separate APIs
>>> from related implementation as much as possible.
>>>
>>> Questions are:
>>>
>>> * WDYT? :)
>>
>> Might the API look like this?
>>
>> public interface PathFinder<V, E, W> {
>> public Path<V, E> search();
>> public PathFinder<V, E, W> from( V source );
>> public PathFinder<V, E, W> to( V target );
>> public PathFinder<V, E, W> withHeuristic( HeuristicFunction<V, W> f );
>> // for A* search.
>> }
>>
>> ... and then we would have, say, A* as follows:
>>
>> public class AStarFinder<V, E, W> implements PathFinder<V, E, W> {
>> public Path<V, E> search() {
>> // A* magic here.
>> }
>>
>> ... implement the rest.
>> }
>>
>> ... with usage as follows:
>>
>> Path<V, E> path = new AStarFinder<V, E, W>().withHeuristic( myFunkyHeuristic
>> ).from( source ).to( target ).search();
>>
>> This would seem like eliminating the need for CommonsGraph -monolith at the
>> cost of introducing new interfaces/abstract base classes for every type of
>> algos out there, plus the actual implementation classes implementing the
>> API.
>>
>>> * About release process: would it be acceptable, here in commons,
>>> release a single module - the only one that has been changed, I mean -
>>> without releasing the whole project?
>>>
>>> * In case the answer to previous question is "no", would it make
>>> sense moving commons-graph to the Incubator (and possibly to TLP)?
>>>
>>> TIA, all the best!
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Claudio Squarcella
PhD student at Roma Tre University
http://www.dia.uniroma3.it/~squarcel
http://twitter.com/hyperboreans
http://claudiosquarcella.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Graph] the future of commons-graph and modularization
Posted by Simone Tripodi <si...@apache.org>.
Hi Rodion,
>
> Might the API look like this?
> [...]
more or less :) Introducing kind of "PathFinder" interface, as main
entry point for shortest path algorithms, but keeping the current chin
builders - as you notice, `withEuristhic` makes sense for A* only,
when current fluent interfaces drive users on choosing the right
algorithm, with right inputs, via a "state-machine" which is clever
than a simple builder pattern.
Anyway
>
> This would seem like eliminating the need for CommonsGraph -monolith at the
> cost of introducing new interfaces/abstract base classes for every type of
> algos out there, plus the actual implementation classes implementing the
> API.
you got the idea, nice to see we are on the same path!!! :)
I'll prepare a more concrete proposal in a branch, hope to read
reviews from your side! :)
All the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, May 26, 2013 at 6:10 PM, Rodion Efremov
<ro...@cs.helsinki.fi> wrote:
> Simone Tripodi kirjoitti 26.05.2013 18:35:
>
>> Hi all, mates,
>>
>> after a long while I haven't touched commons-graph, I had the
>> opportunity to get influenced by some activities at my paid work that
>> made me think twice on what as been already done in that component,
>> and would like to bring new experiences in.
>>
>> So, what I still like about it:
>>
>> * graph APIs: the use of generics make the usage of graphes
>> extensible and adaptable;
>>
>> * fluent APIs: this is the most powerful feature IMHO that simplifies
>> the APIs usage;
>>
>> What I *don't* like anymore:
>>
>> * poor modularization: commons-graph is ATM a big fat monolith;
>>
>> * one single entry-point; for each new family of algorithm(s), new
>> methods have to be added in the main Commons-Graph class.
>>
>> What I would like to propose to work _in a separated branch_, is
>> trying to split the big monolith in smaller modules and separate APIs
>> from related implementation as much as possible.
>>
>> Questions are:
>>
>> * WDYT? :)
>
>
> Might the API look like this?
>
> public interface PathFinder<V, E, W> {
> public Path<V, E> search();
> public PathFinder<V, E, W> from( V source );
> public PathFinder<V, E, W> to( V target );
> public PathFinder<V, E, W> withHeuristic( HeuristicFunction<V, W> f );
> // for A* search.
> }
>
> ... and then we would have, say, A* as follows:
>
> public class AStarFinder<V, E, W> implements PathFinder<V, E, W> {
> public Path<V, E> search() {
> // A* magic here.
> }
>
> ... implement the rest.
> }
>
> ... with usage as follows:
>
> Path<V, E> path = new AStarFinder<V, E, W>().withHeuristic( myFunkyHeuristic
> ).from( source ).to( target ).search();
>
> This would seem like eliminating the need for CommonsGraph -monolith at the
> cost of introducing new interfaces/abstract base classes for every type of
> algos out there, plus the actual implementation classes implementing the
> API.
>
>> * About release process: would it be acceptable, here in commons,
>> release a single module - the only one that has been changed, I mean -
>> without releasing the whole project?
>>
>> * In case the answer to previous question is "no", would it make
>> sense moving commons-graph to the Incubator (and possibly to TLP)?
>>
>> TIA, all the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Graph] the future of commons-graph and modularization
Posted by Rodion Efremov <ro...@cs.helsinki.fi>.
Simone Tripodi kirjoitti 26.05.2013 18:35:
> Hi all, mates,
>
> after a long while I haven't touched commons-graph, I had the
> opportunity to get influenced by some activities at my paid work that
> made me think twice on what as been already done in that component,
> and would like to bring new experiences in.
>
> So, what I still like about it:
>
> * graph APIs: the use of generics make the usage of graphes
> extensible and adaptable;
>
> * fluent APIs: this is the most powerful feature IMHO that
> simplifies
> the APIs usage;
>
> What I *don't* like anymore:
>
> * poor modularization: commons-graph is ATM a big fat monolith;
>
> * one single entry-point; for each new family of algorithm(s), new
> methods have to be added in the main Commons-Graph class.
>
> What I would like to propose to work _in a separated branch_, is
> trying to split the big monolith in smaller modules and separate APIs
> from related implementation as much as possible.
>
> Questions are:
>
> * WDYT? :)
Might the API look like this?
public interface PathFinder<V, E, W> {
public Path<V, E> search();
public PathFinder<V, E, W> from( V source );
public PathFinder<V, E, W> to( V target );
public PathFinder<V, E, W> withHeuristic( HeuristicFunction<V, W> f
); // for A* search.
}
... and then we would have, say, A* as follows:
public class AStarFinder<V, E, W> implements PathFinder<V, E, W> {
public Path<V, E> search() {
// A* magic here.
}
... implement the rest.
}
... with usage as follows:
Path<V, E> path = new AStarFinder<V, E, W>().withHeuristic(
myFunkyHeuristic ).from( source ).to( target ).search();
This would seem like eliminating the need for CommonsGraph -monolith at
the cost of introducing new interfaces/abstract base classes for every
type of algos out there, plus the actual implementation classes
implementing the API.
> * About release process: would it be acceptable, here in commons,
> release a single module - the only one that has been changed, I mean
> -
> without releasing the whole project?
>
> * In case the answer to previous question is "no", would it make
> sense moving commons-graph to the Incubator (and possibly to TLP)?
>
> TIA, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Followup][Graph] the future of commons-graph and modularization
Posted by Simone Tripodi <si...@apache.org>.
Olá Bruno!
thanks *a lot* for reviewing the experimental branch for
modulazitation, really much more than appreciated!
And thanks a lot for setting up the Jenkins job, it does help!
Have a nice WE, all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Fri, May 31, 2013 at 6:57 PM, Bruno P. Kinoshita
<br...@yahoo.com.br> wrote:
> Hi Simo!
>
> I liked the project structure, it's looking like the new structure that Matt created in commons-functor [1], with a API project, one module for each algorithm family and other modules for utility projects, like benchmark tests.
>
> I think we'll have to update the website, since now under Project Documentation / Project Modules, the links to the submodules pages are broken.
>
> So kudos for the great work and my +1 for the modularization of commons-graph. Since I'm not very familiar with commons-graph code base and haven't used it in any project yet, probably other's comments will be important on this thread too.
>
> Side note, I noticed that there are some TODO's, mainly in Javadocs. So I've set up a job in Jenkins [2] with the Maven site + open tasks (FIXME, TODO and TBD). I'll read the open tasks later to see if I can work on any of them, but I think I'll wait for the modularization branch to be merged first :)
>
> Cheers
>
> [1] http://svn.apache.org/viewvc/commons/proper/functor/trunk/
> [2] http://builds.tupilabs.com/job/commons-graph-modularization/1/tasksResult/
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>
> --- Em ter, 28/5/13, Simone Tripodi <si...@apache.org> escreveu:
>
>> De: Simone Tripodi <si...@apache.org>
>> Assunto: [Followup][Graph] the future of commons-graph and modularization
>> Para: "Commons Developers List" <de...@commons.apache.org>
>> Data: Terça-feira, 28 de Maio de 2013, 12:06
>> Hi all guys,
>>
>> here it is my proposal[1], see r1486948.
>>
>> It has been quiet hard since he did not think in therms of
>> separated
>> modules, so I took the freedom to relocate some classes here
>> and
>> there. It is a experimental branch anyway, the purpose is
>> just
>> demonstrating the PoC.
>>
>> Looking forward to read your feedbacks!
>>
>> Many thanks in advance, all the best,
>> -Simo
>>
>> [1] http://svn.apache.org/repos/asf/commons/sandbox/graph/branches/modularization/
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Sun, May 26, 2013 at 5:35 PM, Simone Tripodi
>> <si...@apache.org>
>> wrote:
>> > Hi all, mates,
>> >
>> > after a long while I haven't touched commons-graph, I
>> had the
>> > opportunity to get influenced by some activities at my
>> paid work that
>> > made me think twice on what as been already done in
>> that component,
>> > and would like to bring new experiences in.
>> >
>> > So, what I still like about it:
>> >
>> > * graph APIs: the use of generics make the usage
>> of graphes
>> > extensible and adaptable;
>> >
>> > * fluent APIs: this is the most powerful feature
>> IMHO that simplifies
>> > the APIs usage;
>> >
>> > What I *don't* like anymore:
>> >
>> > * poor modularization: commons-graph is ATM a big
>> fat monolith;
>> >
>> > * one single entry-point; for each new family of
>> algorithm(s), new
>> > methods have to be added in the main Commons-Graph
>> class.
>> >
>> > What I would like to propose to work _in a separated
>> branch_, is
>> > trying to split the big monolith in smaller modules and
>> separate APIs
>> > from related implementation as much as possible.
>> >
>> > Questions are:
>> >
>> > * WDYT? :)
>> >
>> > * About release process: would it be acceptable,
>> here in commons,
>> > release a single module - the only one that has been
>> changed, I mean -
>> > without releasing the whole project?
>> >
>> > * In case the answer to previous question is
>> "no", would it make
>> > sense moving commons-graph to the Incubator (and
>> possibly to TLP)?
>> >
>> > TIA, all the best!
>> > -Simo
>> >
>> > http://people.apache.org/~simonetripodi/
>> > http://simonetripodi.livejournal.com/
>> > http://twitter.com/simonetripodi
>> > http://www.99soft.org/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Followup][Graph] the future of commons-graph and modularization
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br>.
Hi Simo!
I liked the project structure, it's looking like the new structure that Matt created in commons-functor [1], with a API project, one module for each algorithm family and other modules for utility projects, like benchmark tests.
I think we'll have to update the website, since now under Project Documentation / Project Modules, the links to the submodules pages are broken.
So kudos for the great work and my +1 for the modularization of commons-graph. Since I'm not very familiar with commons-graph code base and haven't used it in any project yet, probably other's comments will be important on this thread too.
Side note, I noticed that there are some TODO's, mainly in Javadocs. So I've set up a job in Jenkins [2] with the Maven site + open tasks (FIXME, TODO and TBD). I'll read the open tasks later to see if I can work on any of them, but I think I'll wait for the modularization branch to be merged first :)
Cheers
[1] http://svn.apache.org/viewvc/commons/proper/functor/trunk/
[2] http://builds.tupilabs.com/job/commons-graph-modularization/1/tasksResult/
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com
--- Em ter, 28/5/13, Simone Tripodi <si...@apache.org> escreveu:
> De: Simone Tripodi <si...@apache.org>
> Assunto: [Followup][Graph] the future of commons-graph and modularization
> Para: "Commons Developers List" <de...@commons.apache.org>
> Data: Terça-feira, 28 de Maio de 2013, 12:06
> Hi all guys,
>
> here it is my proposal[1], see r1486948.
>
> It has been quiet hard since he did not think in therms of
> separated
> modules, so I took the freedom to relocate some classes here
> and
> there. It is a experimental branch anyway, the purpose is
> just
> demonstrating the PoC.
>
> Looking forward to read your feedbacks!
>
> Many thanks in advance, all the best,
> -Simo
>
> [1] http://svn.apache.org/repos/asf/commons/sandbox/graph/branches/modularization/
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Sun, May 26, 2013 at 5:35 PM, Simone Tripodi
> <si...@apache.org>
> wrote:
> > Hi all, mates,
> >
> > after a long while I haven't touched commons-graph, I
> had the
> > opportunity to get influenced by some activities at my
> paid work that
> > made me think twice on what as been already done in
> that component,
> > and would like to bring new experiences in.
> >
> > So, what I still like about it:
> >
> > * graph APIs: the use of generics make the usage
> of graphes
> > extensible and adaptable;
> >
> > * fluent APIs: this is the most powerful feature
> IMHO that simplifies
> > the APIs usage;
> >
> > What I *don't* like anymore:
> >
> > * poor modularization: commons-graph is ATM a big
> fat monolith;
> >
> > * one single entry-point; for each new family of
> algorithm(s), new
> > methods have to be added in the main Commons-Graph
> class.
> >
> > What I would like to propose to work _in a separated
> branch_, is
> > trying to split the big monolith in smaller modules and
> separate APIs
> > from related implementation as much as possible.
> >
> > Questions are:
> >
> > * WDYT? :)
> >
> > * About release process: would it be acceptable,
> here in commons,
> > release a single module - the only one that has been
> changed, I mean -
> > without releasing the whole project?
> >
> > * In case the answer to previous question is
> "no", would it make
> > sense moving commons-graph to the Incubator (and
> possibly to TLP)?
> >
> > TIA, all the best!
> > -Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://simonetripodi.livejournal.com/
> > http://twitter.com/simonetripodi
> > http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[Followup][Graph] the future of commons-graph and modularization
Posted by Simone Tripodi <si...@apache.org>.
Hi all guys,
here it is my proposal[1], see r1486948.
It has been quiet hard since he did not think in therms of separated
modules, so I took the freedom to relocate some classes here and
there. It is a experimental branch anyway, the purpose is just
demonstrating the PoC.
Looking forward to read your feedbacks!
Many thanks in advance, all the best,
-Simo
[1] http://svn.apache.org/repos/asf/commons/sandbox/graph/branches/modularization/
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, May 26, 2013 at 5:35 PM, Simone Tripodi
<si...@apache.org> wrote:
> Hi all, mates,
>
> after a long while I haven't touched commons-graph, I had the
> opportunity to get influenced by some activities at my paid work that
> made me think twice on what as been already done in that component,
> and would like to bring new experiences in.
>
> So, what I still like about it:
>
> * graph APIs: the use of generics make the usage of graphes
> extensible and adaptable;
>
> * fluent APIs: this is the most powerful feature IMHO that simplifies
> the APIs usage;
>
> What I *don't* like anymore:
>
> * poor modularization: commons-graph is ATM a big fat monolith;
>
> * one single entry-point; for each new family of algorithm(s), new
> methods have to be added in the main Commons-Graph class.
>
> What I would like to propose to work _in a separated branch_, is
> trying to split the big monolith in smaller modules and separate APIs
> from related implementation as much as possible.
>
> Questions are:
>
> * WDYT? :)
>
> * About release process: would it be acceptable, here in commons,
> release a single module - the only one that has been changed, I mean -
> without releasing the whole project?
>
> * In case the answer to previous question is "no", would it make
> sense moving commons-graph to the Incubator (and possibly to TLP)?
>
> TIA, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org