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
