True, but frankly when it comes to things in the core, we are somewhat
limited. And I'm not a big fan of using the core impl. Have you
uploaded your patch? Maybe we can all review it.
Scott
Gerhard Petracek wrote:
i see your point.
there are some pros and cons!
concerning the example you mentioned:
only because we already have such a situation within the code base it
isn't a legitimation to continue with this approach. (we need at least
a discussion.)
in the end we might have several parts which are "acceptable" to
duplicate. -> -1 for such an approach (if there are/will be too many
duplicate parts).
however, maybe there is a different approach!
regards,
gerhard
2008/5/22 Scott O'Bryan <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
-1 Myfaces commons utils is not the place for this. MyFaces core
should not have to depend on the commons project to run. Plus the
myfaces commons utils is a snapshot and not going to release any
time soon. Making Trinidad dependent on this package would mean
we can't release util the commons utils does.
I don't like duping code either, but Trinidad added a bunch of
duped code from MyFaces for it's configurators, so there is a
prescidence. IMO, duplicating a small amount of code is
preferable to adding at least 3 jar dependencies and making the
core dependent on a util library.
Scott
On Wed, May 21, 2008 at 3:35 PM, Gerhard Petracek
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
hello,
for the patches of TRINIDAD-1088 i used the source code of the
myfaces state manager to detect duplicate component id's.
i don't like to have duplicate source code!
what's your opinion about moving all shared source code like
this to a 'commons' module like the already existing
myfaces-commons-utils?
regards,
gerhard
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
