I guess I'm wondering if *core* and the annotations couldn't be in the same jar.
I suppose the JSR-303 jar is fine. As for the naming of the JSR-303 jar, if a new JSR modifies an existing spec, I needs to b e backward compatible. So yeah, just having a later version of your same Jar should suffice for most projects. Some oddities between JSF11 and JSF12 notwithstanding. :) On Thu, Apr 24, 2008 at 12:27 AM, Gerhard Petracek < [EMAIL PROTECTED]> wrote: > 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 >
