Improve build process

[lucasvanlierop]

Since this project is mainly a wrapper around Janus and some config which only makes Janus development harder it should be phased out.

• [ ] Move separate configuration files to config templates in Janus
• [ ] Move parsers for separate configuration files to Janus
• [ ] Move override config for Surfconext/OpenConext to deployment repository.

[pmeulen]

We do need a place store a janus config for OpenConext. This project is a good place for that.

[lucasvanlierop]

Well it seems a good place for this at first, however @relaxnow and I discussed this and there are a few issues with ServiceRegistry:

• It makes developing in Janus harder since you nearly always develop in Janus instead of ServiceRegistry which requires updating ServiceRegistry everytime you make a change to Janus.
• The config in ServiceRegistry is not 'OpenConext' but 'SurfConext'
• The config in ServiceRegistry needs overriding for various environments of SURFNet which requires separate config files/repos anyway.

When using the OpenConext vm tools for installing Janus, I suggest it should:

• Install Simplesamlphp
• Install Janus as a plugin
• Instal the desired config from a SURFnet private repository

@relaxnow, do you have anything to add to this?

[relaxnow]

@lucasvanlierop well put.

An OpenConext parent project for Janus with configuration seems like a good idea in theory, but in practice it really gets in the way of maintenance and the cost doesn't outweigh the benefits. We still need some place for SURFconext and OpenConext configuration of Janus and the SSP instance it's hosted in, but we have application specific configuration for all OpenConext / SURFconext components. It's better to host the configuration there.

[pmeulen]

Janus can't function standalone. It needs SSP to function. I see serviceregistry as the complete application. This repo is where we keep the recipe for making the app, and the OpenConext config. Janus currently uses SSP as a framework. Not just for authentication, but also for storage, page rendering.

• It makes developing in Janus harder since you nearly always develop in Janus instead of ServiceRegistry which requires updating ServiceRegistry everytime you make a change to Janus.

You need to make a release of SR, yes

• The config in ServiceRegistry is not 'OpenConext' but 'SurfConext'

IMO 99% is OpenConext. Some SURF specific config needs to be pulled out still:

• the available language strings are always array('en', 'nl')
• some of the defaults mention surf
• others?

• The config in ServiceRegistry needs overriding for various environments of SURFNet which requires separate config files/repos anyway.

This will be true for any SR installation.

I am not convinced that making this change now provides much benefits. It will require extra work (change) to existing users of SR: OpenConext-VM and SURFconext production platform

[relaxnow]

I am currently having to wait 15 minutes (and periodically check up on) on updating the SR parent project for every bugfix that I make. That might not sound like a lot, but it is when you want to try to get for instance the integration tests to run again and need to iterate rapidly.

Worse is that when you start development you have to look in the 'vendor' directory for the main functionality, which is really strange (for instance the default search of our IDE is now a lot less useful because you constantly have to search the entire project).

We're not saying that we should not have a 'serviceregistry' component that has the 'recipe' for building SSP + Janus + OpenConext config. We're just saying that it shouldn't be Composer that does this building (because it's horrible at it, it has to duplicate all JANUS dependencies check them double).

I've changed the issue title to reflect the actual issue here. Where the configuration files are placed is an implementation detail that largely also depends on the work that's being done with the VM.

[lucasvanlierop]

@relaxnow :+1: