Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: neutral (nike.apache.org: 141.146.126.228 is neither permitted
 nor denied by domain of darkarena@gmail.com)
Message-ID: <483566AA.4070406@gmail.com>
Date: Thu, 22 May 2008 06:27:22 -0600
From: "Scott O'Bryan" <darkarena@gmail.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: MyFaces Development <dev@myfaces.apache.org>
Subject: Re: shared source code within myfaces
References: <2332f63b0805211435q1c71dd78s8661ddf187ef072e@mail.gmail.com>
	 <323d8a020805211509y26ab74bek82fa87a481bc0b4c@mail.gmail.com>
	 <2332f63b0805211600i5dd09bfela3ab9e7271b64de3@mail.gmail.com>
	 <1211449749.6269.8.camel@simon-laptop>
 <2332f63b0805220306u439a964ald5c87fe39091b59@mail.gmail.com>
In-Reply-To: <2332f63b0805220306u439a964ald5c87fe39091b59@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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