don't fork fcrepo4 to avoid pair-tree in url

[ndushay]

IF we want to continue avoiding pair-tree in url

http://localhost:8983/fedora/rest/b886bab7-45b4-4739-aaec-153b2e8e98aa

rather than

http://localhost:8983/fedora/rest/b8/86/ba/b7/b886bab7-45b4-4739-aaec-153b2e8e98aa

THEN: use runtime java vars for fcrepo4 rather than fork of fcrepo4 with diff minter.

We are currently using sul-dlss/hydra-jetty edge branch which is a fork of hydra-jetty with fedora 4.0.0.beta from late Oct 2014 altered to not have the pair tree. We use this for local development (local jetty instance) and we also create a fedora archive artifact with jenkins for puppet deployment to our fedora dev and stage boxes.

So IF we want to keep this localization, we can accomplish it with java env vars setting the following two properties to 0:

• fcrepo.uuid.path.length
• fcrepo.uuid.path.count

(See https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-webapp/src/main/resources/spring/minter.xml#L9-10)

We would do this with runtime args to jetty / tomcat, perhaps from a config file, like

 -Dfcrepo.uuid.path.length=0

HOWEVER: @cbeer informs us that NOT using the pair tree is a bad idea: "you’ll see performance problems if you don’t have path hierarchy. ... I can’t remember what the number is, but somewhere in the low thousands you start to notice problems."

So I think once #73 is addressed, we should let our urls have the pair-tree in them. That means the work for this ticket is actually:

• [x] hydra-jetty in triannon uses released fedora in projecthydra/hydra-jetty (See #187, #188)
• [x] fedora dev uses released fedora (puppet scripts w devops involvement) (See SAR-2759)
  • [x] waiting for (non-salt) nfs mount for the data
• [x] fedora stage uses released fedora (puppet scripts w devops involvement) (See SAR-2759)
• [ ] jenkins build for sul-dlss/hydra-jetty goes away
  • [x] marked deprecated
• [ ] sul-dlss/hydra-jetty goes away
  • [x] marked deprecated

[ndushay]

Note that Willy's minter.xml is here:

https://gist.github.com/wmene/82ae3de1c88d6fb2f9ae

and other localizations in sul-dlss/hydra-jetty can be viewed at https://github.com/sul-dlss/hydra-jetty/commits/fedora-4/edge -- basically, it was change the minter, rebuild the war file, add a Rakefile to build the artifact for jenkins.

[ndushay]

I have disabled hydra-jetty-custom in our jenkins and added deprecation warning to the description.

[ndushay]

Here is an email from Willy giving the context for the existence of our localized hydra-jetty and its jenkins build:

From: Willy Mene wmene@stanford.edu Subject: Status of Triannon and fedora4 deployment to our VMs Date: October 29, 2014 at 2:12:24 PM PDT To: Rob Sanderson azaroth@stanford.edu, Naomi Dushay ndushay@stanford.edu

Here's where we're at:

Fedora4 on sul-fedora-dev-a

• Because we need the latest fedora4 build, (and one that does not add slashes to identifiers), we forked the hydra-jetty project, and replaced the fedora4 war file with our custom build here: https://github.com/sul-dlss/hydra-jetty/tree/fedora-4/edge
• Our jenkinsqa server monitors this git repo, and runs a rake task to copy the latest war file to the /jenkins/artifacts directory https://jenkinsqa.stanford.edu/job/hydra-jetty-custom/ . This makes it available to our Puppet infrastructure as a deployable war file
• fedora4 needs Java 7. Unfortunately, our Puppet infrastructure does not support installing Java 7 or a tomcat that works with Java 7. The sysadmins plan to use new classes/modules from Puppet Labs to make java7 and tomcat available. I will be working with Erin next week to get this deployed to sul-fedora-dev-a

Triannon web service on triannon-dev

• Created a simple rails app that uses the triannon engine https://github.com/sul-dlss/triannon-service
• Ready to deploy with capistrano once Erin finishes setting up triannon-dev

[ndushay]

@eefahy I just want to confirm that I can remove the jenkins build at https://jenkinsqa.stanford.edu/job/hydra-jetty-custom/ and that I can remove the git repo https://github.com/sul-dlss/hydra-jetty -- no puppet dependencies now, correct?

[ndushay]

@eefahy - I would love to close this ticket. Waiting on you to confirm that I can remove the jenkins build at https://jenkinsqa.stanford.edu/job/hydra-jetty-custom/ and that I can remove the git repo https://github.com/sul-dlss/hydra-jetty -- no puppet dependencies now, correct?

[eefahy]

Actually the machine that Josh wanted (sul-fedora-dev-lt) is currently pointed to that war file. I can get in touch with Josh about it soon, but I don't think he's actually using it.

[ndushay]

@jgreben @eefahy if we need to keep it, the github repo should be revised to say why, and the jenkins build description should also be revised to say why.

Personally, I love getting rid of things we no longer need.