[ 
https://issues.apache.org/jira/browse/TAP5-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17742256#comment-17742256
 ] 

Hudson commented on TAP5-2742:
------------------------------

SUCCESS: Integrated in Jenkins build Tapestry ยป tapestry-java-17-freestyle #62 
(See 
[https://ci-builds.apache.org/job/Tapestry/job/tapestry-java-17-freestyle/62/])
TAP5-2742: fixing ComponentDependencyGraphvizGeneratorImpl (thiago: rev 
50eef37fa00fe3d159300df4a7ac0d57091b792a)
* (edit) 
tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ComponentDependencyGraphvizGeneratorImpl.java
* (edit) 
tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Graphviz.java


> Smarter page cache invalidation
> -------------------------------
>
>                 Key: TAP5-2742
>                 URL: https://issues.apache.org/jira/browse/TAP5-2742
>             Project: Tapestry 5
>          Issue Type: Improvement
>          Components: tapestry-core
>            Reporter: Thiago Henrique De Paula Figueiredo
>            Assignee: Thiago Henrique De Paula Figueiredo
>            Priority: Major
>             Fix For: 5.8.3
>
>
> Since Tapestry 5's inception, it throws the whole set of assembled page 
> instances when anything related is changed, be it the class itself, its 
> template and maybe also associated messages and assets. In very large 
> projects with large pages, this can reach a point it slows down the user 
> (programmer) productivity, forced to wait for unchanged pages to be 
> reassambled. 
> Tapestry should provide some way for users to segment page, component, mixin 
> and base classes to separate regions, one for each classloader, to avoid 
> clearing out cached page instances that don't have themselves or the classes 
> they use changed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to