What's the point of Initializr?

[Dustin Luck]

I see that starting with today's release of CAS 6.3.6, the cas-overlay-template project is being automatically generated from the CAS Initializr. My current build process is as follows:

1. Check out or pull the latest source for the overlay template
2. Add the modules necessary for my specific build in build.gradle
3. Set my CAS version & container in gradle.properties
4. Configure properties files
5. Add UI customizations
6. Build WAR File (gradlew clean build)

Does the Initializr just replace steps 1 & 2 or am I missing something? Are there any benefits of using the Initializr over starting with the base overlay template for someone who is experienced with configuring the modules already?

[Sam Hough]

I'm not really sure. I only hit this yesterday. I've had the job of customising CAS for the last seven years or so and every time my heart sinks as it is always really painful. My guess is (supported by links from the documentation) that you can more quickly start a build with custom features BUT seems a bit of an extra nightmare as the gradle file has so much extra stuff in it.

I tried pushing on with my maven based build (it was running tests, making an RPM so I didn't want to just trash it) but hit weird errors. I read about the "submit pull requests not bug reports" which is all great unless you are trying to work out if you have hit a bug. 

I know it is free software and I'm possibly biased by it being a Friday afternoon after an annoying week.

What did you decide to do? I'm wondering if I can have whatever the latest/greatest way to get a CAS build is in a black box then have an independent build system to customise it. Seems overkill for a SpringBoot thing.

Cheers

Sam

[Dustin Luck]

So far, I'm following the same process as I did before. The cas-overlay-template repo is being automatically synced from cas-initializr, so I use that as my base. When upgrading to a new version, I like to add modules one by one so if there are any errors, it's more apparent which module to troubleshoot. This means that the Initializr's method of specifying the modules when creating the template would actually be more work for me as I would have to merge my customizations each time.

The part that I don't like is when I want to merge any changes from cas-overlay-template, I can't just do a git merge. The overlay repo does not have a change history; when the auto-generation process runs, it scrubs any previous commits. To work around this, I've been checking out the overlay repo to a temp folder, doing a manual merge, and committing the results to my fork of the overlay. Not optimal, but I guess this is the world I'm living in now.