[ https://issues.jboss.org/browse/SHRINKDESC-130?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKDESC-130: -------------------------------------------- Sync progress in: https://github.com/shrinkwrap/descriptors/tree/SHRINKDESC-130 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKDESC-130?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-130: -------------------------------------------- Thanks for your comment. My answers are: 1+2) Probably I didn't pointed out that this class was my play ground for evaluating all available parser frameworks and serialization tools. This class will never be part of the version I finally will make a pull request. But you are right, I should note that somehow better. 3) I will review it today or tomorrow 4) Hmm, that is exactly the behaviour when the (default) entity resolver makes http calls to the internet for downloading one or more missing XSDs. It should be around 0.5s max... I will check this as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKDESC-130?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKDESC-130: -------------------------------------------- Instead of looking in a particular JAR, should access the XSD from a visible ClassLoader. If both JARs are visible to the same ClassLoader, why should it matter the location? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKDESC-130?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-130: -------------------------------------------- Some proposals -------------- The current schema-validator is currently a standalone feature and is not integrated into the metadata-parser plugin. It supports all schemas which are located in the gen module. The usage is: final XmlValidator validator = new XmlValidator(SchemaType.XSD); validator.loadGrammar("application_6.xsd"); validator.validate("src/test/resources/test-invalid-application-6.xml"); You can see that the user has to give the top level descriptor XSD and in addition, to specify a XML file to validate against. Proposal: We could simplify this by doing this: 1) add a flag in the descriptor section of the metada-plugin for each specified XSD: <keepAsResource>true</keepAsResource> 2) if true, the the metadata-plugin copies the XSD into the impl package 3) the source code generater add then a method validate() for each descriptor. This method executes the validation as described above by knowing all the details. What you think? May you want to integrate it this into the SPI level and not directly into the generated descriptors. Let me know your view on this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKDESC-130?page=com.atlassian.jira.pl... ] Dan Allen commented on SHRINKDESC-130: -------------------------------------- Ralf, Overall, the APIs are looking great! I reviewed the facesconfig20 test and I have some comments/suggestions. * The Web prefix on WebFacesConfigDescriptor seems odd to me. I see that you are getting it from the web- prefix on the basename of the XSD URL, but I would consider putting a filter in place for that, esp given these are well known descriptors and we want them to be just right. * Rather than up(), I'd much prefer something that's more DOM-like, such as parentNode(), parent(), or toParent(). up() just doesn't feel right. ** Also consider having an ancestorNode(int) that will jump multiple levels of ancestry to avoid parentNode().parentNode().parentNode() * The "getOrCreate" really doesn't sit well with me. I would much prefer define*() and define*(boolean) where a boolean of true indicates to force create it if it already exists. If you still like create, I would suggest as a second choice create*() and create*(true) w/ the same semantics. Here's an example of how the define would look, taking from the facesconfig example: {code} .defineNavigationRule(true) .fromViewId("*") .defineNavigationCase() .fromAction("#{identity.logout}") ._if("#{true}") .toViewId("/home.xhtml") .defineRedirect() .parentNode() .parentNode() .defineNavigationCase() .fromAction("#{bookingAgent.cancel}") ._if("#{true}") .toViewId("/search.xhtml") .defineRedirect() .parentNode() .parentNode() .parentNode() .parentNode() {code} Keep up the great work! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKDESC-130?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-130: -------------------------------------------- I'd like your ideas. I also think that we should make the API more user friendly. @Andrew, shall we include this with SD-21 or as a separate JIRA? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira