Date   

0.1.0-SNAPSHOT deployed

Ted Wilmes <twi...@...>
 

Hello,
We're still working some of the kinks out, but the first JanusGraph 0.1.0-SNAPSHOT has 
been deployed. This includes a snapshot build of the zip distribution.  You can check 

Thanks,
Ted



Re: 0.1.0-SNAPSHOT deployed

Jason Plurad <plu...@...>
 

Thanks Ted!


I've created an uber simple Java example at: https://github.com/pluradj/janusgraph-java-example

On Sun, Mar 19, 2017 at 10:48 AM, Ted Wilmes <twi...@...> wrote:
Hello,
We're still working some of the kinks out, but the first JanusGraph 0.1.0-SNAPSHOT has 
been deployed. This includes a snapshot build of the zip distribution.  You can check 

Thanks,
Ted


--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Moving toward an initial release

sjudeng <sju...@...>
 

Now that the initial snapshot deployment is behind us what are the next steps towards an initial release? PR#80 and #159 have been merged so it seems to me that the tip of master right now might be a good starting point for a release. We could work on release steps directly on master or create a release branch. Below is one possible approach. Or is there another process already defined or other alternatives?

* Create a release branch, 0.1-SNAPSHOT based on current tip of master (8914cae)
* On master branch: Bump versions from 0.1.0-SNAPSHOT to 0.2.0-SNAPSHOT
* On 0.1-SNAPSHOT branch
  - Run full test suite including TP tests
  - Update documentation as described in RELEASING.md
  - Validate release (what are the steps here? running janusgraph.sh?)
  - Tag version 0.1.0 as 0.1.0-RC1
  - Call vote on 0.1.0 release
  - (Optional) Repeat previous steps (0.1.0-RC2, etc.) as necessary until vote passes
  - Push artifacts to Nexus
  - Upload release distribution zipfile (where?)
* Merge 0.1-SNAPSHOT into master

One question is where release distribution zipfile will be hosted, assuming this should be provided somewhere aside from (or in addition to) Nexus. Titan used S3 I think and janusgraph-dist/src/release/release.sh looks like it might still be assuming this? Another option would be GitHub releases, which would provide them on https://github.com/JanusGraph/janusgraph/releases (see this page for an example).


Re: [DISCUSS] Moving toward an initial release

"P. Taylor Goetz" <ptg...@...>
 

I would say, like Apache projects, the release should consist of the following:

* Source tar.gz/zip, with associated GPG signature of the release manager.
* Convenience binary tar.gz/zip + GPG sig.
* Maven artifacts published to mirrors.

The typical process works like this:

1. DISCUSS thread to form consensus on what to include.
2. Create a branch to release from, merge patches for the release.
3. Create build the release with `mvn release:prepare && mvn release:perform`. This will generate the tar.gz/zip files and stage the maven artifacts in Nexus.
4. Release Manager closes the Nexus repository, making the jar files available for review.
5. RM uploads tar.gz/zip files to staging area for review
5. RM calls a VOTE on janusgraph-dev@ for the release with links to: The tag/SHA for the release, CHANGELOG, tar.gz/zip files, Nexus staging repository.

If the VOTE is successful, release the Maven artifacts from Nexus, and move the staged tar.gz/zip files to the public download location. Then announce the release on user@ and dev@ mailing lists.

The Apache parent pom [1] can help automating this, though we may need to change it for whatever infrastructure we use. I don’t have an answer on where to various download sites should be, aside from Nexus. Misha?

When I looked at the TitanDB/JanusGraph build system, it seemed pretty convoluted and IMHO is ripe for refactoring and simplification. I’d be happy to help with this, but my availability is going to limited for the next two weeks.

-Taylor

On Mar 23, 2017, at 9:53 AM, sjudeng <sju...@...> wrote:

Now that the initial snapshot deployment is behind us what are the next steps towards an initial release? PR#80 and #159 have been merged so it seems to me that the tip of master right now might be a good starting point for a release. We could work on release steps directly on master or create a release branch. Below is one possible approach. Or is there another process already defined or other alternatives?

* Create a release branch, 0.1-SNAPSHOT based on current tip of master (8914cae)
* On master branch: Bump versions from 0.1.0-SNAPSHOT to 0.2.0-SNAPSHOT
* On 0.1-SNAPSHOT branch
  - Run full test suite including TP tests
  - Update documentation as described in RELEASING.md
  - Validate release (what are the steps here? running janusgraph.sh?)
  - Tag version 0.1.0 as 0.1.0-RC1
  - Call vote on 0.1.0 release
  - (Optional) Repeat previous steps (0.1.0-RC2, etc.) as necessary until vote passes
  - Push artifacts to Nexus
  - Upload release distribution zipfile (where?)
* Merge 0.1-SNAPSHOT into master

One question is where release distribution zipfile will be hosted, assuming this should be provided somewhere aside from (or in addition to) Nexus. Titan used S3 I think and janusgraph-dist/src/release/release.sh looks like it might still be assuming this? Another option would be GitHub releases, which would provide them on https://github.com/JanusGraph/janusgraph/releases (see this page for an example).

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Moving toward an initial release

sjudeng <sju...@...>
 

The process you describe sounds good to me. I would call out tests specifically in there somewhere. For a JanusGraph release I think this should include running the full TinkerPop test suite before the candidate release is generated. Also some of the configuration/process could be manual for the initial release and then simplified/automated for the second release.

I'm really interested in getting master freed up for post-initial release development. But this could happen in parallel to release preparation once we create the release branch. Given there has been some discussion here on features to include (#80, #159, #132), can we start with master as it is now and then start the discuss thread in parallel? In the discussion I hope we can keep focus that this is an initial compatibility release only. Then hopefully we can agree that any new features, even those with complete PRs, can wait for the second release. There's nothing saying that the second release can't happen a month after the first.

If this is acceptable I'd like to get started at least with testing (which takes 2-3 days) as soon as possible. Once the tests are confirmed good hopefully others can help out with the documentation (changelog, etc.) updates and definitely to serve as the RM to actually tag and push out the release artifacts. Again in my opinion we could do some of the configuration/process steps manually the first time and then simplify/automate them later maybe as part of the second release. Is this approach too aggressive?


Re: 0.1.0-SNAPSHOT deployed

Ryan Spangler <ryan.s...@...>
 

Hi Jason,

Thanks for posting an example! I have been having a rough time finding some example code.

That said, the build fails (on mac using java 8 update 110 and maven 3.3.9):










[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.064 s
[INFO] Finished at: 2017-03-24T10:37:53-07:00
[INFO] Final Memory: 8M/245M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project java-example: Could not resolve dependencies for project pluradj.janusgraph.example:java-example:jar:0.1: The following artifacts could not be resolved: org.janusgraph:janusgraph-core:jar:0.1.0-SNAPSHOT, org.janusgraph:janusgraph-berkeleyje:jar:0.1.0-SNAPSHOT, org.janusgraph:janusgraph-lucene:jar:0.1.0-SNAPSHOT: Could not find artifact org.janusgraph:janusgraph-core:jar:0.1.0-SNAPSHOT -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException


Any ideas?


I am looking for example code because I am getting an import error when trying to import janusgraph into my own project saying "object janusgraph is not a member of package org"

On Sunday, March 19, 2017 at 8:33:06 AM UTC-7, Jason Plurad wrote:
Thanks Ted!


I've created an uber simple Java example at: https://github.com/pluradj/janusgraph-java-example

On Sun, Mar 19, 2017 at 10:48 AM, Ted Wilmes <t...@...> wrote:
Hello,
We're still working some of the kinks out, but the first JanusGraph 0.1.0-SNAPSHOT has 
been deployed. This includes a snapshot build of the zip distribution.  You can check 

Thanks,
Ted


--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: 0.1.0-SNAPSHOT deployed

Jason Plurad <plu...@...>
 

Thanks for the feedback. I've pushed a fix. Please give it another go.


On Friday, March 24, 2017 at 3:28:36 PM UTC-4, Ryan Spangler wrote:
Hi Jason,

Thanks for posting an example! I have been having a rough time finding some example code.

That said, the build fails (on mac using java 8 update 110 and maven 3.3.9):










[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.064 s
[INFO] Finished at: 2017-03-24T10:37:53-07:00
[INFO] Final Memory: 8M/245M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project java-example: Could not resolve dependencies for project pluradj.janusgraph.example:java-example:jar:0.1: The following artifacts could not be resolved: org.janusgraph:janusgraph-core:jar:0.1.0-SNAPSHOT, org.janusgraph:janusgraph-berkeleyje:jar:0.1.0-SNAPSHOT, org.janusgraph:janusgraph-lucene:jar:0.1.0-SNAPSHOT: Could not find artifact org.janusgraph:janusgraph-core:jar:0.1.0-SNAPSHOT -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException


Any ideas?


I am looking for example code because I am getting an import error when trying to import janusgraph into my own project saying "object janusgraph is not a member of package org"

On Sunday, March 19, 2017 at 8:33:06 AM UTC-7, Jason Plurad wrote:
Thanks Ted!


I've created an uber simple Java example at: https://github.com/pluradj/janusgraph-java-example

On Sun, Mar 19, 2017 at 10:48 AM, Ted Wilmes <t...@...> wrote:
Hello,
We're still working some of the kinks out, but the first JanusGraph 0.1.0-SNAPSHOT has 
been deployed. This includes a snapshot build of the zip distribution.  You can check 

Thanks,
Ted


--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


New Committer: sjudeng

Jason Plurad <plu...@...>
 

The Technical Steering Committee (TSC) for JanusGraph is pleased to welcome sjudeng as a committer on the project (effective March 19). sjudeng has provided major contributions to the project in these initial weeks, including assisting Dylan with the Apache TinkerPop 3.2.x upgrade, offering code and guidance on the Elasticsearch 2.x/5.x upgrade, and continuing to push forward the release process.

Being a committer enables easier contribution to the project since there is no need to work via the patch submission process. This should enable better productivity.


Re: [DISCUSS] Elasticsearch Http using Jest

sjudeng <sju...@...>
 

Keith, I looked over the latest commit on your Jest update branch. Do you think the update to support running tests through ESIntegTestCase will be worth the additional complexity of needing to separate out into multiple ES test modules? Personally my preference in this case would be to stay with the approach of testing through a full instance via the ES distribution artifact available since 2.x and added in #79. I think there's value in running tests against an actual (fully unmocked) ES instance, the implementation is cleaner, and it supports testing against any 2.x and 5.x distribution. We already have approval to drop support for 1.x (after the 0.1.0 release).

Also since I think we have consensus on the path forward to update ES (merging #79 and then migrating to Jest), would you consider retargeting your Jest update commits onto the branch in #79? My hope is we'll be able to get #79 merged after the 0.1.0 release is out/started. I think your updates to use Jest will improve that implementation by removing all the custom REST request/response objects I added. Even better it'll also remove the ES dependency (right?), which will free us up for the Lucene upgrade.

Thanks for your work on this and for making it visible via your WIP PR. However we proceed I think communicating early and often is helpful here.


Re: New Committer: sjudeng

Jerry He <jerr...@...>
 

Congrats, and welcome, sjudeng!


On Friday, March 24, 2017 at 2:36:21 PM UTC-7, Jason Plurad wrote:
The Technical Steering Committee (TSC) for JanusGraph is pleased to welcome sjudeng as a committer on the project (effective March 19). sjudeng has provided major contributions to the project in these initial weeks, including assisting Dylan with the Apache TinkerPop 3.2.x upgrade, offering code and guidance on the Elasticsearch 2.x/5.x upgrade, and continuing to push forward the release process.

Being a committer enables easier contribution to the project since there is no need to work via the patch submission process. This should enable better productivity.


Re: [DISCUSS] Moving toward an initial release

Samik Raychaudhuri <sam...@...>
 

On hosting the zip file, I think we should just use the github hosting. It's easy and comes bundled with github, so why not use it?
Thanks.
-Samik

On 23-Mar-17 5:03 PM, sjudeng wrote:
The process you describe sounds good to me. I would call out tests specifically in there somewhere. For a JanusGraph release I think this should include running the full TinkerPop test suite before the candidate release is generated. Also some of the configuration/process could be manual for the initial release and then simplified/automated for the second release.

I'm really interested in getting master freed up for post-initial release development. But this could happen in parallel to release preparation once we create the release branch. Given there has been some discussion here on features to include (#80, #159, #132), can we start with master as it is now and then start the discuss thread in parallel? In the discussion I hope we can keep focus that this is an initial compatibility release only. Then hopefully we can agree that any new features, even those with complete PRs, can wait for the second release. There's nothing saying that the second release can't happen a month after the first.

If this is acceptable I'd like to get started at least with testing (which takes 2-3 days) as soon as possible. Once the tests are confirmed good hopefully others can help out with the documentation (changelog, etc.) updates and definitely to serve as the RM to actually tag and push out the release artifacts. Again in my opinion we could do some of the configuration/process steps manually the first time and then simplify/automate them later maybe as part of the second release. Is this approach too aggressive?
--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Moving toward an initial release

Ted Wilmes <twi...@...>
 

That's a helpful summation of the Apache release process Taylor, thanks for that.  I say yes, we should get the process started.  I'll kick things off with a DISCUSS thread and create a 0.1.0 release branch that we can work out of.

Thanks,
Ted


On Saturday, March 25, 2017 at 2:01:30 AM UTC-5, Samik R wrote:
On hosting the zip file, I think we should just use the github hosting. It's easy and comes bundled with github, so why not use it?
Thanks.
-Samik

On 23-Mar-17 5:03 PM, sjudeng wrote:
The process you describe sounds good to me. I would call out tests specifically in there somewhere. For a JanusGraph release I think this should include running the full TinkerPop test suite before the candidate release is generated. Also some of the configuration/process could be manual for the initial release and then simplified/automated for the second release.

I'm really interested in getting master freed up for post-initial release development. But this could happen in parallel to release preparation once we create the release branch. Given there has been some discussion here on features to include (#80, #159, #132), can we start with master as it is now and then start the discuss thread in parallel? In the discussion I hope we can keep focus that this is an initial compatibility release only. Then hopefully we can agree that any new features, even those with complete PRs, can wait for the second release. There's nothing saying that the second release can't happen a month after the first.

If this is acceptable I'd like to get started at least with testing (which takes 2-3 days) as soon as possible. Once the tests are confirmed good hopefully others can help out with the documentation (changelog, etc.) updates and definitely to serve as the RM to actually tag and push out the release artifacts. Again in my opinion we could do some of the configuration/process steps manually the first time and then simplify/automate them later maybe as part of the second release. Is this approach too aggressive?
--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Moving toward an initial release

sjudeng <sju...@...>
 

Thanks for creating the branch. I'm starting working through TP tests now. You might consider changing the branch name to 0.1-SNAPSHOT or jg01 or something since presumably it would service all potential 0.1.x releases and also to avoid confusion with the eventual 0.1.0 tag.


[DISCUSS] 0.1.0 Release Prep

Ted Wilmes <twi...@...>
 

Hello,
I have created a release branch (jg01) we can use for 0.1.0 prep.  I think at this point we're ready to discuss what will go into 0.1.0.  Open issues
tagged for the 0.1.0 milestone can be seen at https://github.com/JanusGraph/janusgraph/milestone/1.

Should the TinkerPop upgrade issue #41 be closed out at this point Sjudeng since you guys completed the 3.2.3 upgrade?  I think 
#73 Titan Compatibility can probably be closed as the related PR has been merged.  That leaves 6 more outstanding issues.  Which of these
would you all like to see included for sure versus what could be pushed?  Are there any additional issues that are not tagged for 0.1.0 that
should be?  I could see #171 being one possibility.

Thanks,
Ted



Re: [DISCUSS] 0.1.0 Release Prep

sjudeng <sju...@...>
 

Thanks for getting the ball rolling on this. Below are my recommendations based on 0.1.0 being scoped as an initial compatibility release to enable the easiest possible Titan->JanusGraph transition. In this case no new features are really required.

#41 TinkerPop 3.2 upgrade (status: closed)
- I closed this issue assuming it's reasonable to tie it to the upgrade to 3.2.3 and opened a new issue for the update to 3.2.4, which in my opinion isn't a blocker for the 0.1.0 release. It is worth noting though that JanusGraph TinkerPop tests do require a TinkerPop commit that is not in 3.2.3. I recommend making a temporary note of the workaround steps for this in documentation (e.g. BUILDING.md), which could be removed after updating to 3.2.4.

#74 Automated testing in Travis (remove from 0.1.0 milestone)
- I think it's important that all tests (including TinkerPop tests) are run on the release candidate, but I don't think it's necessary for this to be fully automated through Travis.

#120 Improve documentation of ids.num-partitions
- I can go either way on this one.

#128 Dependency license check in Travis (remove from 0.1.0 milestone)
- Like testing this check could be manual for 0.1.0.

#132 Non-permissive licenses in dependencies (remove from 0.1.0 milestone)
- From a user perspective these dependencies have been there since Titan and have not been added by JanusGraph. The only issue would be if there are additional restrictions on JanusGraph as a Linux Foundation project.

#133 Mark JTS optional in janusgraph-solr (remove from 0.1.0 milestone)
- Same as #132 above.

#147 Support custom ids (remove from 0.1.0 milestone)
- I don't think we're close on this and it's definitely a new feature (or a long outstanding bug?)

#171 Test failures in janusgraph-berkeleyje (add to 0.1.0 milestone)
- I think all tests need to pass for a release.


Re: [DISCUSS] 0.1.0 Release Prep

Ted Wilmes <twi...@...>
 

Nice summary and I'm in agreement with the ones you've marked to remove from the milestone.
In addition, I think #120 could be pushed.  These are all important, but I do not think critical, for the 
first release.  I'm also in agreement that #171 should be added.  I saw your note on that and I'll take
a look at it too.

--Ted


On Sunday, March 26, 2017 at 12:31:51 PM UTC-5, sjudeng wrote:
Thanks for getting the ball rolling on this. Below are my recommendations based on 0.1.0 being scoped as an initial compatibility release to enable the easiest possible Titan->JanusGraph transition. In this case no new features are really required.

#41 TinkerPop 3.2 upgrade (status: closed)
- I closed this issue assuming it's reasonable to tie it to the upgrade to 3.2.3 and opened a new issue for the update to 3.2.4, which in my opinion isn't a blocker for the 0.1.0 release. It is worth noting though that JanusGraph TinkerPop tests do require a TinkerPop commit that is not in 3.2.3. I recommend making a temporary note of the workaround steps for this in documentation (e.g. BUILDING.md), which could be removed after updating to 3.2.4.

#74 Automated testing in Travis (remove from 0.1.0 milestone)
- I think it's important that all tests (including TinkerPop tests) are run on the release candidate, but I don't think it's necessary for this to be fully automated through Travis.

#120 Improve documentation of ids.num-partitions
- I can go either way on this one.

#128 Dependency license check in Travis (remove from 0.1.0 milestone)
- Like testing this check could be manual for 0.1.0.

#132 Non-permissive licenses in dependencies (remove from 0.1.0 milestone)
- From a user perspective these dependencies have been there since Titan and have not been added by JanusGraph. The only issue would be if there are additional restrictions on JanusGraph as a Linux Foundation project.

#133 Mark JTS optional in janusgraph-solr (remove from 0.1.0 milestone)
- Same as #132 above.

#147 Support custom ids (remove from 0.1.0 milestone)
- I don't think we're close on this and it's definitely a new feature (or a long outstanding bug?)

#171 Test failures in janusgraph-berkeleyje (add to 0.1.0 milestone)
- I think all tests need to pass for a release.


[DISCUSS] Splitting janusgraph-cassandra

Samant Maharaj <samant...@...>
 

Hi,

As part of implementing the janusgraph-cql backend, we initially looked into adding the new CQL backend into the existing janusgraph-cassandra project.

We ultimately ended up not taking this approach because it would mean that any code depending on the CQL backend would still end up pulling cassandra-all, astyanax and all their dependencies which is quite undesirable.

We'd like to know what everyone thinks of the idea of splitting janusgraph-cassandra into core and implementation specific modules. If we implemented this, CQL could be moved in as another backend without any unrelated dependencies.

I've implemented this change in a branch in our repository here: https://github.com/orionhealth/janusgraph/tree/feature/cassandra-refactor

Some notes:
  • This covers all the existing backends but not the port of the CQL backend to the new structure.
  • We've simplified the testing setup code around bootstrapping Cassandra which enables running the tests easily from your IDE. It also removes the current dependency on inter-project structure where the other projects need to know how to use the resources in janusgraph-cassandra to bootstrap Cassandra.
  • We've introduced a cassandra-test project that is included in test scope similar to janusgraph-test that contains the shared testing code.
Samant Maharaj & Paul Kendall


Re: [DISCUSS] Elasticsearch Http using Jest

Keith Lohnes <loh...@...>
 

sjudeng, thanks for looking things over. I've moved away from using the ESIntegTestCase. I couldn't get it to work. The reason for separating out the was 1.x support, so I'll likely undo that change.

I also think retargeting the changes on to 79 is a good idea as well. I've been keeping an eye on the Jest repo and it looks like things are starting to move a little bit on the 5.x support, which is why I started back up on coding on that PR a little. 

>Even better it'll also remove the ES dependency 

It won't. There's still a few things in the code that rely on the ES dependency. Here's the list.

```
import org.elasticsearch.Version;
import org.elasticsearch.common.unit.DistanceUnit;
import org.elasticsearch.common.xcontent.XContentBuilder;
import org.elasticsearch.common.xcontent.XContentFactory;
import org.elasticsearch.search.builder.SearchSourceBuilder;
import org.elasticsearch.search.sort.FieldSortBuilder;
import org.elasticsearch.search.sort.SortOrder;
import org.elasticsearch.index.query.OrFilterBuilder;
import org.elasticsearch.index.query.AndFilterBuilder;
import org.elasticsearch.index.query.FilterBuilder;
import org.elasticsearch.index.query.FilterBuilders;
import org.elasticsearch.index.query.QueryBuilders;
```
These could probably be replaced, but I hadn't really intended to do that work right now. So it will get things closer to being able to remove that ES dependency, but it's not _quite_ there yet.

On Fri, Mar 24, 2017 at 7:54 PM sjudeng <sju...@...> wrote:
Keith, I looked over the latest commit on your Jest update branch. Do you think the update to support running tests through ESIntegTestCase will be worth the additional complexity of needing to separate out into multiple ES test modules? Personally my preference in this case would be to stay with the approach of testing through a full instance via the ES distribution artifact available since 2.x and added in #79. I think there's value in running tests against an actual (fully unmocked) ES instance, the implementation is cleaner, and it supports testing against any 2.x and 5.x distribution. We already have approval to drop support for 1.x (after the 0.1.0 release).

Also since I think we have consensus on the path forward to update ES (merging #79 and then migrating to Jest), would you consider retargeting your Jest update commits onto the branch in #79? My hope is we'll be able to get #79 merged after the 0.1.0 release is out/started. I think your updates to use Jest will improve that implementation by removing all the custom REST request/response objects I added. Even better it'll also remove the ES dependency (right?), which will free us up for the Lucene upgrade.

Thanks for your work on this and for making it visible via your WIP PR. However we proceed I think communicating early and often is helpful here.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Elasticsearch Http using Jest

sjudeng <sju...@...>
 

Sounds good. Hopefully the Jest 5.x jar will be backwards compatible with ES 2.x in the same way the ES REST client is.


Re: [DISCUSS] 0.1.0 Release Prep

Florian Hockmann <f...@...>
 

I agree with your assessment of the issues for the first release which basically comes down to the conclusion that only #171 has to be resolved for the release if I didn't miss anything. (Assuming that #120 isn't seen as a show stopper as the documentation was already unclear for Titan in that regard.)

Therefore I hope that #171 can be quickly resolved so that we have a first official release. (Unfortunately I cannot provide any input there as I never worked with BerkleyDB.) But in case that #171 takes longer to be resolved I would highly appreciate another snapshot release as the current release branch probably resembles already the final release for everything apart for the BerkleyDB storage backend. The current snapshot is probably not an option for most people to upgrade from Titan as it is not backwards compatible when using Cassandra as the storage backend (due to missing changes from #80).

Am Sonntag, 26. März 2017 21:09:06 UTC+2 schrieb Ted Wilmes:

Nice summary and I'm in agreement with the ones you've marked to remove from the milestone.
In addition, I think #120 could be pushed.  These are all important, but I do not think critical, for the 
first release.  I'm also in agreement that #171 should be added.  I saw your note on that and I'll take
a look at it too.

--Ted

On Sunday, March 26, 2017 at 12:31:51 PM UTC-5, sjudeng wrote:
Thanks for getting the ball rolling on this. Below are my recommendations based on 0.1.0 being scoped as an initial compatibility release to enable the easiest possible Titan->JanusGraph transition. In this case no new features are really required.

#41 TinkerPop 3.2 upgrade (status: closed)
- I closed this issue assuming it's reasonable to tie it to the upgrade to 3.2.3 and opened a new issue for the update to 3.2.4, which in my opinion isn't a blocker for the 0.1.0 release. It is worth noting though that JanusGraph TinkerPop tests do require a TinkerPop commit that is not in 3.2.3. I recommend making a temporary note of the workaround steps for this in documentation (e.g. BUILDING.md), which could be removed after updating to 3.2.4.

#74 Automated testing in Travis (remove from 0.1.0 milestone)
- I think it's important that all tests (including TinkerPop tests) are run on the release candidate, but I don't think it's necessary for this to be fully automated through Travis.

#120 Improve documentation of ids.num-partitions
- I can go either way on this one.

#128 Dependency license check in Travis (remove from 0.1.0 milestone)
- Like testing this check could be manual for 0.1.0.

#132 Non-permissive licenses in dependencies (remove from 0.1.0 milestone)
- From a user perspective these dependencies have been there since Titan and have not been added by JanusGraph. The only issue would be if there are additional restrictions on JanusGraph as a Linux Foundation project.

#133 Mark JTS optional in janusgraph-solr (remove from 0.1.0 milestone)
- Same as #132 above.

#147 Support custom ids (remove from 0.1.0 milestone)
- I don't think we're close on this and it's definitely a new feature (or a long outstanding bug?)

#171 Test failures in janusgraph-berkeleyje (add to 0.1.0 milestone)
- I think all tests need to pass for a release.

101 - 120 of 1585