Consolidation build code doesn't match dtr?

[Former Member]

I'm getting this error during a build in the consolidation compartment:

     [javac] Compiling 41 source files to /work/JDI/CBS/12/.B/454/t/89C8A1AF5586FDED0174DD43CBADA17F/classes
/work/JDI/CBS/12/.B/454/t/89C8A1AF5586FDED0174DD43CBADA17F/gwd/packages/ca/company/wl/browser/FavoritesCust.java:164: cannot resolve symbol
symbol  : method deleteFolderx (java.lang.String)
location: class ca.company.wl.browser.folder.FolderManager
			wfm.deleteFolderx(folderName);

If I use the WebDAV interface to browse the dtr, the line mentioned above does not match the line in the code. In fact, the line that caused the error was fixed weeks ago. I also checked out the active DC just to verify - the code is correct ie. does not have the above error.

Why is the build picking up the old code, when in fact the DTR shows that the correct code is in place? All activities have been checked in and activated; all transports have been released. Is there something I'm missing?

I have had this error in the past with the development compartment as well; the problem seemed to right itself after a day or so. It's almost as if some data files are cached somewhere in the build sub-system, so the current changes are not being picked up.

BTW, in case anyone is asking, SP16 (latest patches) on both the NWDI and NWDS.

[Former Member · Accepted solution]

Did you check the active DC in the _D DevConf or the _C DevConf?

[Former Member · Accepted solution]

_C DevConf.

The really weird thing is I just triggered a build, and the build was successful. There has to be some kind of caching going on...

[Former Member · Accepted solution]

Hmmm... spooky....

[Former Member · Accepted solution]

spooky indeed...

Yes, CBS caches sources to minimize data transfer between CBS and DTR. You can maybe find something locally in <CBS tempdir>\<buildspace id>\.CACHE\<dc id>\..., e.g. F:\cbstemp\94\.CACHE\1234\DCs\...

CBS should notice if the cache is not up-to-date but there was one bug with DTR where this failed, especially if there were integration conflicts. As ultimate weapon "init compartment" resolves the issue.

Marc

[Former Member · Accepted solution]

Is an 'init compartment' action non-destructive? I just want to make sure

I will certainly add this to my toolbox for later issues like this. For now, I'm not to worried about build issues since they generally seem to sort themselves out after a day or so. But, when I need to force a build, this will be good to know.