Community
Participate
Working Groups
Build Identifier: eclipse-SDK-I20110222-0800-win32.zip The "API Use Scans" preference page allows adding API use scans so they can be compared to the workspace to ensure that the API references still exist. The API use scans can be added as archives. However, whatever I tried I always got an error saying that my archive is invalid. I eventually looked into the code and found out that method "ApiUseScanPeferencePage.valditeArchive(File file)" requires the archive file(jar or zip) to have directory entries(which are not essential to the structure of a zip file). And it also requires a root directory which starts with "xml" which seemed odd to me. The last part appears to be related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=338488. I think there are two problems here: 1. Requiring directory zip entries. 2. Requiring entries to start with "xml". Reproducible: Always
As with bug 338488 this check should either be removed (if the actual use scan analysis does not require the xml folder) or the user should be told why it is not valid. Some of the directory structure is necessary for a use scan to be parsed.
We can remove the constraint that the directory name should be "XML". However, the directory structure is integral part of a use scan. Currently, the preference page follows these rules already. We will fix the builder to only look for matching directory structure. Peter, please confirm. Will this be good for you?
From Bug # 338488 Copying here so that it can be tracked in one place "Build Identifier: eclipse-SDK-I20110222-0800-win32.zip The "API Use Scans" preference allows adding API use scans so they can be compared to the workspace to ensure the API references still exist. I ran into the following problem when I tried it out. My scan report location was accepted as valid in the preference page dialog. However, the API analysis builder didn't report the errors I expected it to report. I spend some time trying to figure why. Eventually, I looked into the source code and found out that at run time, the "UseScanManager.getExactScanLocation()" method looks for a parent "xml" directory and if this directory is not there, it silently interrupts the scan so there is not way to figure out why it didn't produce the expected results. I don't understand why is there a requirement the scan report's parent directory to be named "xml". And second, if this is a needed requirement, I think there should be a prominent error displayed, and probably at the time the location is added and validated. Reproducible: Always"
*** Bug 338488 has been marked as a duplicate of this bug. ***
Created attachment 193535 [details] Patch for comment 2 The patch makes builder not to look for 'xml' folder. instead the logic is now like this 1. Check the location for directory structure, if it matches, use it (location) 2. if not, does it has an 'xml' sub-folder? if so...use it if it has matching directory structure 3. if not, look for children, if there is only one and it has matching directory structure ...use that as location. This should give a fair flexibility and yet enforce the use scan structure.
Testing the patch I found that I am unable to add an archive that does not contain a root 'xml' folder, I think the patch should include the fix for that as well.
Created attachment 193766 [details] Updated Patch 1. removes validation checks from archives when they are added 2. fixed the regex 3. builder will report invalid use scan locations/archives 4. the folder name 'xml' not mandatory any more
Fixed in HEAD
I updated the fix a bit, because with the last patch I still could not add an archive that did not have a root 'xml' entry. I also removed some duplicate code from the preference page. > 3. builder will report invalid use scan locations/archives Where is this capability? You cannot leave the preference page with a bad scan location, so I don't see how it would build. Or maybe I missed something?
(In reply to comment #9) > Where is this capability? You cannot leave the preference page with a bad scan > location, so I don't see how it would build. Or maybe I missed something? Ahh I see, the builder does not report a problem, the use scan manager throws an exception when it tries to fetch a location that is bogus, which results in a log entry rather than a reported builder problem.
remarking as fixed, with the last updates I can add archives and locations that do not contain a root 'xml' directory.
