|
»
»
»
« Return to Thread: new name for sev-en
Re: new name for sev-en
by Scott O'Bryan
::
Rate this Message:
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 <hazem.saleh@...
> <mailto:hazem.saleh@...>>:
>
> +1 for separated core jar.
>
>
> On Thu, Apr 24, 2008 at 3:52 PM, Scott O'Bryan
> <darkarena@... <mailto:darkarena@...>> 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
> <gerhard.petracek@...
> <mailto:gerhard.petracek@...>> 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 <darkarena@...
> <mailto:darkarena@...>>:
>
> 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
> <gerhard.petracek@...
> <mailto:gerhard.petracek@...>> 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
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 <hazem.saleh@...
> <mailto:hazem.saleh@...>>:
>
> +1 for separated core jar.
>
>
> On Thu, Apr 24, 2008 at 3:52 PM, Scott O'Bryan
> <darkarena@... <mailto:darkarena@...>> 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
> <gerhard.petracek@...
> <mailto:gerhard.petracek@...>> 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 <darkarena@...
> <mailto:darkarena@...>>:
>
> 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
> <gerhard.petracek@...
> <mailto:gerhard.petracek@...>> 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
« Return to Thread: new name for sev-en
| Free Forum Powered by Nabble | Forum Help |