+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]>: > 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 > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
