[ 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)