<div dir="ltr">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.<div><br></div><div>So problem solved by simply moving themes from standalone/configuration/themes to standalone/themes.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 February 2016 at 16:15, Marko Strukelj <span dir="ltr"><<a href="mailto:mstrukel@redhat.com" target="_blank">mstrukel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm thinking of a workflow I would find useful, and I think it would<br>
be something like this:<br>
<br>
There is a directory with extracted theme files which I don't touch -<br>
$KEYCLOAK_HOME/standalone/configuration/themes/expanded. Keycloak<br>
automatically extracts files into it upon startup. I as a developer do<br>
a 'git init && git add * && git commit -a -m "Keycloak 1.9.0.CR1"' in<br>
it to turn it into a git repo.<br>
<br>
My theme development repo is somewhere else on the disk, outside the<br>
KEYCLOAK_HOME, let's say in ~/kc-theme.<br>
<br>
In there a have a .git repo with:<br>
git init<br>
git remote add kcinstall<br>
file://$KEYCLOAK_HOME/standalone/configuration/themes/expanded<br>
<br>
Now I can do:<br>
git fetch kcinstall<br>
git reset --hard remotes/kcinstall/master<br>
<br>
I have my inital custom theme. I make changes and work on it.<br>
<br>
When patching is performed on keycloak install it would result in<br>
either complete rewrite of standalone/configuration/themes/expanded or<br>
in only some files changing. If it is the former then I can simply<br>
reinit git repo there as the first time, it it's the latter I just do<br>
'git add * && git commit -a -m "Keycloak 1.9.0.Final"'. Then in my<br>
working dir I say:<br>
<br>
git fetch kcinstall<br>
git rebase remotes/kcinstall/master<br>
<br>
Now I fix any merge conflicts ...<br>
<br>
The effective theme dir for my Keycloak instance can be under<br>
standalone/configuration/themes/public, and in that directory I can<br>
expand my theme copy. Or for development I can configure in<br>
keycloak-server.json to use my working directory ~/ks-theme.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Mon, Feb 15, 2016 at 3:40 PM, Stan Silvert <<a href="mailto:ssilvert@redhat.com">ssilvert@redhat.com</a>> wrote:<br>
> On 2/15/2016 9:03 AM, Bill Burke wrote:<br>
><br>
> Users will be editing and playing with our existing themes to figure how to<br>
> extend things. I'll go as far to say that *EVERY* user will do this. It<br>
> needs to be really easy to do and is just as important as playing nicely<br>
> with the patch mechanism.<br>
><br>
> I agree on making it really easy.<br>
><br>
> IMO, the real solution is to make themes fully manageable from the admin<br>
> console. You should be able to upload and download themes. Then, you could<br>
> download the default themes and copy them but not allow overwrite.<br>
><br>
> This also solves the openshift problem as you would be able to upload themes<br>
> to an openshift-based Keycloak instance. And, we wouldn't have to do<br>
> anything special to account for the patch tool as the default themes would<br>
> just be read from the module and never modified unless patched.<br>
><br>
> Obviously, that's more of a long-term solution though. It would take a fair<br>
> amount of work to implement.<br>
><br>
><br>
><br>
> On 2/15/2016 4:08 AM, Stian Thorgersen wrote:<br>
><br>
> Keeping it as is isn't an option IMO. There's a pretty big chance that we<br>
> will need to patch themes. There's several issues with that as it stands:<br>
><br>
> * Users need to deal with two separate patching mechanisms and we also need<br>
> to create tools, patches, documentation separately<br>
> * What if users change the built-in themes, rather than extending. We tell<br>
> users not to, but if they can they will. If a built-in theme has been<br>
> changed patches probably won't work<br>
> * EAP supports roll-back of patches, applies patches atomically. It's a<br>
> proper tool that helps users to do it right<br>
> * EAP supports domain mode<br>
><br>
> What Stan is proposing might be worth considering. It doesn't solve the case<br>
> that users can modify the files though.<br>
><br>
> I would actual prefer that built-in themes are always loaded from the<br>
> module, but we have the templates available in exames/themes/templates.<br>
><br>
> Another relevant thing is what do we do when users have modified templates.<br>
> How can we help them apply the required changes to the custom template?<br>
><br>
> On 12 Feb 2016 19:32, "Stan Silvert" <<a href="mailto:ssilvert@redhat.com">ssilvert@redhat.com</a>> wrote:<br>
>><br>
>> BTW, how do you deal with theme changes on OpenShift? Looks like a year<br>
>> ago the answer was, "fork the cartridge". Is that still the only solution?<br>
>><br>
>> <a href="http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html</a><br>
>><br>
>> On 2/12/2016 12:46 PM, Bill Burke wrote:<br>
>><br>
>> Keep it the way it is, IMO. Write directions on how to handle a theme<br>
>> patch.<br>
>><br>
>> On 2/12/2016 11:01 AM, Stan Silvert wrote:<br>
>><br>
>> Another way to deal with this might be to unjar the files ourselves at<br>
>> startup. The files could live in the same place they live today.<br>
>><br>
>> We would just have keep track of versioning. If a newer version of the<br>
>> theme is installed we overwrite the old version in<br>
>> standlone/configuration/themes. Of course, if the theme has been modified<br>
>> by the user we wouldn't overwrite, but instead just unjar to another<br>
>> location.<br>
>><br>
>> On 2/12/2016 9:44 AM, Stian Thorgersen wrote:<br>
>><br>
>> Currently we include built-in themes in the themes jar as well as<br>
>> extracted to standalone/configuration/themes. We have to remove the<br>
>> extracted files.<br>
>><br>
>> This is due to patching. The patching tools only supports patching<br>
>> modules, not files. If we need to patch the theme templates (quite likely we<br>
>> will) we can then only patch the jar. As the extracted themes override the<br>
>> jar it won't work unless we remove them.<br>
>><br>
>> The main problem with removing the extracted files is that they are useful<br>
>> for someone that needs to modify the templates. I think the best would just<br>
>> be to give people instructions on how to extract these from the jar. It's<br>
>> just a zip after all.<br>
>><br>
>> Thoughts??<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> keycloak-dev mailing list<br>
>> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> keycloak-dev mailing list<br>
>> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
>><br>
>><br>
>> --<br>
>> Bill Burke<br>
>> JBoss, a division of Red Hat<br>
>> <a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> keycloak-dev mailing list<br>
>> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> keycloak-dev mailing list<br>
>> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> keycloak-dev mailing list<br>
> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
><br>
><br>
> --<br>
> Bill Burke<br>
> JBoss, a division of Red Hat<br>
> <a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> keycloak-dev mailing list<br>
> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> keycloak-dev mailing list<br>
> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div></div></blockquote></div><br></div>