BVal
  1. BVal
  2. BVAL-1

split usable validations like @Email from our impl

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: extras
    • Labels:
      None

      Description

      Currently there are a few very useful Validations included in the impl.

      Since they are in fact independent of the actual JSR-303 implementation, we should split them out into two own modules

      • validators-api which contains only the annotations and public stuff
      • validators-impl which contains the implementation stuff which are not needed at compile time (always used with <scope>runtime</scope>)

        Activity

        Hide
        Donald Woods added a comment -

        Not sure I follow what you're proposing....

        What exactly do we gain by splitting our implementation into a api and impl? There is a spec api that defines the API for anyone wanting to provide an impl, so doesn't that fit your idea of api vs. impl? Is there some OSGi specific packaging/best practices that you're wanting to follow?

        From a recent email thread about moving constraints - The spec defines constraints that all implementations must provide, but we can provide additional ones. Why would we move these out?

        Show
        Donald Woods added a comment - Not sure I follow what you're proposing.... What exactly do we gain by splitting our implementation into a api and impl? There is a spec api that defines the API for anyone wanting to provide an impl, so doesn't that fit your idea of api vs. impl? Is there some OSGi specific packaging/best practices that you're wanting to follow? From a recent email thread about moving constraints - The spec defines constraints that all implementations must provide, but we can provide additional ones. Why would we move these out?
        Hide
        Mark Struberg added a comment -

        > Why would we move these out?
        because the standard JSR-303 API will most probably be provided by the container (e.g. geronimo). So any non-standard validation must not be part of this package.

        Because, if you code your application and like to use the @Email (which is not part of the JSR-303 standard API afaik), then you would end up with not being portable.

        But if we split this additional functionality into an own api/impl jar (or a single 'extensions-impl.jar') then we would be perfectly portable. I assume that this 'extension-impl' only uses portable JSR-303 functions and will also run on other 303 implementations like Hibernate Validator.

        Show
        Mark Struberg added a comment - > Why would we move these out? because the standard JSR-303 API will most probably be provided by the container (e.g. geronimo). So any non-standard validation must not be part of this package. Because, if you code your application and like to use the @Email (which is not part of the JSR-303 standard API afaik), then you would end up with not being portable. But if we split this additional functionality into an own api/impl jar (or a single 'extensions-impl.jar') then we would be perfectly portable. I assume that this 'extension-impl' only uses portable JSR-303 functions and will also run on other 303 implementations like Hibernate Validator.
        Hide
        Donald Woods added a comment -

        OK, that makes sense. Any additional constraints would be defined in separate api/impl jars.

        Thought you were alluding to some grander reorg.

        Show
        Donald Woods added a comment - OK, that makes sense. Any additional constraints would be defined in separate api/impl jars. Thought you were alluding to some grander reorg.
        Hide
        Mark Struberg added a comment -

        No no, no big reorg

        It was only meant as a 'cleanup task'. I'm just not 100% sure if we can split the additional validator implementations so cleanly, or if they heavily reuse code from the core constraints. So maybe we have to 'dupe' some classes into this extensions-impl.jar for portability reasons.

        Show
        Mark Struberg added a comment - No no, no big reorg It was only meant as a 'cleanup task'. I'm just not 100% sure if we can split the additional validator implementations so cleanly, or if they heavily reuse code from the core constraints. So maybe we have to 'dupe' some classes into this extensions-impl.jar for portability reasons.
        Hide
        Roman Stumm added a comment -

        +1 from me

        The ONLY constraint validator implementation, that uses some code from the core module is EmailValidator.

        Show
        Roman Stumm added a comment - +1 from me The ONLY constraint validator implementation, that uses some code from the core module is EmailValidator.
        Hide
        Mark Struberg added a comment -

        remaining question is whether we like to do this in 1 jar or if we split API and impl into 2 jars.

        I've only glimpsed over the code and it looks to me that 1 single constraints.jar would be enough, since there are not so many impl classes needed actually.

        Show
        Mark Struberg added a comment - remaining question is whether we like to do this in 1 jar or if we split API and impl into 2 jars. I've only glimpsed over the code and it looks to me that 1 single constraints.jar would be enough, since there are not so many impl classes needed actually.
        Hide
        Roman Stumm added a comment -

        My opinion: into 1 single jar, because
        a) jar is small and users would most probably always need both if we would split
        b) we already have several jars, better less than more.
        Size of jar is less important than transitive dependencies, and there are no extra dependencies in the single jar anyway.

        Show
        Roman Stumm added a comment - My opinion: into 1 single jar, because a) jar is small and users would most probably always need both if we would split b) we already have several jars, better less than more. Size of jar is less important than transitive dependencies, and there are no extra dependencies in the single jar anyway.

          People

          • Assignee:
            Mark Struberg
            Reporter:
            Mark Struberg
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development