hello scott, there might be fewer jar-files. i know what you mean. that's one of several reasons why i suggested an own sub-project. at least there should be 3 jar-files: - core - a separated annotation module for our annotations - a separated module for jsr 303
there will be other jsr 303 impl. out there. so users are free to choose the impl. they prefer. + if they choose an other impl. of jsr 303, they can use sev-en for the rest (= our annotations and/or custom annotations). (+ maybe we will need a sandbox module.) we could use one jar-file (instead of two) for validation and cross-validation. there are advantages and also disadvantages to do that. @jsr 303 within the name: that's ok for me. i also thought about it. so we have to differ within the version number. if there will be other jsr's about bean validation, we might need further jar-files. i don't know how compatible future versions of the bean validation jsr will be. so users are free to choose which jsr they would like to use. it's just the question if we indicate the jsr version with the name or the version number. maybe there will be a jsr303-api jar-file which contains javax.annotation.[...] (comparable to jsr 250). that's the reason i also thought about an indication within the name. however, i'm also ok with your suggestion. @1.1 branch: that's true - nevertheless there will be two different cores. even though one of it is within the branch. regards, gerhard 2008/4/24 Scott O'Bryan <[EMAIL PROTECTED]>: > Couple of things. > Can any of this be consolidated into fewer jars? I'm worried that the > jars in the commons project are starting to look TOO segmented and > functionality that is similar is not being put into a common jar. I haven't > had time to take a look at Sev-en, but provided the framework does not > "automatically" add significant overhead to the processing of the lifecycle, > there should be no issues if it exists, unused, in the classpath.. We have > several options here, the code could live in the validators or, if people > feel it will add significant overhead or dependencies, maybe one other > project. > > As for the JSR-303, I strongly suggest AGAINST using the JSR number in > your project name.. Why? When this spec gets updated, a new JSR will be > created and then your jar has no reflection on reality because my guess it > you wouldn't necessarily want to change it. Instead you might just want to > call it "bean-validation". > > Lastly, the commons project trunk is JSF 1.2, I think Matthias has a 1.1 > branch and things are backported as needed. I would essentially put your > 1.1 work into that branch so it can be versioned with the rest of the 1.1 > commons projects. > > Other then that, like Andrew, I've got enough on my plate ATM... > > Scott > > > Andrew Robinson wrote: > > > Sounds like fun, but I've already put enough on my plate :) Perhaps in > > the future. > > > > On Wed, Apr 23, 2008 at 4:45 PM, Gerhard Petracek > > <[EMAIL PROTECTED]> wrote: > > > > > > > hello, > > > > > > 'sev-en' is just the intermediate (code-)name -> let's find a final > > > name. > > > > > > there will be some modules within commons-[new name] (which means > > > several > > > jar files). > > > > > > e.g.: > > > > > > required to use sev-en: > > > commons-[new name]-core (currently one for jsf 1.1 and one for jsf > > > 1.2) > > > > > > optional: > > > commons-[new name]-validation (annotations + validation strategies,... > > > and > > > also the validation strategy to support jpa validation) > > > commons-[new name]-crossvalidation (annotations + validation > > > strategies, > > > ...) > > > commons-[new name]-jsr303 (validation strategies to support jsr 303, > > > ...) > > > > > > are there volunteers to join the development? > > > > > > regards, > > > gerhard > > > > > > -- > > > > > > http://www.irian.at > > > > > > Your JSF powerhouse - > > > JSF Consulting, Development and > > > Courses in English and German > > > > > > Professional Support for Apache MyFaces > > > > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
