myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From simon <simon.kitch...@chello.at>
Subject Re: shared source code within myfaces
Date Thu, 22 May 2008 12:36:51 GMT
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 <simon.kitching@chello.at 
> > <mailto:simon.kitching@chello.at>>:
> >
> >     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 <darkarena@gmail.com
> >     <mailto:darkarena@gmail.com>>:
> >     >         -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
> >     >         <gerhard.petracek@gmail.com
> >     <mailto:gerhard.petracek@gmail.com>> 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 
> 


Mime
View raw message