Community
Participate
Working Groups
N20050504-1000 I have a workspace where I reference external plug-ins via the PDE container form my Eclipse installation. When I updated my eclipse installation form N20050503-0010 to N20050504-1000 the search indices didn't get rebuild although the content of core.resources did change. As a result I don't see the new types which got added in internal.core.resources.mapping. Browsing to this package shows that is exists and that the types are there.
To clarify: I don't see the types in the all type dialog which now queries them from the index.
Reproduced. The index for the jar file was not rebuilt. Its timestamp has definitely changed so it should have been rebuilt... investigating.
If the plugins are imported as binary projects with linked content -> it works fine. But I'm able to reproduce when the jar file is added to search by PDE, so that it shows up in the External Plug-in Libraries.
Dirk, how is the jar attached in your workspace? Did you add it to Java Search using PDE?
I think we should also check consistency of indexes/builds after startup when you open the search dialog, as we do now with the open type dialog.
Jerome/Philippe : where do we detect external jar file changes? Or do we? Cause it looks like we never reindex them.
I simply get the jars via the PDE container. I don't use the PDE magic for adding stuff to the Java search.
It appears that an optimization to SetClasspathOperation is causing us to miss the changes to the external jar files. We have 2 choices: 1. Take out the optimization 2. Or start recording the timestamp of the jar file in savedIndexNames.txt so we can rebuild the index ourselves when we first open it on startup. My preference is to do #2 unless the optimization is causing problems elsewhere.
The optimization needs to be 'improved' The builder & index manager rely on callbacks that external jar files have changed.
Actually the optimization is not the culprit. I just verified that the problem existed in 3.0 as well.
Lowering priority since this is not a regression.
It may not be a regression BUT we would have never shipped 3.0 with this bug if we knew about it.
We want to investigate a fix for 3.1rc1, I agree it is bad.
Changed JavaCore#initializeAfterLoad() to force a refresh of all external jars. Note this method needs to be called by JDT UI first to see the index beeing rebuild. Also changed JavaBuilder#build(...) to refresh the external jars of the project (only in the case of a full build triggered by the user). Added regression tests ExternalJarsDeltaTests#testExternalJarChanged5() and testExternalJarChanged6().
Jerome, may be I am misunderstanding but IMO rebuilding the search indexes shouldn't be coupled to initializeAfterLoad since there will be no guarantee that this method will be called. My understanding is that this method is optional.
There are now several ways to refresh external jars: - refresh action - full build - initializeAfterLoad All these actions have the nice characteristic that they don't run on startup but later on. If JDT Core would force the refresh of external jars, it could only be on startup. This would cause classpath resolution, and we would be back to the state we had in 3.1 M6.
Are you saying that you never detect this case which makes the whole story of PDE plug-in containers questionable. Shouldn't PDE then at least try to detect this an trigger some action when they resolve the class path ?. I am a little bit affraid of putting all this into initializeAfterLoad since this will result in the fact that we will not call it since it will be to expensive as well. How expensive will the whole initializeAfterLoad now be ?
We never detect automatically that external jars have changed whether they come from the PDE container, the JRE container, a variable, or even if they are on the raw classpath. This is true since at least 3.0. The cost of initializeAfterLoad(...) will not be increased by this addition (or this will not be noticeable).
Kent - talking with Jerome, we need you to also protect both indexes and build states reading with timestamp. There could be situations where #initializeAfterLoad() wouldn't run (headless mode, or before jdt/ui opens). Also if doing so, I wonder if a full build would need to force a refresh, since it would likely occur for free, wouldn't it ?
I don't follow... why is a refresh necessary? If the builder/indexer start detecting jar file timestamp changes, then the full build or rebuild of index files will happen whenever the user does a search or build... could be 10 minutes after startup. What would be picked up by a refresh? What new/deleted resources did the workspace not know about?
The external jars refresh will create Java deltas for jars that have changed, and clients could benefit from these deltas.
What other clients are there? And if the builder/indexer is responsible for detecting changes, why aren't these other clients also responsible?
Checked with JohnA & since the resource tree does not include external jar files, the default refresh doesn't find them & doesn't issue any deltas for them. How are clients informed when they changed?
The platform doesn't know about external JARs, which is the sole reason for this issue to exist. The normal way to discover JAR changes, is to perform a Java model refresh operation (not platform). This broadcasts Java deltas as normal Java operations for client of Java model APIs. Jerome hooked invocation of refresh in #initializeAfterLoad API and full build. If you do protect the build state, then he could remove the invocation from full build. If you protect the indexes, these could be recreated lazily, but the purpose of #initializeAfterLoad is to catch early situations where quite a few tasks are required before giving full control to user. But, #initializeAfterLoad is only optional, and is just a hint from client to indicate that now is an appropriate time to perform inits (should still remain bound initialization effort in normal cases). Having indexes be only recreated after 2 hours in the session (after being idle for a long time) isn't very useful... unless we believe users will never use any search/codeassist.
So who should the builder/indexer tell when they detect an external jar file has changed? And will this cause an infinite loop if the builder/indexer remain clients of this notification?
+1 for RC2
Added timestamps for external jars to the build state. Will now check on every incremental build if any external jar file has been replaced. Moving to Jerome so he can change the DelatProcessor to notice that a CLEAN build has started and perform a workspace wide refresh of external jars so index files are also rebuilt.
I left the call in the JavaBuilder.build method until the DeltaProcessor changes are made. Also the DeltaProcessor is still nulling out the build state in checkExternalArchiveChanges()
Removed the call that was nulling out the delta state in DeltaProcessor. Removed the call to force a refresh on full build in JavaBuilder. The DeltaProcessor was actually alreay handling the case. Updated ExternalJarDeltaTests#testExternalJarChange6().
Verified for 3.1 RC2 using build N20050607-0010 +JDT/Core HEAD.
Verified.
Verified for 3.1 RC2 using build I20050610-0010
