gh-pages provide an easy way to add a home page to a project. It would be nice to groovydoc master and publish it to gh-pages using travis-ci.

When a build turns optimizations off there should be a warning printed. This will make it easy to know when optimizations are turned off in travis-ci.

The groovy documentation talks about using @DelegateTo to make ide's and type checking possible within closures. This could be applied to the the api to make it easier to use.

• add @DelegateTo in traversal methods that take a closure.

In all of these methods the graph is the delegate and 'it' in each closure is the vertex. This allows other methods in the graph to be used during traversal. For instance a user can get the inEdges or outEdges for the vertex in a DirecedGraph. This can be useful for finding vertices with certain input or output while traversing the graph.

eachBfs methods

• Will include: eachBfs(Closure) and eachBfs(String,Closure)
• starts at first vertex or vertex where name matches given string
• run closure on each vertex in breadth first order
• in keeping with groovy's each there is no way of returning early. For that behavior use find methods instead.

findBfs methods

• Will include: findBfs(Closure) and findBfs(String,Closure)
• Starts at first vertex or vertex where name matches given string
• Should work like groovy's find and return the vertex if closure returns true otherwise returns null

findAllBfs methods

• Will include: findAllBfs(Closure) and findAllBfs(String,Closure)
• starts at first vertex or vertex where name matches given string
• returns list of all matching vertices

injectBfs methods

• Will include: injectBfs(Object,Closure) and injectBfs(String,Object,Closure)
• starts at first vertex or vertex where name matches given string
• Object is the first value passed into the first call to closure. The result of each call to closure are passed to the next call to closure.
• the result of the final call to closure is returned from the method

collectBfs methods

• Will include: collectBfs(Closure) and collectBfs(String,Closure)
• starts at first vertex or vertex where name matches given string
• calls inject with a list and a closure that calls the given closure adding the result to the list

traverseEdges

The above methods need a method that tells them which edges to follow during a traversal. In the past this was called adjacentEdges but that name doesn't fit well. This method needs to be modified when DirectedGraphPlugin is applied to only return outEdges. This method will be used in depth first search methods as well.

In all of these methods the graph is the delegate and 'it' in each closure is the vertex. This allows other methods in the graph to be used during traversal. For instance a user can get the inEdges or outEdges for the vertex in a DirecedGraph. This can be useful for finding vertices with certain input or output while traversing the graph.

Unlike breadth first search, depth first search has different orders: pre-order, in-order, post-order, and reverse post-order. This means there are 4 versions of each higher-order method (each, find, findAll, inject, collect).

The default methods for graph will use dfs preorder methods. This means each higher-order methd (find, findAll, inject, and collect) in graph will be aliases to the dfs preorder methods.

For every higher order method there will be the default which aliases to PreOrder and there will be methods for each ordering. For example each will have each, eachPreOrder, eachInOrder, eachPostOrder, and eachReversePostOrder. The pattern is each${order}(...).

each methods

• Will include: each${order}(Closure) and each${order}(String,Closure)
• starts at first vertex or vertex where name matches given string
• in keeping with groovy's each there is no way of returning early. For that behavior use find methods instead.

find methods

• Will include: find${order}(Closure) and find${order}(String,Closure)
• Starts at first vertex or vertex where name matches given string
• Should work like groovy's find and return the vertex if closure returns true otherwise returns null

findAll methods

• Will include: findAll${order}(Closure) and findAll${order}(String,Closure)
• starts at first vertex or vertex where name matches given string
• returns list of all matching vertices

inject methods

• Will include: inject${order}(Object,Closure) and inject${order}(String,Object,Closure)
• starts at first vertex or vertex where name matches given string
• Object is the first value passed into the first call to closure. The result of each call to closure are passed to the next call to closure.
• the result of the final call to closure is returned from the method

collect methods

• Will include: collect${order}(Closure) and collect${order}(String,Closure)
• starts at first vertex or vertex where name matches given string
• calls inject with a list and a closure that calls the given closure adding the result to the list

traverseEdges

The above methods need a method that tells them which edges to follow during a traversal. In the past this was called adjacentEdges but that name doesn't fit well. This method needs to be modified when DirectedGraphPlugin is applied to only return outEdges. This method will be used in breadth first search methods as well.

Write method that uses edge classification to detect cycles. This will be used to implement the directed a cyclic graph plugin.

Implement edge classification in depth first traversal.

There should be a closure added to DepthFirstTraversalSpec to allow developers to hook into the classification ation.

the com.github.amkay.gitflow gradle plugin has been applied and git now has the gitflow plugin. The only thing left is to make sure travis-ci only does sonar from the dev branch and for releases.

Add feature to load edges from a file.

The user guide should be published to gh-pages when a new version of graph-dsl is released.

Vertex has the property name. This should not be set directly outside of the package. Instead rename should be used within the dsl.

• make setName package private in Vertex.

Edge has the properties one and two. These should not be set directly outside of the package. Instead renameOne and renameTwo should be used in the dsl.

• make one and two package private in Edge.

edge methods

edge(String, String)
edge(VertexSpec, VertexSpec)
edge(Map)
edge(String, String, Map)
edge(VertexSpec, VertexSpec, Map)
edge(String, String, Closure)
edge(VertexSpec, VertexSpec, Closure)
edge(Map, Closure)
edge(String, String, Map, Closure)
edge(VertexSpec, VertexSpec, Map, Closure)
edge(EdgeSpec)

All methods create an EdgeSpec then call edge(EdgeSpec).
Methods that take VertexSpec will allow for code like this

edge(step1, step2)

Strings are not required because propertyMissing returns a VertexSpec with name set to the missing name.

EdgeSpecRunner

Runs the closure in a EdgeSpec.

add sonar plugin to gradle
execute sonar in travis-ci

sonarqube.com should only contain published results from master. Everything else should use pull requests for preview scans.

When working on a bugfix branch the version becomes detached instead of having the bugfix name. Looking at the code for gradle-gitflow it seems like bugfix is something gitflow-avh added that gradle-gitflow doesn't support. The code should be easy to change. It looks like it needs a new strategy class added for bugfix.

The sonarqube task is reporting

CodeNarc completed: (p1=0; p2=0; p3=0) 1992ms

but we know it is actually

CodeNarc completed: (p1=0; p2=13; p3=68) 3545ms

This needs to be solved so sonar can report the correct information.

Right now groovy optimizations are turned off so jacoco can get accurate results. This needs to change if we are going to publish to maven central. There should be a separate build path for when optimizations need to be turned on.

On:
publishing

Off:
local development
travis-ci build for anything other than master

Gradle can check which tasks are in the task graph. If publish is in the graph it should do optimizations. It is ok to turn them off for everything else right now.

Get artifacts published in nexus. Master should publish releases.

Develop may publish snapshots so each merged feature has a snapshot but since we are following semantic versioning and all versions are released, there may be no point.

Make sure groovydoc are published and can be accessed.

implement bfs and dfs in graph

This plugin should only allow edges to be added that do not cause cycles.

This may work in the same design as dft.

Sonar scans can run for pull requests and develop. They should not run for other branches because it cause a race condition where the last to publish wins.

Write algorithm to detect connected components.

Options: for given vertex, all connected components

setup with travis-ci

Plugins may be applied multiple times. There needs to be a way to check that a plugin is only applied once.

trait will allow a single trait to be applied without the need to pass a list to traits.

vertex 'A' trait: LinkedHashMap

The Mapping trait takes over all property calls in other traits. It needs to be rewritten to use missing property method or if there is a way to override get (). It should check for null values in the map and return super's property if it exists.

The user guide should be written in asciidoctor. Figure out how asciidoctor will work for this project and implement it. At the end of this task there should be some basic guidance for graph-dsl.

Basic Documentation to Add

1. Using graph-dsl with with grape
2. Add vertices and edges
3. show actual code and results from running actual code

Problems to solve

1. ensure the version of graph-dsl in scripts is updated from gradle
2. include code from documentation scripts
3. include results from running documentation scripts

Documentation policy

Some policies should be made on how to introduce new features in the guide. How to tag code for use in asciidoctor. When to display results from example code.

When something is first used include all the code. After it is introduced including all the code is not needed. For example, show the usage of the static graph {...} method once and then after that section of the documentation the developer should assume code is run from within a dsl entry point.

Explore the idea of having vertex and edge use a map as a trait. This can replace the Value trait. It will allow vertex and edge to have multiple values. The can also be treated like maps which may be nice.

This will need to be implemented as two separate plugins that can be applied to the graph. The plugin will add these traits to the existing vertex and edges and modify the newEdge/newVertex methods to apply the trait to any new vertices or edges added to the graph.

Cobertura provides code coverage metrics for codenarc reports. It may also provide per test coverage.

maven supports sending per test code coverage to sonar. Gradle doesn't seem to. It would be nice to add this to the build somehow.

It would be nice to generate local reports for per test code coverage. Jacoco supports custom reporting for an execution.

Create a minimal cli that can run a graph.

• look for graph.groovy by default
• Load script as DelegatingScript with a graph as delegatearly
• Add binding for graph variable as well
• run script

When a method is missing from graph it should create a VertexSpec. The name of the missing method should be the name in the spec.

step1 ()

When a property is missing it should be a VertexSpec withe the name set to the missing property name.

step1

vertex (VertexSpec, Closure) will allow the dsl to do something like this.

vertex step1 {
    ...
}

When the missing method is called with a map the dsl could look like this

vertex step1 (traits:Mapping, edgesOut:'step2') {
    ...
}

What about a call like this

step1 {
    ...
}

OR

step1 (traits:Mapping) {
    ...
}

VertexSpec could extend Closure and become a method that takes a Closure as a param. The call will apply the spec to the graph.

add jacoco to gradle
make sure coverage gets reported in sonar

Add methods to graph which can delete vertices and edges.

• vertices cannot be deleted if referenced by an edge (there are adjacent edges)

Implement Topological sort

fix inferred versions for previous versions and in develop.

vertex and edge methods should only create new objects if they do not already exist.

This applies to directed graphs

Options: for given vertex, all scc

Since vertex now reuses previously created vertices it would be nice if edge created vertices when called. This way a complete graph can be created with calls to the edge method. There will be no need to create vertices separately. This is what creating a graph would look like.

graph {
    edge 'a', 'b'
    edge 'a', 'c'
    edge 'c', 'b'
}

It would also be nice to create edges from vertex methods. An attribute could be used in the map like connects to.

graph {
    vertex ('a', connectsTo:'b')
    vertex ('c', connectsTo:['a', 'b'])
}

The behavior of connectsTo creates an edge where edge.one is this vertex and edge.two is the named vertex. connectsIn will do the opposite. edge.one will be the named vertex and edge.two will be this vertex.

Also consider renaming this so it is less confusing. Something like 'inEdges' and 'outEdges' may be more appropriate. Or it could be just 'in' and 'out' to keep it simple.

Creating a vertex is still a pain. It is hard to understand what should go into the config closure and how it relates to what happens outside of the config closure. The vertex closure needs to be streamlined so config traits can be setup and the graph can be setup while the closure is running.

VertexSpec

The config closure will be renamed to runnerCode. It will contain the closure passed to vertex methods.

vertex methods

All methods will create a VertexSpec and pass it to the vertex(VertexSpec) method

vertex(String)
vertex(String, Map)
vertex(String, Map, Closure)
vertex(String, Closure)
vertex(VertexSpec)

VertexSpecRunner in vertex(VertexSpec)

A new object that will run VertexSpec.runnerCode. It will perform all statements in the closure on the graph, and vertex. It will control new methods that are available to the closure.

This is an example of what should be able to happen in the closure.

vertex step1 {
    traits Mapping
    key = 'value'
    traits Weight
    weight 20
}

vertex step2(traits:Mapping) {
    key = 'value'
    traits Weight
    weight 30
    edgesFirst 'step1'
    println adjacentEdges(name)
}

This allows traits to be applied and code to execute against the trait once it is added.

Add the plugin so results show in gradle.

directed graph should have edges with the DirectedEdge trait

DirectedGraph trait should add algorithms for a directed graph

vertices should be a set where name is unique

graph algorithms do not use a map so we shouldn't here for now

• Undetected graph should only have preorder
• directed graph should have traversal, edge classification, preorder, inorder, postorder, and reversePostorder.

The plugin should have graph methods with groovydoc. Methods added to the graph through metaClass should call the plugin methods.

• traverseEdges needs to return edges sorted by weight.

Should be something like.

graph {

}

In a script to create a graph.

This is based on the idea of FileVisitor in java 7. It allows these results to be returned.

CONTINUE
SKIP_SIBBLINGS
SKIP_SUBTREE
TERMINATE

Following this concept in graph traversal could be interesting. So far graph-dsl has STOP and continue is represented by not returning STOP in a traversal closure (preorder, inorder, postorder). Adding CONTINUE could help enforce the return types from these closures and eliminate any confusion for what a closure can return (only a traversal options). Having SKIP could be helpful but there would need to be a use case for it.