BVal
  1. BVal
  2. BVAL-69

make dependency to com.thoughtworks.xstream of bval-core optional or obsolete

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.2-incubating
    • Fix Version/s: 0.2-incubating
    • Component/s: jsr303
    • Labels:
      None

      Description

      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??

        Activity

        Hide
        Donald Woods added a comment -

        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.)

        Show
        Donald Woods added a comment - 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.)
        Hide
        Roman Stumm added a comment -

        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.

        Show
        Roman Stumm added a comment - 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.
        Hide
        Roman Stumm added a comment -

        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.

        Show
        Roman Stumm added a comment - 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.
        Hide
        Donald Woods added a comment -

        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....

        Show
        Donald Woods added a comment - 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....

          People

          • Assignee:
            Roman Stumm
            Reporter:
            Roman Stumm
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development