In JaxB, we need to move from one schema form to another and we would love to be able to deprecated stuff in the xsd with some simple note in the xsd:documentation element or something. Is there a way to get JAXB to mark these generated classes and methods with #Deprecated so developers can easily see which cold still needs to change?
thanks,
Dean
I would recommend the Annotate plugin: Annotate plugin(edit: the original link is no longer valid).
You'll see a couple of examples, including deprecation, warning suppression, etc.
It is usually recommended to do this stuff using special markup under appinfo as opposed to documentation.
I finally got all of mine working quite nicely...thanks!!!! The complete code is found here
JAXB External Custom Binding XJC Issue - Parsing results in empty node
Related
I was having difficulty with XJCTask so am using XJC2Task to generate Jaxb classes from xsd. What is the difference? Will the generated classes be different?
XJCTask delegates to JAXB1 or JAXB2 depending on what you have on your classpath.
If you are already using JAXB2 then you wont see any difference as it ends up calling the same thing.
You are unlikely to be using JAXB1 so you can just use XJC2Task.
See a related answer with more details https://stackoverflow.com/a/8863287/1000011
Seems that the /docbook-5.0/catalog.xml (XML catalog) found in the DocBook 5.0 zip ...
http://www.docbook.org/xml/5.0/docbook-5.0.zip
references a xsd/docbookxi.xsd schema file that seems to be missing from that archive.
Is this just a placeholder for some functionality that is yet to exist, or is this a legitimate error/bug/oversight in that catalog file?
Doing some google searching for docbookxi.xsd just turns up hundreds of references to this DocBook xml catalog reference, but no reference to the actual docbookxi.xsd file / definition.
Due to limitations in the environment i'm working with, I cannot use the alternative RELAX NG versions of this schema.
Yes, that's a legitimate bug. I don't actually recall if the toolchain that built the (awful) XSD versions was ever able to produce the XInclude version.
I can try to create an XInclude version of the "by hand" XSD files. However, that will be a version 1.1 XML Schema. Is that good enough, or do you need 1.0?
[Addendum]
After some investigation, it appears to me that the UPA rule in XSD makes creating an XInclude version enormously difficult. Simply allowing XInclude at either the division level (part or reference) and the component level (preface, chapter, et. al.) violates the UPA rule because a book can start with either a division or a component.
Perhaps http://docbook.org/xsd/5.0b2/docbook-xsd10.xsd or http://docbook.org/xsd/5.0b2/docbook.xsd is what you are looking for? Since the XSD schema documents for Docbook are now maintained by hand, it may well be that there are versions of the normative Relax NG schema for which no corresponding XSD schema document is provided.
Especially rich:autocomplete. There are a lot of possible attributes but not all of them are explained, neither in the Developers Guide nor in the Component Reference. For example there is no information about fetchValue, immediate, selecteditemClass,...
You need to check the Tag Library Documentation. Here is the <rich:autocomplete>.
What is the use of .# in groovy? Can anyone explain me with a code snippet?
Have you seen the official documentation? It contains nice code samples.
Essentially, when you use normal . operator, you access fields indirectly, using implicitly generated getters/setters. However, .# allows you to access the field directly, skipping getter/setter.
This can be useful when you want to avoid some additional logic implemented in getter/setter and change the field directly. Violates tons of OOP principles, but the authors of Groovy found this construct to be useful.
That's the Java Field operator (according to the documentation)
There are examples in the documentation.
It is also used for accessing attributes when you are parsing XML (again, there's an example if you follow that link).
I have an XSD that's going through a transition from one set of elements to another. During the transition, there'll be code expecting the new elements and code expecting the old elements. Therefore I need to keep the old elements in the XSD; I'm documenting them as deprecated (using free text in an xs:documentation element).
Is there a way of marking an element as deprecated such that a tool like xmllint will automatically warn if someone uses a deprecated element?
Create a new schema, with a new namespace. Call this "version 2". If you choose to support version 1 XSD and version 2 XSD in your application that's fine, but keep them seperate and don't try to layer the two on top of each other - especially if you're going try to stop people from using the version 1.
This is worth looking at as it describes some of what you're dealing with:
archive of http://www.pluralsight.com/community/blogs/tewald/archive/2006/04/19/22111.aspx
I realise, however, that doesn't really address your question. With regard to "is there a way to do this?" the answer is "no - not in a universally supported manner". I've seen people add their own doc annotations to give hints, but this isn't going to be universally understood by tooling.
Your best bet in the long run is to create come up with a versioning story for your schema(s) and keep version 2 seperate from version 1.