3:44 p.m.
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??
4:55 p.m.
Putting the themes into a module jar raises two usability issues:
1) They have to be extracted and the re-jarred
2) Modules live many, many level deep in the directory structure and are
therefore hard to find.
I'm not familiar with the limitations of the patching tool, but is seems
that we could do this:
* Don't put themes in a jar. Plain files can also live inside a module.
* Create a second module directory structure. JBoss Modules lets you
have multiple paths for modules. So we just have a <KEYCLOAK
HOMe>/themes path that is a known module path.
The question is, will the patching tool be able to deal with that? If
not, we need to fix the patching tool.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:01 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6:46 p.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:31 p.m.
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:08 a.m.
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(a)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
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hathttp://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:03 p.m.
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.
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(a)redhat.com
<mailto: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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org <mailto: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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:40 p.m.
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(a)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(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
<mailto: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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:15 p.m.
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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:40 p.m.
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(a)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(a)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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2992
days inactive
2996
days old
9 comments
4 participants
participants (4)
-
Bill Burke -
Marko Strukelj -
Stan Silvert -
Stian Thorgersen