[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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] the future of commons-graph and modularization
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 PathFinderV, E, W {
public PathV, E search();
public PathFinderV, E, W from( V source );
public PathFinderV, E, W to( V target );
public PathFinderV, E, W withHeuristic( HeuristicFunctionV, W f
); // for A* search.
}
... and then we would have, say, A* as follows:
public class AStarFinderV, E, W implements PathFinderV, E, W {
public PathV, E search() {
// A* magic here.
}
... implement the rest.
}
... with usage as follows:
PathV, E path = new AStarFinderV, 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OT] git and svn properties
Hi Luc, Am 25.05.2013 21:53, schrieb Luc Maisonobe: Le 25/05/2013 21:16, Oliver Heger a écrit : Hi all, Hi Oliver, recently I switched from svn to git and now use git svn to do my commits. One problem I have with this setup is that git svn does not honor the autoprops configured for svn. Therefore, all newly added files are missing these properties. I think I am not the only git user here. So I would like to ask how others address this problem. This is the setting I have been used for months (probably more than one year). This seems strange to me, I thought git svn honoured the autoprops. Looking back at a commit where I created lots of newx files (like http://markmail.org/message/4yb4yzp2ixqvhl2e), the properties where set properly. So I think it works for me. In my case, I work on Linux and the subversion properties are set in a file $HOME/.subversion/config. There is also one specific property that may need to be set specifically for git, it is the line-endings encoding. On a Linux machine, I globally set core.autocrlf ot input (the setting must be different for Windows). thanks for your answer. Hm, it may be an OS-specific issue then (I am on Windows). I found contradictory information on the net. While some say svn autoprops would work, there is the following statement in [1] (which should be the reference) in the Bugs section: We ignore all SVN properties except svn:executable. Will have to do some more research, but currently I even don't know whether this is supposed to work :-( If somebody has a working configuration for Windows, please let me know! Thanks Oliver [1] https://www.kernel.org/pub/software/scm/git/docs/git-svn.html Luc Thanks in advance! Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OT] git and svn properties
Or... We could switch from svn to git. I know, I know, I don't want to start another 1000 message long thread. ;) Gary On May 26, 2013, at 13:06, Oliver Heger oliver.he...@oliver-heger.de wrote: Hi Luc, Am 25.05.2013 21:53, schrieb Luc Maisonobe: Le 25/05/2013 21:16, Oliver Heger a écrit : Hi all, Hi Oliver, recently I switched from svn to git and now use git svn to do my commits. One problem I have with this setup is that git svn does not honor the autoprops configured for svn. Therefore, all newly added files are missing these properties. I think I am not the only git user here. So I would like to ask how others address this problem. This is the setting I have been used for months (probably more than one year). This seems strange to me, I thought git svn honoured the autoprops. Looking back at a commit where I created lots of newx files (like http://markmail.org/message/4yb4yzp2ixqvhl2e), the properties where set properly. So I think it works for me. In my case, I work on Linux and the subversion properties are set in a file $HOME/.subversion/config. There is also one specific property that may need to be set specifically for git, it is the line-endings encoding. On a Linux machine, I globally set core.autocrlf ot input (the setting must be different for Windows). thanks for your answer. Hm, it may be an OS-specific issue then (I am on Windows). I found contradictory information on the net. While some say svn autoprops would work, there is the following statement in [1] (which should be the reference) in the Bugs section: We ignore all SVN properties except svn:executable. Will have to do some more research, but currently I even don't know whether this is supposed to work :-( If somebody has a working configuration for Windows, please let me know! Thanks Oliver [1] https://www.kernel.org/pub/software/scm/git/docs/git-svn.html Luc Thanks in advance! Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons - Commons Compress -
Group (shared) Maven 2 Build Definition (Java 1.5) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Continuum-Build-Host: vmbuild X-Continuum-Project-Id: 64 X-Continuum-Project-Name: Commons Compress Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=26994projectId=64 Build statistics: State: Failed Previous State: Failed Started at: Sun 26 May 2013 18:20:07 + Finished at: Sun 26 May 2013 18:20:25 + Total time: 18s Build Trigger: Schedule Build Number: 276 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_30 Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_30 Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: linux version: 2.6.32-41-server arch: amd64 Family: unix SCM Changes: Changed: bodewig @ Sun 26 May 2013 17:28:17 + Comment: COMPRESS-227 make test more complete Files changed: /commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java ( 1486436 ) Changed: bodewig @ Sun 26 May 2013 17:36:35 + Comment: COMPRESS-228 be more lenient when parsing zip64 extra field Files changed: /commons/proper/compress/trunk/src/changes/changes.xml ( 1486437 ) /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/Zip64ExtendedInformationExtraField.java ( 1486437 ) /commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/zip/ZipFileTest.java ( 1486437 ) /commons/proper/compress/trunk/src/test/resources/COMPRESS-228.zip ( 1486437 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Group (shared) Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 0 Failures: 0 Errors: 0 Total time: 0.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] the future of commons-graph and modularization
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
rodion.efre...@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 PathFinderV, E, W {
public PathV, E search();
public PathFinderV, E, W from( V source );
public PathFinderV, E, W to( V target );
public PathFinderV, E, W withHeuristic( HeuristicFunctionV, W f );
// for A* search.
}
... and then we would have, say, A* as follows:
public class AStarFinderV, E, W implements PathFinderV, E, W {
public PathV, E search() {
// A* magic here.
}
... implement the rest.
}
... with usage as follows:
PathV, E path = new AStarFinderV, 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OT] git and svn properties
Le 26/05/2013 19:53, Gary Gregory a écrit : Or... We could switch from svn to git. +1 from me. I have been using git for quite some time now and am particularly happy with it (well I was also happy when I switched from SCCS to RCS to CVS to SVN, and will probably also like what the next generation will bring after Git). One drawback, though, is that it needs some time to get used to it. We should really have a large number of committers in favor of such a change to do it. Just in order to have a rough idea, how many of us already use Git, how many don't use it but would like to give it a try, and how many don't want it? I'm not sure if we could switch only some components first and the other ones later on. As we already have a specific layout with two layers (proper/sandbox/dormant) and then all the components, it may need some tricks and help from infra. Luc I know, I know, I don't want to start another 1000 message long thread. ;) Gary On May 26, 2013, at 13:06, Oliver Heger oliver.he...@oliver-heger.de wrote: Hi Luc, Am 25.05.2013 21:53, schrieb Luc Maisonobe: Le 25/05/2013 21:16, Oliver Heger a écrit : Hi all, Hi Oliver, recently I switched from svn to git and now use git svn to do my commits. One problem I have with this setup is that git svn does not honor the autoprops configured for svn. Therefore, all newly added files are missing these properties. I think I am not the only git user here. So I would like to ask how others address this problem. This is the setting I have been used for months (probably more than one year). This seems strange to me, I thought git svn honoured the autoprops. Looking back at a commit where I created lots of newx files (like http://markmail.org/message/4yb4yzp2ixqvhl2e), the properties where set properly. So I think it works for me. In my case, I work on Linux and the subversion properties are set in a file $HOME/.subversion/config. There is also one specific property that may need to be set specifically for git, it is the line-endings encoding. On a Linux machine, I globally set core.autocrlf ot input (the setting must be different for Windows). thanks for your answer. Hm, it may be an OS-specific issue then (I am on Windows). I found contradictory information on the net. While some say svn autoprops would work, there is the following statement in [1] (which should be the reference) in the Bugs section: We ignore all SVN properties except svn:executable. Will have to do some more research, but currently I even don't know whether this is supposed to work :-( If somebody has a working configuration for Windows, please let me know! Thanks Oliver [1] https://www.kernel.org/pub/software/scm/git/docs/git-svn.html Luc Thanks in advance! Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] the future of commons-graph and modularization
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
rodion.efre...@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 PathFinderV, E, W {
public PathV, E search();
public PathFinderV, E, W from( V source );
public PathFinderV, E, W to( V target );
public PathFinderV, E, W withHeuristic( HeuristicFunctionV, W f );
// for A* search.
}
... and then we would have, say, A* as follows:
public class AStarFinderV, E, W implements PathFinderV, E, W {
public PathV, E search() {
// A* magic here.
}
... implement the rest.
}
... with usage as follows:
PathV, E path = new AStarFinderV, 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OT] git and svn properties
In general, I like the simplicity of dealing with one jar. How big is it now? Gary On May 26, 2013, at 15:48, Oliver Heger oliver.he...@oliver-heger.de wrote: Am 26.05.2013 21:39, schrieb Luc Maisonobe: Le 26/05/2013 19:53, Gary Gregory a écrit : Or... We could switch from svn to git. +1 from me. I have been using git for quite some time now and am particularly happy with it (well I was also happy when I switched from SCCS to RCS to CVS to SVN, and will probably also like what the next generation will bring after Git). One drawback, though, is that it needs some time to get used to it. We should really have a large number of committers in favor of such a change to do it. Just in order to have a rough idea, how many of us already use Git, how many don't use it but would like to give it a try, and how many don't want it? I'm not sure if we could switch only some components first and the other ones later on. As we already have a specific layout with two layers (proper/sandbox/dormant) and then all the components, it may need some tricks and help from infra. This sounds reasonable. If we want to do such a move, we should do it carefully. Anyway, you can count me to the group in favor of git. I don't want to miss it any more. Oliver Luc I know, I know, I don't want to start another 1000 message long thread. ;) Gary On May 26, 2013, at 13:06, Oliver Heger oliver.he...@oliver-heger.de wrote: Hi Luc, Am 25.05.2013 21:53, schrieb Luc Maisonobe: Le 25/05/2013 21:16, Oliver Heger a écrit : Hi all, Hi Oliver, recently I switched from svn to git and now use git svn to do my commits. One problem I have with this setup is that git svn does not honor the autoprops configured for svn. Therefore, all newly added files are missing these properties. I think I am not the only git user here. So I would like to ask how others address this problem. This is the setting I have been used for months (probably more than one year). This seems strange to me, I thought git svn honoured the autoprops. Looking back at a commit where I created lots of newx files (like http://markmail.org/message/4yb4yzp2ixqvhl2e), the properties where set properly. So I think it works for me. In my case, I work on Linux and the subversion properties are set in a file $HOME/.subversion/config. There is also one specific property that may need to be set specifically for git, it is the line-endings encoding. On a Linux machine, I globally set core.autocrlf ot input (the setting must be different for Windows). thanks for your answer. Hm, it may be an OS-specific issue then (I am on Windows). I found contradictory information on the net. While some say svn autoprops would work, there is the following statement in [1] (which should be the reference) in the Bugs section: We ignore all SVN properties except svn:executable. Will have to do some more research, but currently I even don't know whether this is supposed to work :-( If somebody has a working configuration for Windows, please let me know! Thanks Oliver [1] https://www.kernel.org/pub/software/scm/git/docs/git-svn.html Luc Thanks in advance! Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] the future of commons-graph and modularization
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
squar...@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
rodion.efre...@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 PathFinderV, E, W {
public PathV, E search();
public PathFinderV, E, W from( V source );
public PathFinderV, E, W to( V target );
public PathFinderV, E, W withHeuristic( HeuristicFunctionV, W f
);
// for A* search.
}
... and then we would have, say, A* as follows:
public class AStarFinderV, E, W implements PathFinderV, E, W {
public PathV, E search() {
// A* magic here.
}
... implement the rest.
}
... with usage as follows:
PathV, E path = new AStarFinderV, 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
Claudio Squarcella
PhD student at Roma Tre University
http://www.dia.uniroma3.it/~squarcel
Re: [OT] git and svn properties
Le 26/05/2013 19:53, Gary Gregory a écrit : Or... We could switch from svn to git. I know, I know, I don't want to start another 1000 message long thread. ;) No ! Not this can of worm ;) Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [parent][all] JaCoCo vs. Cobertura
So are we ready for a release 30? Gary On Sat, May 25, 2013 at 1:03 PM, Luc Maisonobe luc.maison...@free.frwrote: Hi all, Le 23/05/2013 20:55, Luc Maisonobe a écrit : Le 23/05/2013 20:52, Gary Gregory a écrit : I think all this is addressed by the parent POM in trunk. Please check it out for [math] and we can then talk about getting a version 30 out the door. Sure. I'll look at it probably tomorrow. I am quite tired this evening. I have checked commons parent 30-SNAPSHOT. It works great, thanks. Luc Luc Gary On Thu, May 23, 2013 at 2:38 PM, Luc Maisonobe luc.maison...@free.fr wrote: Le 23/05/2013 06:53, Phil Steitz a écrit : On 5/22/13 5:45 PM, sebb wrote: On 23 May 2013 01:15, Gary Gregory garydgreg...@gmail.com wrote: On Wed, May 22, 2013 at 7:43 PM, sebb seb...@gmail.com wrote: On 22 May 2013 17:52, Gary Gregory garydgreg...@gmail.com wrote: Hi All: [parent] version 29 replaces Cobertura with Jacoco, the main reasoning from the folks over at [math] being that Jacoco is very fast compared to Cobertura. In the case of [math] it's hours vs. minutes. It's not the only problem. The other two problems we encountered are: - there are bugs in cobertura that generates errors (typically when using floating numbers with hexadecimal encoding, which is very important for some specific constants representing specific numbers in IEEE encoding) - cobertura CANNOT be switched off when in parent pom. All normal means to to prevent it completely failed up to now. So we could not live with the current pom The problem is that Jacoco produces bogus results as I recently emailed about the [io] component. The large portion of the code is reported with 0% coverage which is completely wrong. This is apparently a known issue due to the Jacoco use of 'probes' to analyze code which is not compatible with the use of exceptions. If you get the latest from [io] and edit the POM to enable JaCoC, you can compare both reports in the generated site with 'mvn clean site'. Fast and bogus is not better than slow and right. I propose we switch [parent] back to Cobertura until a better alternative is proposed. [math] can decide if it can live with the fast and bad results provided by Jacoco. Strong -1 to bring cobertura back to parent unless it can *really* be switched off, which was not the case with parent 28 and earlier. If it can be switched off, then yes, this makes sense. Why not include both as options, so components can choose? Sure, why not, it would be nice to be able to run both for the same report set to see the differences. As a test I created profiles for JaCoCo and Cobertura. These work fine when activated via the command-line. I had hoped to use a property defined in the component POM to enable the default coverage provider, unfortunately the profiles are resolved before the properties are defined. However file-based activation does work OK - this would require projects to define a dummy file somewhere, for example: src/site/resources/coverage.jacoco or src/site/resources/coverage.cobertura A component can thereby define the appropriate default coverage tool. This can be overridden on the command line, for example: -P!jacoco -Pcobertura Why not just let projects add a coverage reporting plugin if they want it? I think that is how maven is designed to work :) This would be a good solution. In fact when I replaced cobertura with jacoco, my intend was much more to remove cobertura than impose jacoco. The previous discussion we had seemed to show that we did want a shared coverage tool, but cobertura was really a problem. Now we find that Jacoco also has some major drawbacks, so I guess the proper way is to forget the idea of a shared tool and let components choose their own way. So either we find a *real* way to prevent one from running and use the other, or we don't put anything at parent level and let components do this. Both solutions are equivalent to me until we find a third tool, a fourth tool ... in which case handling all possibilities in the parent pom becomes cumbersome and handling this at component level seems to remain manageable. best regards, Luc Phil Gary I'm currently experimenting with profiles to see if this can be done easily. Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail:
