Subresources not reloaded in development mode

[jglick]

While using

mvn -pl war jetty:run

on core in jenkinsci/jenkins#5496 I noticed that changes to core/src/main/resources/lib/hudson/artifactList.jelly were not being reloaded, though changes to a top-level Jelly file (l:layout) are reloaded. git bisect found jenkinsci/jenkins#4813 which implies that #184 is responsible for the regression (not the more recent #220).

[timja]

I’ve noticed this, it’s very annoying -.-

[jglick]

If you happen to know what is going on, a patch to fix it would be great! I would not like to just revert #184 since then we would be back to quite slow browsing in dev mode.

[timja]

If you happen to know what is going on

Sub resources don't go down the code path that is patched with a cache, looking to see if I can find a patch, but:

If you touch whatever view you're working on the sub resources will reload which is a fairly straightforward workaround and far better than restarting.

e.g. change something in src/main/resources/jenkins/model/Jenkins/configure.jelly

if you are working on src/main/resources/lib/form/textbox.jelly

[timja]

I've submitted 2 PRs as options:

#278
#279

Open to other suggestions

[jglick]

I think the proper fix would be for page rendering to track usage of custom tag libs and check their timestamps as well.

Other than custom tag libs, are regular includes (IIRC using st:include ~ IncludeTag) such as config.jelly chunks from Describables reloaded correctly?

[timja]

IIRC custom tag lib loading is all done inside of jelly, during compilation of the scripts.
I couldn't see a place to hook into it, (might be possible but won't have time to look into it again for awhile probably).

Other than custom tag libs, are regular includes (IIRC using st:include ~ IncludeTag) such as config.jelly chunks from Describables reloaded correctly?

not sure can check later

[jglick]

custom tag lib loading is all done inside of jelly […and] I couldn't see a place to hook into it

CustomTagLibrary.load is not called during page rendering as #279 implies? I guess it should be possible to set a request property (or at worst a thread-local) tracking the top-level script being rendered so that our cache entries enumerate all the files and their timestamps involved.

[timja]

It's called as part of compiling the scripts as the scripts are parsed jelly will load them and compile.

It is called during page render just not from any of our code.

Yes that would probably work, the jelly context is available afaik