Genome annotation editor, with a Java servlet backend and a Javascript client that runs in a web browser as a JBrowse plugin
cd apollo-gmod-js
rm -rf
cp -r
rm -rf
pwd/temp-apollo-test-datacp -r
pwd/test-data pwd/temp-apollo-test-data
I guess we coudl do that offline
should have at least one of you here
Is there a calendar invite
@garrettjstevens / @peterkxie the https://github.com/GMOD/Apollo3Server build works now. bintray was deprecated as a host for jfrog. Let me know if you have any troubles.
Also, there is a meeting next Tuesday at 8 am PT.
invites will go out. Let me know if that time doesn’t work.
FYI if you want a pure micronaut / swagger installation, I started this branch: https://github.com/GMOD/Apollo3Server/tree/micronaut-swagger
A little more than what we or most curators want, but definitely worth taking a look at
./gradlew devmode
@peterkxie / @garrettjstevens / @rbuels not sure long-term what you guys are doing, but I’ve been pretty impressed with nestjs + graphql. I like the code-first approach (very similar to running an ORM in some ways, but without the overhead of bound objects). Coupling with neo here: https://medium.com/@faaizhussain/nestjs-graphql-neo4j-1e3e6e552a80 kind of interseting / FYI
Neo4j has been picked up and well used by a number of Bioinformatics projects, including Reactome. Supported by a number of different languages, tools, etc. GraphQL is also really interesting opportunity. One of our GSoC projects last year was to create GraphQL API for the Reactome Neo4j. Lincoln like this approach!
@hawrobin agreed, that IS a really nice approach
Been dabbling with some optimization and overall health inspections of our stack at the CPT. Additionally, some "free-ish" money is around for server upgrades. Are there any recommended "specs" for a production-grade server? I have found some RAM recommendations (https://github.com/GMOD/Apollo/blob/develop/docs/Troubleshooting.md#tomcat-memory), I'm curious if there's anything else in another place that could perhaps help me guide my mouse to an appropriate server for ~100ish of concurrent users. The node we have right now is shared with Galaxy, and things can get pretty clunky during high usage times, especially during the semesters that we teach. Any thoughts on this?
@rbuels: I still have merge permissions on apollo, you ok with me merging PRs? (there's a small one from Anthony Bretaudeau fixing the blastview plugin)
not sure how you want to handle PRs/project maintenance since I'm guessing most work is going to be apollo3 and 2 is just maintenance mode now
3 replies
At the moment, the Dockerfile in the apollo repo, develop branch is failing to build. It looks to me like it is a grails problem, as the first indication of a problem is this line
Error Resolve error obtaining dependencies: Could not transfer artifact org.odftoolkit:odfdom-java:jar:0.8.5 from/to repo_grails_org_grails_core (http://repo.grails.org/grails/core): Permanent Redirect (308) (Use --stacktrace to see the full trace) with a simple build (docker build .) but to be honest, I’m not that experienced with apollo builds. Any ideas?
Looks like they may have changed the structure of their website and something in the installation tools can't follow the redirect.
OK, still working on getting the Apollo container to build. I switched to pulling from the develop branch for Apollo, and it felt like it was working, because the build ran longer, but it ended up dying at the same place as above, trying to get odfdom-java. I thought the problem was a failure to gracefully redirect (since there is a 308 error thrown), and that may still be the most current problem, but when I go in a browser to
http://repo.grails.org/grails/core and get redirected to https://repo.grails.org/artifactory/core/, I see that there is no listing for odfdom-java there, so even if the redirect were successful, I don’t think the build would complete successfully. So, I’m left wondering if we can/should try to get odfdom-java from somewhere else, or I am misinterpreting what’s going on? @garrettjstevens @nathandunn