We develop in a team an XPages application and we experienced that it takes longer time to build a project and to refresh the design of the templates on ACC and PROD environment. We noticed that a lot of files are being replicated so initially I thought it were the files for web-plugins like Datatables was causing troubles. But after I moved these files to a common shared resources NSF this XPages application still had a lot of unclear files in it.
When I analysed the design of the NSF with ScanEZ I saw that it contained almost a 1000 “Eclipse Files”. An analyse of another less frequently developed XPages application gave a similar indication, but here the number of Eclipse Files are a lot less, but still not reasonable:
The files that appear first in the list are “expected” (although for not all clear is clear what their purpose is) but then the list goes on as followed:
For some of the classes I have more than 30 versions of them!
I have stored these classes via the Package Explorer Eclipse view under WebContent\WEB-INF\src folder and added it to the build path. I added them here because it felt more alike to store them here as in Java projects outside of DDE. This seems to work fine from the start and still does except that as side-effect that you seem to get a lot of versions.
So what is the root cause of this misery (when building a project goes slow and it replicates undesired files across NSF’s) I don’t know. We use GitHub and I don’t notice the files in the source code. So they must appear when DDE is synchronising the ODP with the NSF.
So the files only reside in the NSF.
I have no clue how I should avoid the creation of these “version” files except storing the Java classes under the Code\Java section in DDE which has some disadvantages like collapsible packages (unnecessary scrolling) and new methods will be noticed in DDE AFTER I have closed and re-opened the project (SUCK).
Luckily via this approach the version files are being removed when you update the NSF via the “replace design” method. So in restricted-access environments like ACC and PROD this can save you some pain.
So if you have a suggestion and want to save my day, please write down what alternative way works for you. Happy development 🙂
Edit: I add here my painful experience with HCL regarding the issue above. I reported a case at HCL and their first response was that they do not give support on observations made from third-party tools (ScanEz). But when I replied that I make the same observation with HCL’s NotesPeek they replied that I should not place custom Java classes in custom folders in the Package Explorer view and add them as build path but as Code\Java design elements. Then I referred to an online WIKI-article of them where it is demonstrated how and where to create custom Java classes. As reply I got that this was a method for 8.5 and is no longer supported for newer releases. One might wonder what they have changed here after 8.5 but I guess not much.
Kwintessential Notes 
Do those classes have anonymous classes in them? That is, something like “Consumer foo = new Consumer() { … };”. “$” is the delimiter Java uses for embedded/inner classes, and anonymous classes show up with number indexes. For example, in a normal Mavan Java project I have, I have “GenerateUpdateSiteTask.class”, “GenerateUpdateSiteTask$CopyEmbedVisitor.class” (an inner static named class), and “GenerateUpdateSiteTask$1.class” (an anonymous subclass of SimpleFileVisitor).
With the Code/Java folder, these classes are all stored in the same note as the source, but WEB-INF/src (and any other custom source folder) creates separate class file notes. With a note in Code/Java, you can see the class data and file names in the $ClassData0, $ClassData1, etc. and $ClassIndexItem items.