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]>:
>         -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]> 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

> 

Reply via email to