TinkerPop3

Documentation

• homepage

• user documentation

• core javadoc

• full javadoc

Building and Testing

TinkerPop requires Java 1.8.0_40+ for proper building and proper operations.

• Build Project: mvn clean install

  • Specify specific tests in a TinkerPop Suite to run with the GREMLIN_TESTS environment variable, along with the Maven project list argument, e.g.:

    export GREMLIN_TESTS='org.apache.tinkerpop.gremlin.process.traversal.step.map.PathTest$Traversals,org.apache.tinkerpop.gremlin.process.traversal.step.util.PathTest'
    mvn -Dmaven.javadoc.skip=true --projects tinkergraph-gremlin test

  • Clean the .groovy/grapes/org.apache.tinkerpop directory on build: mvn clean install -DcleanGrapes

• Regenerate test data (only necessary given changes to IO classes): mvn clean install -Dio from tinkergraph-gremlin directory

  • If there are changes to the Gryo format, it may be necessary to generate the Grateful Dead dataset from GraphSON (see IoDataGenerationTest.shouldWriteGratefulDead)

• Check license headers are present: mvn apache-rat:check

• Build AsciiDocs: docs/preprocessor/preprocess.sh && mvn process-resources -Dasciidoc

• Build JavaDocs: mvn process-resources -Djavadoc

• Check for Apache License headers: mvn apache-rat:check

• Deploy JavaDocs/AsciiDocs: bin/publish-docs.sh svn-username

• Integration Tests: mvn verify -DskipIntegrationTests=false

• Performance Tests: mvn verify -DskipPerformanceTests=false

IDE Setup

This section refers specifically to setup within Intellij. TinkerPop has a module called gremlin-shaded which contains shaded dependencies for some libraries that are widely used and tend to introduce conflicts. To ensure that Intellij properly interprets this module after importing the Maven pom.xml perform the following steps:

1. Build gremlin-shaded from the command line with mvn clean install.

2. Right-click on the gremlin-shaded module in the project viewer of Intellij and select "Remove module".

3. In the "Maven Projects" Tool window and click the tool button for "Reimport All Maven projects" (go to View | Tool Windows | Maven Projects on the main menu if this panel is not activated).

4. At this point it should be possible to compile and run the tests within Intellij, but in the worst case, use File | Invalidate Caches/Restart to ensure that indices properly rebuild.

Note that it maybe be necessary to re-execute these steps if the gremlin-shaded pom.xml is ever updated.

Get Started

$ bin/gremlin.sh

         \,,,/
         (o o)
-----oOOo-(3)-oOOo-----
gremlin>

Release Process

1. mvn clean install

   1. mvn verify -DskipIntegrationTests=false

   2. mvn verify -DskipPerformanceTests=false

2. Update CHANGELOG.asciidoc with release date

3. bin/bump.sh "version" to update project files to reference the non-SNAPSHOT version

4. git diff and review the updated files (expect all pom.xml files and this README)

5. git commit -a -m "TinkerPop x.y.z release" and git push

6. git tag -a -m "TinkerPop x.y.z release" x.y.z and git push --tags

7. bin/publish-docs.sh <username>

8. Upload artifacts to https://dist.apache.org/repos/dist/dev/incubator/tinkerpop

9. Submit for [VOTE] at [email protected]

10. mvn deploy -Papache-release -DcreateChecksum=true -Dmaven.test.skip=true- deploy signed artifacts with checksums to Apache Nexus

11. Review and close the staging repository

12. Upload artifacts to https://dist.apache.org/repos/dist/release/incubator/tinkerpop (rename to -bin and -src)

13. Update homepage with references to latest distribution.

14. Announce release on dev@/gremlin-users@ mailing lists and tweet from @apachetinkerpop.

Issue Tracker Conventions

TinkerPop3 uses Apache JIRA as its issue tracker. JIRA is a very robust piece of software with many options and configurations. To simplify usage and ensure consistency across issues, the following conventions should be adhered to:

• An issue’s "status" should be in one of two states: open or closed.

  • An open issue is newly created, under consideration or otherwise in progress.

  • A closed issue is completed for purposes of release (i.e. code, testing, and documentation complete).

• An issue’s "type" should be one of two options: bug or improvement. A bug has a very specific meaning, referring to an error that prevents usage of TinkerPop AND does not have a reasonable workaround. Given that definition, a bug should generally have very high priority for a fix. Everything else is an improvement in the sense that any other work is an enhancement to the current codebase.

• The "component" should be representative of the primary area of code that it applies to and all issues should have this property set.

• The "priority" of an issue is represented by two states critical and major. It should be assigned as follows:

  • If the issue is a bug then the "priority" should be critical.

  • If the issue is an improvement then the "priority should be major.

• Issues are not assigned "labels".

• Until there is an official release "affected version" should be left empty.