hello scott, ok - great to have an agreement!
i'm also fine with your "myfaces-commons-[projectName]" suggestion for the core. we definitely need test cases - also for other parts. i suggest to discuss such details later on. we are getting side-tracked... let's find a name within this thread! :) regards, gerhard 2008/4/24 Scott O'Bryan <[EMAIL PROTECTED]>: > That's fine. So it's looking like we still need a project name. I > suppose I agree with the: > > myfaces-commons-[projectName]-[module] format but with one exception. The > "core" should simply be myfaces-commons-[projectName]. So using the example > below, we would have: > > trunk > myfaces-commons-[projectName] > myfaces-commons-[projectName]-validation > myfaces-commons-[projectName]-bean-validation > > branch > 1.1 branch > myfaces-commons-[projectName] > > Are the validations and bean validations available for 1.1? If so, we > should also have a mechanism in the build scripts where we can compile and > test the validation and bean-validation packaged against the 1.1 code base > to ensure all the contracts are followed. > > Scott > > > Gerhard Petracek wrote: > > > hello, > > > > +1 for a separated core jar-file too! > > > > it isn't about what's possible or not... > > > > anyway, in my opinion we have to find a compromise. > > we will not find a solution everyone will completely agree on. > > > > the compromise: > > - core > > - validation (which provides our annotations - we can switch the name) > > - bean-validation (which provides the jsr 303 impl.) > > > > which means: > > > > - trunk: > > - core (for jsf 1.2) > > - validation > > - bean-validation > > > > - branch: > > - core (for jsf 1.1) and nothing else! > > > > regards, > > gerhard > > > > > > > > 2008/4/24 Hazem Saleh <[EMAIL PROTECTED] <mailto: > > [EMAIL PROTECTED]>>: > > > > +1 for separated core jar. > > > > > > On Thu, Apr 24, 2008 at 3:52 PM, Scott O'Bryan > > <[EMAIL PROTECTED] <mailto:[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] > > <mailto:[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] > > <mailto:[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] > > <mailto:[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 > > > > > > > > -- > > > > 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
