Mailing-List: contact dev-help@click.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@click.apache.org
Message-ID: <28219431.419921285591173958.JavaMail.jira@thor>
Date: Mon, 27 Sep 2010 08:39:33 -0400 (EDT)
From: "Bob Schellink (JIRA)" <jira@apache.org>
To: dev@click.apache.org
Subject: [jira] Commented: (CLK-719) Click Resources Deploying prevents
 rapid development with container's (tomcat in my case) hot deploy
In-Reply-To: <2415581.363251285245213986.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CLK-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915290#action_12915290 ] 

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: https://issues.apache.org/jira/browse/CLK-719
>             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 folder).
> 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 (redeploy)

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