[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build
Github user metlos commented on the issue: https://github.com/apache/tinkerpop/pull/494 So in another words it is a matter of setting up the level of breakage you want to allow between different Tinkerpop versions. I based the "minor increase allows breaking changes" on the "feeling" I got from how Tinkerpop changed over time, but you may want to modify it if you so choose. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop pull request #494: TINKERPOP-1443 - Introduce API check into the b...
Github user metlos closed the pull request at: https://github.com/apache/tinkerpop/pull/494 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build
Github user metlos commented on the issue: https://github.com/apache/tinkerpop/pull/494 Hmm, maven central seems to be taking its time - it still doesn't have the latest revapi-java version available (which is why CI failed for the latest commit). But anyway, I've updated the versions to the latest, so you can move on to the internal branch. Let's hope maven central gets synced soon. Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build
Github user metlos commented on the issue: https://github.com/apache/tinkerpop/pull/494 I'm near a new release of Revapi that contains some important fixes (like wrong classification of a return type change to a covariant type). So everything I wanted to do to this PR was to update it with the latest Revapi version before it's merged. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #518: Honor the equals() contract on Property impls by allow...
Github user metlos commented on the issue: https://github.com/apache/tinkerpop/pull/518 Created #519 with the updates as suggested here. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop pull request #519: Make ElementHelper.areEqual(Property, Object) h...
GitHub user metlos opened a pull request: https://github.com/apache/tinkerpop/pull/519 Make ElementHelper.areEqual(Property, Object) handle nulls⦠⦠so that it can be used correctly in equals() methods of Property impls. Added test methods for additional equality "scenarios" in ElementHelper. Note that it is not possible to add tests for equals on `Vertex`, `Edge`, `Property` and `VertexProperty` directly as they are interfaces, not concrete classes. Instead I've added additional test methods for `ElementHelper` to test various case of properties and elements. `ElementHelper.areEqual()` methods are suggested to be used for `equals` of implementations of those interfaces. You can merge this pull request into a Git repository by running: $ git pull https://github.com/metlos/tinkerpop null-equality-on-props Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/519.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #519 commit 366a0b473e09ccdb4e49803d1ab804f82faf32e2 Author: Lukas Krejci <lkre...@redhat.com> Date: 2016-12-21T22:02:03Z Make ElementHelper.areEqual(Property, Object) handle nulls so that it can be used correctly in equals() methods of Property impls. Added test methods for additional equality "scenarios" in ElementHelper. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #518: Honor the equals() contract on Property impls by allow...
Github user metlos commented on the issue: https://github.com/apache/tinkerpop/pull/518 Thanks for the feedback. I'm closing this PR then and will target the reworked patch to tp32. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop pull request #518: Honor the equals() contract on Property impls b...
Github user metlos closed the pull request at: https://github.com/apache/tinkerpop/pull/518 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop pull request #518: Honor the equals() contract on Property impls b...
GitHub user metlos opened a pull request: https://github.com/apache/tinkerpop/pull/518 Honor the equals() contract on Property impls by allowing nulls as valid comparisons. If user code put the properties into some kind of collection together with `null` values, things would blow up. Note that `ElementHelper.areEqual(Element, Object)` allows for `null` values, but `ElementHelper.areEqual(Property, Object)` does not. I assume the reason for this discrepancy is that properties are never supposed to be null but merely not present. While this assumption is valid in Tinkerpop impl, I think it cannot be imposed on the user code, which assumes a valid implementation of `equals()` which *should not* blow up on null arguments. You can merge this pull request into a Git repository by running: $ git pull https://github.com/metlos/tinkerpop null-equality-on-props Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/518.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #518 commit a0b604c10f3ffbf96fbe444bc5059e2c9d0030a3 Author: Lukas Krejci <lkre...@redhat.com> Date: 2016-12-21T10:34:34Z Honor the equals() contract on Property impls by allowing nulls as valid comparisons. If user code put the properties into some kind of collection together with null values, things would blow up. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build
Github user metlos commented on the issue: https://github.com/apache/tinkerpop/pull/494 @okram the API changes seem to be due to your changes in 05bfb029. You could try and fill out your first intentional API changes list ;-) (Most of the below is just git extravaganza - the important bits are points 5, 6 and 7) 1. `git fetch <>` 1. `git checkout -b metlos-api-check-tp32 <>/tp32` 1. `git pull https://github.com/metlos/tinkerpop api-check-tp32` 1. `mvn clean install -DskipTests` 1. copy and paste the JSON snippet output to the build console by revapi into `gremlin-core/api-changes.json`. 1. Follow the example in that file to ignore the found changes in `3.2.4` using the JSON snippet from the build. 1. Fill out the justifications for the changes in that snippet (making it a valid JSON). 1. `git push ssh://g...@github.com/metlos/tinkerpop.git HEAD:api-check-tp32` 1. Watch this PR go green. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build
Github user metlos commented on the issue: https://github.com/apache/tinkerpop/pull/494 > org.apache.tinkerpop.gremlin.structure > org.apache.tinkerpop.gremlin.structure.io > org.apache.tinkerpop.gremlin.process.computer > org.apache.tinkerpop.gremlin.process.traversal > org.apache.tinkerpop.gremlin.process.traversal.dsl.graph Is this the full list of packages or should the sub-packages of these be included, too? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build
Github user metlos commented on the issue: https://github.com/apache/tinkerpop/pull/494 `.travis.install-maven.sh` is a workaround I used in another project for https://github.com/travis-ci/travis-ci/issues/4872. Trusty, which is the distro used on Travis for Tinkerpop builds, provides Maven 3.1.1, which is too old for Revapi which needs at least 3.2.5. I will push another commit with the changes necessary to track the ignored (aka intentional) API changes. It will be similar to http://revapi.org/modules/revapi-maven-plugin/examples/multi-file-configuration.html. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build
Github user metlos commented on the issue: https://github.com/apache/tinkerpop/pull/494 Yes, Java makes it somewhat difficult to properly declare "module boundaries" - let's hope Java 9 will do that right. But for now, it is often useful to declare certain packages as internal and not consider any changes in them as "user-facing". As shown with `org.apache.tinkerpop.shaded`, it is quite easy to exclude packages from the API check with Revapi. If the internal and API classes are mixed within a single package, we could also annotate the internal classes with some dedicated annotation - let's say `org.apache.tinkerpop.Internal` and configure Revapi to ignore anything annotated with that annotation. Revapi can also be configured to just ignore certain classes but that's slightly more involved, because you'd need to modify the POM each time you add an internal class (as opposed to just annotating the class). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build
Github user metlos commented on the issue: https://github.com/apache/tinkerpop/pull/494 K, finally the CI fails for the right reasons :wink: https://travis-ci.org/apache/tinkerpop/builds/176007319#L3026 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop pull request #494: TINKERPOP-1443 - Introduce API check into the b...
GitHub user metlos opened a pull request: https://github.com/apache/tinkerpop/pull/494 TINKERPOP-1443 - Introduce API check into the build This introduces API checks into the build and fails the build whenever a "severe" change is introduced that would break either source or binary compatibility. Several modules are excluded from the API check (by setting the `revapi.skip` property to true) but because I don't know exactly what Tinkerpop considers its public API this list might shrink or grow... The API analysis itself is configured such that it only checks classes from `org.apache.tinkerpop` package and subpackages excluding `org.apache.tinkerpop.shaded`. More importantly, the analysis is configured to allow breaking changes on a new minor version - from the context I gathered that is roughly your policy. Also using a non-public class as part of the API always breaks the build even if other breaking changes are allowed. As it stands right now, the CI build will fail with this PR because there are API changes that the checker disallows. You can merge this pull request into a Git repository by running: $ git pull https://github.com/metlos/tinkerpop api-check-tp32 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/494.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #494 commit f35041fe52173f4ce73ad4385d1ad011306e3df1 Author: Lukas Krejci <lkre...@redhat.com> Date: 2016-11-14T22:55:23Z Introduce Revapi API checks into the build. The API checker is set up to only check classes in org.apache.tinkerpop package (and sub packages) and is set up to ignore breaking changes on a minor version increase. It always reports non-public classes that leak into the API though. commit 992800be33d28f55372cb219e90447dd4f33accb Author: Lukas Krejci <lkre...@redhat.com> Date: 2016-11-15T08:57:59Z Merge remote-tracking branch 'upstream/tp32' into api-check --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
