We've had chats with folks that know about the patching tools now and it turns out that by simply moving the themes from standalone/configuration/themes they can be patched. If someone has changed the built-in themes they will get a warning and be asked if they want to cancel the patching or overwrite the file.

So problem solved by simply moving themes from standalone/configuration/themes to standalone/themes.

On 15 February 2016 at 16:15, Marko Strukelj <mstrukel@redhat.com> wrote:
I'm thinking of a workflow I would find useful, and I think it would
be something like this:

There is a directory with extracted theme files which I don't touch -
$KEYCLOAK_HOME/standalone/configuration/themes/expanded. Keycloak
automatically extracts files into it upon startup. I as a developer do
a 'git init && git add * && git commit -a -m "Keycloak 1.9.0.CR1"' in
it to turn it into a git repo.

My theme development repo is somewhere else on the disk, outside the
KEYCLOAK_HOME, let's say in ~/kc-theme.

In there a have a .git repo with:
git init
git remote add kcinstall
file://$KEYCLOAK_HOME/standalone/configuration/themes/expanded

Now I can do:
git fetch kcinstall
git reset --hard remotes/kcinstall/master

I have my inital custom theme. I make changes and work on it.

When patching is performed on keycloak install it would result in
either complete rewrite of standalone/configuration/themes/expanded or
in only some files changing. If it is the former then I can simply
reinit git repo there as the first time, it it's the latter I just do
'git add * && git commit -a -m "Keycloak 1.9.0.Final"'. Then in my
working dir I say:

git fetch kcinstall
git rebase remotes/kcinstall/master

Now I fix any merge conflicts ...

The effective theme dir for my Keycloak instance can be under
standalone/configuration/themes/public, and in that directory I can
expand my theme copy. Or for development I can configure in
keycloak-server.json to use my working directory ~/ks-theme.



On Mon, Feb 15, 2016 at 3:40 PM, Stan Silvert <ssilvert@redhat.com> wrote:
> On 2/15/2016 9:03 AM, Bill Burke wrote:
>
> Users will be editing and playing with our existing themes to figure how to
> extend things.  I'll go as far to say that *EVERY* user will do this.  It
> needs to be really easy to do and is just as important as playing nicely
> with the patch mechanism.
>
> I agree on making it really easy.
>
> IMO, the real solution is to make themes fully manageable from the admin
> console.  You should be able to upload and download themes.  Then, you could
> download the default themes and copy them but not allow overwrite.
>
> This also solves the openshift problem as you would be able to upload themes
> to an openshift-based Keycloak instance.  And, we wouldn't have to do
> anything special to account for the patch tool as the default themes would
> just be read from the module and never modified unless patched.
>
> Obviously, that's more of a long-term solution though.  It would take a fair
> amount of work to implement.
>
>
>
> On 2/15/2016 4:08 AM, Stian Thorgersen wrote:
>
> Keeping it as is isn't an option IMO. There's a pretty big chance that we
> will need to patch themes. There's several issues with that as it stands:
>
> * Users need to deal with two separate patching mechanisms and we also need
> to create tools, patches, documentation separately
> * What if users change the built-in themes, rather than extending. We tell
> users not to, but if they can they will. If a built-in theme has been
> changed patches probably won't work
> * EAP supports roll-back of patches, applies patches atomically. It's a
> proper tool that helps users to do it right
> * EAP supports domain mode
>
> What Stan is proposing might be worth considering. It doesn't solve the case
> that users can modify the files though.
>
> I would actual prefer that built-in themes are always loaded from the
> module, but we have the templates available in exames/themes/templates.
>
> Another relevant thing is what do we do when users have modified templates.
> How can we help them apply the required changes to the custom template?
>
> On 12 Feb 2016 19:32, "Stan Silvert" <ssilvert@redhat.com> wrote:
>>
>> BTW, how do you deal with theme changes on OpenShift?  Looks like a year
>> ago the answer was, "fork the cartridge".  Is that still the only solution?
>>
>> http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html
>>
>> On 2/12/2016 12:46 PM, Bill Burke wrote:
>>
>> Keep it the way it is, IMO.  Write directions on how to handle a theme
>> patch.
>>
>> On 2/12/2016 11:01 AM, Stan Silvert wrote:
>>
>> Another way to deal with this might be to unjar the files ourselves at
>> startup.  The files could live in the same place they live today.
>>
>> We would just have keep track of versioning.  If a newer version of the
>> theme is installed we overwrite the old version in
>> standlone/configuration/themes.  Of course, if the theme has been modified
>> by the user we wouldn't overwrite, but instead just unjar to another
>> location.
>>
>> On 2/12/2016 9:44 AM, Stian Thorgersen wrote:
>>
>> Currently we include built-in themes in the themes jar as well as
>> extracted to standalone/configuration/themes. We have to remove the
>> extracted files.
>>
>> This is due to patching. The patching tools only supports patching
>> modules, not files. If we need to patch the theme templates (quite likely we
>> will) we can then only patch the jar. As the extracted themes override the
>> jar it won't work unless we remove them.
>>
>> The main problem with removing the extracted files is that they are useful
>> for someone that needs to modify the templates. I think the best would just
>> be to give people instructions on how to extract these from the jar. It's
>> just a zip after all.
>>
>> Thoughts??
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev