You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bval.apache.org by "Roman Stumm (JIRA)" <ji...@apache.org> on 2010/06/15 15:03:22 UTC
[jira] Created: (BVAL-69) make dependency to
com.thoughtworks.xstream of bval-core optional or obsolete
make dependency to com.thoughtworks.xstream of bval-core optional or obsolete
-----------------------------------------------------------------------------
Key: BVAL-69
URL: https://issues.apache.org/jira/browse/BVAL-69
Project: BeanValidation
Issue Type: Improvement
Components: jsr303
Affects Versions: 0.2-incubating
Reporter: Roman Stumm
currently bval-core needs xstream to compile, although xstream is NOT used to marshal XML when working with bval-jsr303 xml-descriptors. Only proprietary xml-support in bval-core uses xstream.
To minimize the number of different XML-frameworks (bval-jsr303 has a dependency to jaxb, which is OK, because this is part of the JDK) and to minimize the number of dependencies in general, we should refactor the core-classes to get rid of the mandatory xstream dependency.
A first simple way would be to remove all XStream annotation in org.apache.bval.xml and instead use the programmatic API of XStream to define the mapping and move the xstream-dependent code to a new optional mvn-module.
Another way could be to change the code from using XStream to using jaxb or to remove the code (if we do not want to keep the proprietary functionality, which is not required for the jsr303 features)
Any other ideas??
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (BVAL-69) make dependency to
com.thoughtworks.xstream of bval-core optional or obsolete
Posted by "Roman Stumm (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BVAL-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on BVAL-69 started by Roman Stumm.
> make dependency to com.thoughtworks.xstream of bval-core optional or obsolete
> -----------------------------------------------------------------------------
>
> Key: BVAL-69
> URL: https://issues.apache.org/jira/browse/BVAL-69
> Project: BeanValidation
> Issue Type: Improvement
> Components: jsr303
> Affects Versions: 0.2-incubating
> Reporter: Roman Stumm
> Assignee: Roman Stumm
>
> currently bval-core needs xstream to compile, although xstream is NOT used to marshal XML when working with bval-jsr303 xml-descriptors. Only proprietary xml-support in bval-core uses xstream.
> To minimize the number of different XML-frameworks (bval-jsr303 has a dependency to jaxb, which is OK, because this is part of the JDK) and to minimize the number of dependencies in general, we should refactor the core-classes to get rid of the mandatory xstream dependency.
> A first simple way would be to remove all XStream annotation in org.apache.bval.xml and instead use the programmatic API of XStream to define the mapping and move the xstream-dependent code to a new optional mvn-module.
> Another way could be to change the code from using XStream to using jaxb or to remove the code (if we do not want to keep the proprietary functionality, which is not required for the jsr303 features)
> Any other ideas??
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (BVAL-69) make dependency to
com.thoughtworks.xstream of bval-core optional or obsolete
Posted by "Roman Stumm (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BVAL-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roman Stumm reassigned BVAL-69:
-------------------------------
Assignee: Roman Stumm
> make dependency to com.thoughtworks.xstream of bval-core optional or obsolete
> -----------------------------------------------------------------------------
>
> Key: BVAL-69
> URL: https://issues.apache.org/jira/browse/BVAL-69
> Project: BeanValidation
> Issue Type: Improvement
> Components: jsr303
> Affects Versions: 0.2-incubating
> Reporter: Roman Stumm
> Assignee: Roman Stumm
>
> currently bval-core needs xstream to compile, although xstream is NOT used to marshal XML when working with bval-jsr303 xml-descriptors. Only proprietary xml-support in bval-core uses xstream.
> To minimize the number of different XML-frameworks (bval-jsr303 has a dependency to jaxb, which is OK, because this is part of the JDK) and to minimize the number of dependencies in general, we should refactor the core-classes to get rid of the mandatory xstream dependency.
> A first simple way would be to remove all XStream annotation in org.apache.bval.xml and instead use the programmatic API of XStream to define the mapping and move the xstream-dependent code to a new optional mvn-module.
> Another way could be to change the code from using XStream to using jaxb or to remove the code (if we do not want to keep the proprietary functionality, which is not required for the jsr303 features)
> Any other ideas??
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BVAL-69) make dependency to
com.thoughtworks.xstream of bval-core optional or obsolete
Posted by "Roman Stumm (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BVAL-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880079#action_12880079 ]
Roman Stumm commented on BVAL-69:
---------------------------------
I suggest moving the XSteam-dependent code from core to a new sub-module bval-xstream.
I am already working on this and it seems, that the remaining core becomes very small.
Taking into account what Carlos wrote:
"- There are several parts of the code in the jsr303 module that could be
made more concise/clean if they were separated from the core
superclasses/dependencies. This would be similar to the issue in BVAL-47.
Two other good examples that come to my mind are
GroupValidationContext/BeanValidationContext and
ConstraintValidationListener. The warning reported by findbugs in
ConstraintValidatorListener also illustrates this."
and
"f the objective of the project is determined to be more in the
line of being a jsr303 impl, I think we could gain code clarity and reduce
complexity by moving the needed code from core to the jsr303 part and
dropping the dependency. This would also probably make it easier for new
people to contribute."
This could be a first step to get rid of the core-module at all by first shrinking it to the absolute minimum. We can later decide what to do with the rest: unify it with the jsr303 module or keep it. This mainly depends on the value the community gives to the proprietary features of the core- and xstream- parts.
In my opinion, the core frameworks offers some very flexible possiblities to store, merge and transport metadata of classes, that we used for providing type and meta-data information via json to an AJAX app. But for a jsr303-validation features some parts are not required.
> make dependency to com.thoughtworks.xstream of bval-core optional or obsolete
> -----------------------------------------------------------------------------
>
> Key: BVAL-69
> URL: https://issues.apache.org/jira/browse/BVAL-69
> Project: BeanValidation
> Issue Type: Improvement
> Components: jsr303
> Affects Versions: 0.2-incubating
> Reporter: Roman Stumm
> Assignee: Roman Stumm
>
> currently bval-core needs xstream to compile, although xstream is NOT used to marshal XML when working with bval-jsr303 xml-descriptors. Only proprietary xml-support in bval-core uses xstream.
> To minimize the number of different XML-frameworks (bval-jsr303 has a dependency to jaxb, which is OK, because this is part of the JDK) and to minimize the number of dependencies in general, we should refactor the core-classes to get rid of the mandatory xstream dependency.
> A first simple way would be to remove all XStream annotation in org.apache.bval.xml and instead use the programmatic API of XStream to define the mapping and move the xstream-dependent code to a new optional mvn-module.
> Another way could be to change the code from using XStream to using jaxb or to remove the code (if we do not want to keep the proprietary functionality, which is not required for the jsr303 features)
> Any other ideas??
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BVAL-69) make dependency to
com.thoughtworks.xstream of bval-core optional or obsolete
Posted by "Roman Stumm (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BVAL-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roman Stumm resolved BVAL-69.
-----------------------------
Fix Version/s: 0.2-incubating
Resolution: Fixed
If you set ApacheValidatorConfiguration.Properties.ENABLE_METABEANS_XML="true" the xstream module and jsr303 can be used together.
otherweise you dont need the xstream module and thus the jsr303 and the core modules have less dependencies.
> make dependency to com.thoughtworks.xstream of bval-core optional or obsolete
> -----------------------------------------------------------------------------
>
> Key: BVAL-69
> URL: https://issues.apache.org/jira/browse/BVAL-69
> Project: BeanValidation
> Issue Type: Improvement
> Components: jsr303
> Affects Versions: 0.2-incubating
> Reporter: Roman Stumm
> Assignee: Roman Stumm
> Fix For: 0.2-incubating
>
>
> currently bval-core needs xstream to compile, although xstream is NOT used to marshal XML when working with bval-jsr303 xml-descriptors. Only proprietary xml-support in bval-core uses xstream.
> To minimize the number of different XML-frameworks (bval-jsr303 has a dependency to jaxb, which is OK, because this is part of the JDK) and to minimize the number of dependencies in general, we should refactor the core-classes to get rid of the mandatory xstream dependency.
> A first simple way would be to remove all XStream annotation in org.apache.bval.xml and instead use the programmatic API of XStream to define the mapping and move the xstream-dependent code to a new optional mvn-module.
> Another way could be to change the code from using XStream to using jaxb or to remove the code (if we do not want to keep the proprietary functionality, which is not required for the jsr303 features)
> Any other ideas??
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BVAL-69) make dependency to
com.thoughtworks.xstream of bval-core optional or obsolete
Posted by "Donald Woods (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BVAL-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878976#action_12878976 ]
Donald Woods commented on BVAL-69:
----------------------------------
I'd vote for moving it to an optional module for now, which gives us options down the road (either moving it to JAXB or dropping the support.)
> make dependency to com.thoughtworks.xstream of bval-core optional or obsolete
> -----------------------------------------------------------------------------
>
> Key: BVAL-69
> URL: https://issues.apache.org/jira/browse/BVAL-69
> Project: BeanValidation
> Issue Type: Improvement
> Components: jsr303
> Affects Versions: 0.2-incubating
> Reporter: Roman Stumm
>
> currently bval-core needs xstream to compile, although xstream is NOT used to marshal XML when working with bval-jsr303 xml-descriptors. Only proprietary xml-support in bval-core uses xstream.
> To minimize the number of different XML-frameworks (bval-jsr303 has a dependency to jaxb, which is OK, because this is part of the JDK) and to minimize the number of dependencies in general, we should refactor the core-classes to get rid of the mandatory xstream dependency.
> A first simple way would be to remove all XStream annotation in org.apache.bval.xml and instead use the programmatic API of XStream to define the mapping and move the xstream-dependent code to a new optional mvn-module.
> Another way could be to change the code from using XStream to using jaxb or to remove the code (if we do not want to keep the proprietary functionality, which is not required for the jsr303 features)
> Any other ideas??
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BVAL-69) make dependency to
com.thoughtworks.xstream of bval-core optional or obsolete
Posted by "Donald Woods (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BVAL-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880307#action_12880307 ]
Donald Woods commented on BVAL-69:
----------------------------------
I think we need to also fix some package names, as bval-xstream provides classes in o.a.bval.routines and o.a.bval.xml, while bval-core provides some classes in o.a.bval.routines also. It's not critical right now, since bval-xstream is not a bundle, but for proper packaging best practices, we should clean this up....
> make dependency to com.thoughtworks.xstream of bval-core optional or obsolete
> -----------------------------------------------------------------------------
>
> Key: BVAL-69
> URL: https://issues.apache.org/jira/browse/BVAL-69
> Project: BeanValidation
> Issue Type: Improvement
> Components: jsr303
> Affects Versions: 0.2-incubating
> Reporter: Roman Stumm
> Assignee: Roman Stumm
> Fix For: 0.2-incubating
>
>
> currently bval-core needs xstream to compile, although xstream is NOT used to marshal XML when working with bval-jsr303 xml-descriptors. Only proprietary xml-support in bval-core uses xstream.
> To minimize the number of different XML-frameworks (bval-jsr303 has a dependency to jaxb, which is OK, because this is part of the JDK) and to minimize the number of dependencies in general, we should refactor the core-classes to get rid of the mandatory xstream dependency.
> A first simple way would be to remove all XStream annotation in org.apache.bval.xml and instead use the programmatic API of XStream to define the mapping and move the xstream-dependent code to a new optional mvn-module.
> Another way could be to change the code from using XStream to using jaxb or to remove the code (if we do not want to keep the proprietary functionality, which is not required for the jsr303 features)
> Any other ideas??
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.