There is some info on the wiki (linked under "MyFaces Development" on the main page): http://wiki.apache.org/myfaces/Source_Code_Packaging
I am intermittently working to try to get the myfaces "support" modules (maven-archetypes, trinidad-build-plugin, myfaces-builder-plugin, shared) to have sites that are linked from the main page, and have a decent summary page. In particular, I want the builder plugin website available, with adequate docs, before we switch the trunk to the new build approach (which should be pretty soon now). Regards, Simon On Thu, 2008-05-22 at 06:27 -0600, Scott O'Bryan wrote: > 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 >
