I’m not sure how critical or trivial these are, but I’d like to share some
issues:
1. StrongLabelDeleteTest.deleteAll fails randomly
First of all I have one test case that is failing, with the following log.
[info] StrongLabelDeleteTest:
[info] - Strong consistency select (274 milliseconds)
[info] - Strong consistency deleteAll (83 milliseconds)
[info] - update delete (10 seconds, 377 milliseconds)
[info] - update delete 2 (7 seconds, 611 milliseconds)
[info] - large degrees (83 milliseconds)
[info] - deleteAll *** FAILED *** (94 milliseconds)
[info] false was not true (StrongLabelDeleteTest.scala:211)
[info] org.scalatest.exceptions.TestFailedException:
[info] at
org.scalatest.MatchersHelper$.newTestFailedException(MatchersHelper.scala:160)
[info] at
org.scalatest.Matchers$ShouldMethodHelper$.shouldMatcher(Matchers.scala:6231)
[info] at org.scalatest.Matchers$AnyShouldWrapper.should(Matchers.scala:6265)
[info] at
org.apache.s2graph.core.Integrate.StrongLabelDeleteTest$$anonfun$9.apply$mcV$sp(StrongLabelDeleteTest.scala:211)
[info] at
org.apache.s2graph.core.Integrate.StrongLabelDeleteTest$$anonfun$9.apply(StrongLabelDeleteTest.scala:181)
[info] at
org.apache.s2graph.core.Integrate.StrongLabelDeleteTest$$anonfun$9.apply(StrongLabelDeleteTest.scala:181)
[info] at
org.scalatest.Transformer$$anonfun$apply$1.apply$mcV$sp(Transformer.scala:22)
This is not entirely deterministic, as it sometimes succeeds, but most of the
time it fails with the stacktrace above.
If the test is dependent on some preconditions I think it’d be good to include
the initialization code that makes the precondition true.
The documentation lacks the comment that HBase must be running during the test;
maybe better to launch/stop HBase before/after the test?
2. asynchbase dependency in the POM
After running “sbt publishM2”, the resulting POM has the following entry as a
dependency,
<dependency>
<groupId>org.hbase</groupId>
<artifactId>asynchbase</artifactId>
<version>1.7.2-S2GRAPH</version>
</dependency>
but the resolution of any Maven project dependent on s2core fails because the
POM doesn’t contain https://github.com/SteamShon/asynchbase/raw/mvn-repo as an
additional Maven repository.
This can be fixed by manually adding the url as an additional Maven resolver in
the SBT settings, but generally it is not a good idea to use the Maven central
only rather than adding a custom repo.
This might not be a problem if we primarily focus on the S2Graph server
application in this release, but if we are uploading the S2Graph artifacts to
the Maven Central, e.g. to support the custom batch job development, this needs
to be fixed.
3. SBT root project depends on others but only aggregates s2core and s2rest_play
Currently the root SBT project only aggregates s2core and s2rest_play, and thus
any sbt command in the root directory, like compile, test, and publish, will be
only applied to those two.
4. Travis CI fails to resolve SBT dependencies
This is most likely a Travis CI issue; it fails while resolving some SBT
plugins: https://travis-ci.org/jongwook/incubator-s2graph/builds
<https://travis-ci.org/jongwook/incubator-s2graph/builds>
Jong Wook
> On Sep 26, 2016, at 9:27 AM, DO YUNG YOON <sho...@gmail.com> wrote:
>
> Hi all.
>
> So far, we got 1(+1 binding) and 3(+1 non-binding).
> Thanks for taking time to try out RC4.
> But I think we need more +1.
>
> Please take time to try out our RC4 then give any feedback and vote.
> I will wait more days before closing out this vote thread until either
> objection or sufficient votes.
>
>
>
>
> On Fri, Sep 23, 2016 at 3:00 PM Sergio Fernández <wik...@apache.org> wrote:
>
>> On Fri, Sep 23, 2016 at 12:51 AM, Jong Wook Kim <jongw...@nyu.edu> wrote:
>>
>>> I wrote that section in the README.md in mind that the majority will
>>> download the binary distribution which will contain the content in the
>>> subdirectory,
>>>
>>> The section “Building from the source” specifies that the distribution
>>> will be created in target/apache-s2graph-$version-incubating-bin.
>>>
>>> So I don’t think this is a blocker, but I agree that README.md can be
>> even
>>> more specific and it would be nice if start-s2graph.sh prints a helpful
>>> message if it is launched in the source root.
>>>
>>
>> No no, the mistake was completely on my side, I just wanted to provide
>> feedback from outside of the project development. Of course this is not
>> blocking the release, it's just a comment.
>>
>>
>>
>>
>>
>>>> On Sep 22, 2016, at 6:02 AM, Sergio Fernández <wik...@apache.org>
>> wrote:
>>>>
>>>> On Thu, Sep 22, 2016 at 11:56 AM, Kim, Min-Seok <mskim....@gmail.com>
>>> wrote:
>>>>>
>>>>> To Sergio,
>>>>>
>>>>> The commands will work on
>>>>>
>> `/path/to/incubator-s2graph/target/apache-s2graph-0.1.0-incubating-bin`
>>>>> after `sbt package`.
>>>>>
>>>>
>>>> Of course!
>>>>
>>>> Then the README needs to remark that to avoid people to get confused,
>>> like
>>>> it happened to me.
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Sergio Fernández
>>>> Partner Technology Manager
>>>> Redlink GmbH
>>>> m: +43 6602747925
>>>> e: sergio.fernan...@redlink.co
>>>> w: http://redlink.co
>>>
>>>
>>
>>
>> --
>> Sergio Fernández
>> Partner Technology Manager
>> Redlink GmbH
>> m: +43 6602747925
>> e: sergio.fernan...@redlink.co
>> w: http://redlink.co
>>
