[
https://jira.codehaus.org/browse/MJAXB-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288228#comment-288228
]
Lennart Jörelid edited comment on MJAXB-55 at 1/14/12 2:41 AM:
---------------------------------------------------------------
{quote} Could you use xmlunit to compare xml documents? I've already added the
dependency.
My problem is
org.codehaus.mojo.jaxb2.helpers.SchemagenHelperTest.validateProcessingNodes()
which seems to fail when using assertXMLEqual( changedDocument, document )
{quote}
Added and fixed, with a few caveats:
* We might ask the XMLUnit folks to publish their source code on the maven
repo1.
At the moment, one has to download the source manually to debug
XMLUnit classes, which seems unnecessarily inconvenient.
* The error/diff printouts in XMLUnit Diffs (or DetailedDiffs) WRT namespace
inconsistencies
felt really confusing. This is most likely what tripped yourself.
{quote} TransformSchema should be a pojo, so return the toFile as is. {quote}
TransformSchema *is* a pojo, with some smarts in one getter aimed at saving
unnecessary
typing in the configuration. I suggest we leave it as it is.
{quote} The validator is too strict. People can use expressions for certain
values, which can be empty.
Don't throw an exception, just skip it. {quote}
In the case of a schema transformation, we need at least 2 configuration
properties with
non-empty values - namespace URL and either toPrefix or toFile. Any
schemagen configuration
not complying with this rule is incorrect, irrespective of how the incorrect
configuration
was generated.
The question, then, is "how do we handle incorrect plugin configuration".
My answer is clear, and different from your suggestion:
{noformat} Plugins given incorrect configuration should not try to "enhance"
or "correct" the configuration by guessing what should be appropriate in the
general case.
Instead, all plugins should fail with an exception message clearly describing
what was wrong and how to correct the problem. Plugins can otherwise cause big
problems for larger real-life projects (in an example from real life, around
400 maven projects combine to create one enterprise application) where some
incorrect plugin configuration can generate major problems while being quite
hard to identify/detect.{noformat}
The method to rectify such difficult-to-detect build problems is that each
plugin throws exceptions as described above.
Therefore, I disagree that the validator is too strict.
Let us release the plugin with exactly the provided level of assistance to
the users.
{quote} Add a workDirectory, where the schemaN.xsd can be placed.
From here the mojo can pick them up, transform it a write them to the
outputDirectory.{quote}
Done.
{quote} Add yourself as contributer in the pom {quote}
Done. Also, please do not remove the cobertura inclusion within the pom.
We need our coverage report.
was (Author: [email protected]):
a) Could you use xmlunit to compare xml documents? I've already added the
dependency.
My problem is
org.codehaus.mojo.jaxb2.helpers.SchemagenHelperTest.validateProcessingNodes()
which seems to fail when using assertXMLEqual( changedDocument, document )
Added and fixed. We might ask the XMLUnit folks to publish their source code
on
the maven repo1. At the moment, one has to download the source manually to
debug
XMLUnit classes, which seems unnecessarily inconvenient. Also, the
error/diff printouts
in XMLUnit Diffs (or DetailedDiffs) WRT namespace inconsistencies felt
really confusing.
b) TransformSchema should be a pojo, so return the toFile as is.
TransformSchema is a pojo, with some smarts in one getter aimed at saving
unnecessary
typing in the configuration. I suggest we leave it as it is.
c) The validator is too strict. People can use expressions for certain values,
which can be empty.
Don't throw an exception, just skip it.
In the case of a schema transformation, we need at least 2 configuration
properties with
non-empty values - namespace URL and either toPrefix or toFile. Any
schemagen configuration
not complying with this rule is incorrect, irrespective of how the incorrect
configuration
was generated.
The question, then, is "how do we handle incorrect plugin configuration".
My answer is clear, and different from your suggestion:
Plugins given incorrect configuration should not try to "enhance" or
"correct"
the configuration. Instead, all plugins should fail with an exception message
clearly describing what was wrong and how to correct the problem. Plugins
can
otherwise cause big problems for larger real-life projects (in an example
from
real life, around 400 maven projects combine to create one enterprise
application)
where some incorrect plugin configuration can generate major problems.
Therefore, I disagree that the validator is too strict.
Let us release the plugin with exactly the provided level of assistance to
the users.
d) Add a workDirectory, where the schemaN.xsd can be placed.
From here the mojo can pick them up, transform it a write them to the
outputDirectory.
Done.
e) Add yourself as contributer in the pom
Done. Also, please do not remove the cobertura inclusion within the pom.
We need our coverage report.
> Provide means to set the file name of generated XML schema
> ----------------------------------------------------------
>
> Key: MJAXB-55
> URL: https://jira.codehaus.org/browse/MJAXB-55
> Project: Maven 2.x JAXB 2.1 Plugin
> Issue Type: New Feature
> Affects Versions: 1.3.1
> Environment: All
> Reporter: Lennart Jörelid
> Assignee: Robert Scholte
> Attachments: diagramAdditions_1.png, fileRenamePatch_v14.txt
>
>
> AbstractSchemagenMojo sneakily hard-codes the resulting filename for the
> generated schema file.
> This should really be configurable; provided a parameter to set the resulting
> file name, as well as an integration test.
> For reasons of somewhat misguided backwards compatibility, I set the default
> value of the parameter to its currently hardcoded value, "schema1.xsd".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
