new name for sev-en

[Gerhard Petracek]

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

[Andrew Robinson-5]

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@...> 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

[Scott O'Bryan]

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@...> 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
>>    

[Gerhard Petracek]

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@...>:

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@...> 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

[Scott O'Bryan]

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@...> 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@...>:

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@...> 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 Saleh]

+1 for separated core jar.

On Thu, Apr 24, 2008 at 3:52 PM, Scott O'Bryan <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@...> 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@...>:

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@...> 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

[Gerhard Petracek]

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@...>:

+1 for separated core jar.

On Thu, Apr 24, 2008 at 3:52 PM, Scott O'Bryan <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@...> 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@...>:

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@...> 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

[Scott O'Bryan]

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

[Gerhard Petracek]

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 <darkarena@...>:

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

--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

[Jesse Alexander (KSFH 323)]

we are getting side-tracked...
let's find a name within this thread! :)

validation ?

->

myfaces-commons-validation

myfaces-commons-validation-annotations (was -validation)

myfaces-commons-validation-jsr303        (was bean-validation)

 

 

kind regards

Alexander