Closed romixch closed 8 years ago
Agree - the scanner should be robust to handle this case gracefully. Just a question: which jQA version did you use?
Oh. I forgot to mention: I used the latest version 1.1.2. It is a really great tool. Hope to use it much more often.
Interesting use case. I think it wasn't a good decision to allow empty XML files. But it is as it is.
Handling an empty bean descriptor file is easy if we treat it only as bean descriptor file. But jQAssistant treats the file also a XML document. Here we could have the situation to have an invalid XML document but to have a valid bean descriptor.
According to the XML 1.1 specification a document is well formed (we use also the term valid) if it contains a least one element.
Difficult to handle. In case of an empty file the extension .xml
to can not label it as XML document because there is no XML document. And a non-existing XML document is neither well-formed or nor it is not well-formed.
In case of an bean descriptor file with a valid XML document we must label it also with XML
because is an XML document.
We must discuss this. There is no just on line
solution.
I was also a bit concerned when I first saw that the spec allows empty XML files... (AFAIK this approach has its origin in JBoss Seam where empty property files were used as marker)
I see two options for an empty beans.xml:
I'd prefer the first option - if a file has the extension .xml and has a defined schema then it should carry that label - even if it's not well-formed nor valid. any opinions on that?
Actually I think there are two issues:
For the first issue I think of following solution: Empty beans.xml: Mark as containing a beans descriptor. Don't add any xml specific information beans.xml with valid content: Mark as containing a beans descriptor. Add some xml specific information beans.xml with invalid content: Mark as containing a beans descriptor. Don't add any xml specific information.
For the second issue I think of this: Don't break the whole process if a ScannerPlugin fails to scan a file. This behaviour always leads to trouble. You can be more relaxed if the scan still finishes but some information is missing for a particular broken plugin.
At the end of this month I could help with some pull requests. You can then still reject them :-)
I would go for option 2. Why? Because there is no XML document and therefore it can't be not well-formed.
@romixch The latest snapshot of the jQA distribution contains a first fix for the empty beans.xml, you can get it from https://oss.sonatype.org/content/repositories/snapshots/com/buschmais/jqassistant/distribution/jqassistant.distribution/1.1.3-SNAPSHOT/ Can you verify if it works for you?
This is great! I will test this as soon as possible. Thanks.
@romixch Just in case that you run into another unexpected issue - you can also trigger the scan with
jqassistant.sh scan maven:repository::http://... -continueOnError
If an error occurs (which I hope this won't be the case) please report it :-)
@romixch We'd like to finish 1.1.3 - is it ok for you if we close this issue?
Yes. I tried it with my repository. It only crashed as I run out of local disk space. Seams to work. Thank you for your work!
Thanks for your feedback and have a nice weekend!
I tried to scan a nexus repository, which failed at following point:
It is totally legal to have a completely empty beans.xml according to this tutorial from Oracle: Configuring a CDI Application. Therefore I think this should be fixed. Anyway I think the scanner should be tolerant to broken files in a maven repository. In the worst case it should not read the file, write a warning and go on with the next file.