I was aware of the "shared" module, but I must admit that I'm not
exactly sure how it's used or how it benefits us in this case. Is there
a wiki I can look at or should I go digging in the shared projects?
Scott
Gerhard Petracek wrote:
+1 for the "shared" module.
it would be my second question to use it.
the reason for choosing commons as the first one was:
if we have stable common source code within a separated module also
other external extensions, projects, ... could use it.
(it isn't that important for state manages. but there are also some
other useful parts.)
however, as i said - i also see the disadvantages.
anyway, for me the most important issue is not to have more and more
redundant source code.
regards,
gerhard
2008/5/22 simon <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
Using a "commons" module for things like this reintroduces exactly the
problem that the "shared" module was created to solve:
(a) fundamental projects (core, trinidad) would then depend on an
extra
jar
(b) placing code shared between projects into a normal jar means that
upgrading one project may force the shared jar to be updated,
which can
break the other project - unless we enforce 100% binary and semantic
compatibility between releases of that jar.
The "import and rename" approach of the myfaces-shared project solves
both (a) and (b).
Possibly we could move the state manager code from myfaces 1.2
into the
myfaces-shared project, and then Trinidad could use myfaces-shared
like
the other projects do. Would that solve your problem?
A while ago, Mario proposed moving the StateManager stuff into the
myfaces-shared module so that Orchestra could offer its own custom
StateManager variant that stored state within the current conversation
context for multi-window-support. So it seems generally useful to have
at least the basics of a StateManager implementation in shared.
Regards,
Simon
On Thu, 2008-05-22 at 01:00 +0200, 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
