Let me question this once more... does this really belong in fcrepo-webapp and not kitchen sink?

I think it does not, but @eddies specifically told me otherwise.

@eddies, who's that? isn't he off the project now?

@eddies: Is this a piece of functionality from the steering group reqs?

@ajs6f can you merge fcrepo-auth-oauth into the fcrepo4 repository? if we're actually baking this in (and @eddies has convinced me that we should), it should live close-to-core rather than our only free-floating dependency.

I can, but would we rather do a Git submodule? I'm really going to try to be a bear about trying to break up the main fcrepo4 repo. We agreed a long time ago to try to separate it for flexibility.

Actually, do we want to move towards breaking up fcrepo4 entirely and doing git submodules under fcrepo-webapp, so that you can just clone fcrepo-webapp and build?

For now, no, let's not try to break up fcrepo4 any more before OR. And submodules are more confusing than they're worth IMHO (esp. for other users)

So… move fcrepo-auth-oauth under fcrepo4? Okay, I'll do that tomorrow.

And for completeness, here's the part of @eddies' argument that convinced me:

if we don't have an authz framework baked into core, nothing will drive the development that's needed to support generic authz features. The only auth implementation we have now that's worth anything is oauth, so let's ship it. (sure, we have the container-level auth that may or may not work with the native JCR stuff.. but we know we want more granular policies than that..). Hopefully that'll be enough to annoy us to e.g. hard-coding an authorized path into the webapp config and someone will fix it.

he also had nice things to say about oauth, but i'm not sure i believe them yet.

This stuff all looks pretty familiar. We can fiddle with injection strategies pre-Beta.