Just to make sure that we are talking about the same plug-ins: Are you using the jslint and checkstyle plug-in? Or are you using the violations plug-in?
My comments make only sense if you use the jslint plugin and then the checkstyle plugin;-) Ulli Am 17.01.2013 um 02:49 schrieb TeMc <mail.t...@gmail.com>: > > On Jan 16, 2013, at 6:31 PM, Ulli Hafner <ullrich.haf...@gmail.com> wrote: > >> >>> Why does the Checkstyle page viewer need the full paths? All it needs to do >>> is output the given file name (regardless of whether it exists or not) and >>> the warnings/errors for those files. >>> >>> If it wants to use the paths to display samples of the code, how does that >>> work for old builds? Files could have been moved by then, or Jenkins might >>> be installed in a different location etc. Unless it caches the samples >>> during the build this doesn't scale very well. >>> >> >> The checkstyle plug-in creates a copy for each file that contains a warning. >> If the file does not exist, then you just can't navigate to the source code >> - the rest of the plug-in should work without any problems… >> >> Ulli > > I don't care much about navigating the source code. > > All I want is to see the warnings that jshint outputted in the Checkstyle XML > file given to Jenkins via Violations. > > Right now all I see isa number and a couple of files with broken links. I > can't read the actual warnings (which is the whole point, otherwise I can > just have the output go to the console output and read the xml directly, I'm > using this plugin to visualise the data). > > I don't need it to do any fancy fetching of the files themselves, just read > the xml file and show each message for each file name. > > It shouldn't fall flat on its face just because it doesn't know how to > resolve the file name. Checkstyle reports don't need to have absolute or > (currently) existing file paths. All the information is right there in the > xml file. > > -- Tem >
