[jsword-devel] Feature found

[DM Smith]

I found a "feature" which I am working on fixing.

When the xsl is compiled for reuse, it works very well to check each 
time it is used to see if there is a change and recompile it when it 
does. The compilation is expensive so it is best for the user to compile 
it. And recompiling it when it changes allows a developer to bring up 
the application and test iterative changes to the xsl. It serves no 
advantage to a non-developer.

The problem is when the xsl is in a jar the NetUtil.getLastModified 
returns the current time and the net result is that the xsl is compiled 
every time it is used.

I see three possible solutions:
1) return 0 when the resource is in a jar. This is the simplest 
solution. The problem with this is that if there is any persistence of a 
n artifact based upon that timestamp, then it will not see any changes.
2) return the timestamp of the jar. So if there is persistence and the 
jar changes then it would force a recompile even if the xsl did not 
change. The basic thought is that the changes to the jar are going to be 
relatively infrequent and even recompiling the xsl once for each run of 
the application is not that big a deal.
3) return the timestamp on the file in the jar. This is a complete 
solution and matches the expectation of the method's contract.

The form of the url that I am trying to work with is:
jar:file:/a/b/c/jarname.jar!/x/y/filename.ext

In this case I can pick off the file:.../jarname.jar and the 
.../filename.ext and use JarFile to get the JarEntry to interrogate.

The problem is that the solution is still not completely generalized. 
What if the jar's file is served up via ftp or http. I don't know what 
that url would look like. Would it be something like:
http:jar:file:.../jarname.jar!.../filename.ext.

I am inclined to do nothing for this situation.

On another note, I think Eclipse M9 is coming out later today. I have 
been using an integration build for the last week and it is better than M8.