click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink (JIRA)" <>
Subject [jira] Commented: (CLK-719) Click Resources Deploying prevents rapid development with container's (tomcat in my case) hot deploy
Date Mon, 27 Sep 2010 12:39:33 GMT


Bob Schellink commented on CLK-719:

To clarify my question: Click deploys resources as follows:

1: deploy all resources on the ServletPath -> ServletContext#getResourcePaths
2. deploy resources under WEB-INF

So if a developer wants to override a resource they can simply create a custom version and
put it in their webapp. For example:
/click/control.js would override the control.js file deployed by Click itself.

With this change the control.js in the  Click jar would be deployed over my changes.

Another thing to consider is IDE's. In Netbeans at least, it uses an exploded war and would
immediately copy changes to J/CSS/HTM files to the output folder. If Click were to override
these resources upon startup I'd loose my changes when the server hot-deploys.

Does this clarify my question?

> Click Resources Deploying prevents rapid development with container's (tomcat in my case)
hot deploy
> ----------------------------------------------------------------------------------------------------
>                 Key: CLK-719
>                 URL:
>             Project: Click
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 2.2.0, 2.1.0
>            Reporter: Andrew Fink
> Example:
> I have some template in "META-INF/resources", for ex:  META-INF/resources/admin/blabla.ftl
> I run tomcat under my IDE:
> 1) it deploys webapp - OK
> 2) click deploys  META-INF/resources/admin/blabla.ftl to webroot/admin/blabla.ftl - OK
> Then I see some mistake in blabla.ftl and bug fix it, build and deploy again.
> 1. Tomcat re-deploys webapp over existing webapp - OK!
> 2. Click doesn't deploy  blabla.ftl because It already exists (tomcat/IDE doesn't clean
> It is a problem.
> __ ClickUtils.deployFile checks only destinationFile.exists() __
> I think in debug|trace mode, Click should:
> - always overwrite (redeploy) files,
> - or checks resource length (for example: skip all bytes from resource's inputStream
to calculate it's length) and if destinationFile.length != resource.length then overwrite

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message