+1 for separated core jar. On Thu, Apr 24, 2008 at 3:52 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
> 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 >> > > -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
