You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@myfaces.apache.org by John Fallows <jo...@gmail.com> on 2005/11/02 06:25:24 UTC

Re: RC3: dependency on commons-lang

On 10/25/05, Sean Schofield <se...@gmail.com> wrote:
>
> I don't think we will enjoy keeping some 100+ classes in sync across
> two different packages. Nor will I think that users who try to supply
> a patch who enjoy this. We couldn't use svn externals either b/c the
> files need to have different package statements.

That's why this code would need to either be repackaged automatically, or
eliminated from the current design altogether.

The whole point of the shared code is to cut down on this type of
> headache. The RI has the luxury of just providing an implementation.
> They do not provide components so they don't have to share code. As
> Manfred put it, this code is shared between projects for a reason.

Agreed. However, the reason is out of date because the projects are now
separated (as they should be).

I agree the current situation is not ideal and I'm open to your idea
> and anyone elses but so far this solution seems even worse.

I agree that your description of the proposed approach is worse, but I don't
think anyone was suggesting what you described. :-)

If you want to use a version of tomahawk that is incompatible with
> your MyFaces implementation on the web server, just upgrade the
> MyFaces version. Yes its a pain but it certainly doesn't seem to be
> insurmountable.

This just proves that we depend on something other than the APIs in the
specification to integrate the two projects together. That indicates that we
haven't ensured proper isolation between the projects.

Am I misssing something here? Is the problem more significant then
> upgrading your MyFaces implementation?

I think you might be missing the point of having a standard. :-)

The implementation of the standard runtime stands alone. The implementation
of any extensions to the standard also stand alone.

The current shared code approach breaks the guarantee that any combination
of standard runtime implementation and standard extension implementation can
work together.

The fact that a certain combination of these implementations are provided by
a common set of developers should be entirely irrelevant to the end user.

Kind Regards,
John Fallows.

On 10/24/05, John Fallows <jo...@gmail.com> wrote:
> > Hey Sean,
> >
> > On 10/24/05, Sean Schofield <se...@gmail.com> wrote:
> > > I agree the shared classes is the most important issue to focus on. I
> > > also agree -1 on repackaging them. We would live to regret that
> > > decision.
> >
> > Your current position is clear, but not your rationale. Can you
> > please elabotate so that we can better understand the perceived
> > downside of using this approach?
> >
> > Kind Regards,
> > John Fallows.
> >
>

Re: myfaces-share (was RC3...)

Posted by Martin Marinschek <ma...@gmail.com>.

Well, for me, if John achieves a way of doing this on a
"automatically-in-deployment" base, then this is very much ok - if we
have to copy classes manually whenever we deploy, this won't work.

regards,

Martin

On 11/3/05, Keijo Nurmes <kn...@dnainternet.net> wrote:
> I imagine there is also loads of code to be refactored as shared.
> It's most important that there is a clean spot (shared.jar common.jar whatever.jar)
> where to put all future common code.
>
> IMHO the trade-off between supporting freely mixing different versions of myfaces libraries
> and risking the quality of code is too high.
>
> regards,
>
> Keijo
>
>
> Martin Marinschek wrote:
>
> >together with John I have taken a look onto the shared classes, and he
> >thinks there might be a solution to get rid of most shared classes and
> >repackage the remaining ones as a util jar-file.
> >
> >Don't know yet if this will work out though!
> >
> >regards,
> >
> >Martin
> >
> >On 11/3/05, Craig McClanahan <cr...@apache.org> wrote:
> >
> >
> >>On 11/2/05, Sean Schofield <se...@gmail.com> wrote:
> >>
> >>
> >>>I'm not too wild about a new jar.  Craig made some good arguments a
> >>>while back about keeping myfaces just two jars (impl and api).
> >>>
> >>>Perhaps he can be persuaded to share his thoughts with us again?  He
> >>>has some relevant experience with this in the RI and trying to use the
> >>>RI and MyFaces with Shale.
> >>>
> >>>
> >> The original argument went like this:  anyone who creates a build script
> >>for the RI will define two properties (one for the API classes and one for
> >>the implementation) ... and having the MyFaces distribution organized the
> >>same way would facilitate people trying it out.  However, this was primarily
> >>an argument to split the original all-in-one jar file into two.  It has less
> >>relevance when thinking about a myfaces-share.jar file.
> >>
> >> Why?  Because the MyFaces implementation (as does the RI implementation)
> >>has other external dependencies as well, so build scripts would already have
> >>to accomodate that difference.  There this argument doesn't really apply to
> >>whether myfaces-share.jar makes sense or not.
> >>
> >> On that topic, I *definitely* believe that it does make sense.  None of us
> >>have enough time in the day to maintain two sets of code that does the same
> >>thing, when its much easier to share a common set.  Ironically, this would
> >>definitely put restrictions on API evolution of the shared classes ... but
> >>those restrictions would be no different than the restrictions you
> >>implicitly accept on any other third party libraries that are shared between
> >>the JSF implementation and Tomahawk.  And, if *anyone* is going to be
> >>motiviated to maintain API compatibility across different versions of the
> >>implementation and the components, it's certainly convenient not to have to
> >>look any further than yourselves :-).
> >>
> >> Craig
> >>
> >>
> >>
> >>
> >>>sean
> >>>
> >>>On 11/2/05, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> >>>
> >>>
> >>>>Ok, let's have a look at this.
> >>>>
> >>>>Although I doubt that we will get rid of the *Renderer*Base classes.
> >>>>
> >>>>regards,
> >>>>
> >>>>Martin
> >>>>
> >>>>On 11/2/05, John Fallows <jo...@gmail.com> wrote:
> >>>>
> >>>>
> >>>>>On 11/2/05, Martin Marinschek <martin.marinschek@gmail.com > wrote:
> >>>>>
> >>>>>
> >>>>>>Yes, this is another option.
> >>>>>>
> >>>>>>make myfaces-share something like a common-jsf-utils or so.
> >>>>>>
> >>>>>>Thing is that changes should not happen very often in there, then.
> >>>>>>
> >>>>>>
> >>And
> >>
> >>
> >>>>>>incompatible changes never.
> >>>>>>
> >>>>>>
> >>>>> Right.
> >>>>>
> >>>>> This requires that the shared code be promoted to a public API, which
> >>>>>reduces it's ability to change/refactor over time.  That's a big
> >>>>>
> >>>>>
> >>decision.
> >>
> >>
> >>>>>In general, it is usually best to keep the public API as small as
> >>>>>
> >>>>>
> >>reasonably
> >>
> >>
> >>>>>possible, so that the least number of constraints are placed on the
> >>>>>implementation.
> >>>>>
> >>>>> Perhaps we can implement the common code once (to avoid maintenance
> >>>>>headaches), but not actually share it in the same package across
> >>>>>
> >>>>>
> >>project
> >>
> >>
> >>>>>implementations (to avoid unnecessary package overlap).  It should be
> >>>>>possible to automate this process as part of the build.
> >>>>>
> >>>>> This would allow the trunk to have a single source of truth, while
> >>>>>
> >>>>>
> >>deployed
> >>
> >>
> >>>>>implementation versions could still vary independently as they would
> >>>>>
> >>>>>
> >>for any
> >>
> >>
> >>>>>combination of standard runtime / extension to the standard.
> >>>>>
> >>>>> I think it would also be useful to do a thorough review of the actual
> >>>>>integration points between the shared codebase and the two different
> >>>>>implementations, with a goal of reducing the amount of shared code,
> >>>>>especially the RendererBase classes and their supporting classes.  I
> >>>>>
> >>>>>
> >>can
> >>
> >>
> >>>>>look into this and report back to the group.  If anyone else wants to
> >>>>>
> >>>>>
> >>help,
> >>
> >>
> >>>>>please let me know.
> >>>>>
> >>>>> Suppose we don't solve this problem.  Out of all the component
> >>>>>
> >>>>>
> >>libraries
> >>
> >>
> >>>>>available for JavaServer Faces, do we really want to have to explain
> >>>>>
> >>>>>
> >>to end
> >>
> >>
> >>>>>users why the MyFaces Tomahawk project doesn't always work so well
> >>>>>
> >>>>>
> >>with the
> >>
> >>
> >>>>>MyFaces Runtime?
> >>>>>
> >>>>> Kind Regards,
> >>>>> John Fallows.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>On 11/2/05, Bill Dudney <bdudney@mac.com > wrote:
> >>>>>>
> >>>>>>
> >>>>>>>Hi John,
> >>>>>>>
> >>>>>>>On Nov 1, 2005, at 10:25 PM, John Fallows wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>>If you want to use a version of tomahawk that is incompatible
> >>>>>>>>
> >>>>>>>>
> >>with
> >>
> >>
> >>>>>>>>your MyFaces implementation on the web server, just upgrade the
> >>>>>>>>MyFaces version.  Yes its a pain but it certainly doesn't seem
> >>>>>>>>
> >>>>>>>>
> >>to be
> >>
> >>
> >>>>>>>>insurmountable.
> >>>>>>>>
> >>>>>>>>This just proves that we depend on something other than the APIs
> >>>>>>>>
> >>>>>>>>
> >>in
> >>
> >>
> >>>>>>>>the specification to integrate the two projects together.  That
> >>>>>>>>indicates that we haven't ensured proper isolation between the
> >>>>>>>>projects.
> >>>>>>>>
> >>>>>>>>Am I misssing something here?  Is the problem more significant
> >>>>>>>>
> >>>>>>>>
> >>then
> >>
> >>
> >>>>>>>>upgrading your MyFaces implementation?
> >>>>>>>>
> >>>>>>>>I think you might be missing the point of having a standard. :-)
> >>>>>>>>
> >>>>>>>>The implementation of the standard runtime stands alone.  The
> >>>>>>>>implementation of any extensions to the standard also stand
> >>>>>>>>
> >>>>>>>>
> >>alone.
> >>
> >>
> >>>>>>>>The current shared code approach breaks the guarantee that any
> >>>>>>>>combination of standard runtime implementation and standard
> >>>>>>>>extension implementation can work together.
> >>>>>>>>
> >>>>>>>>The fact that a certain combination of these implementations are
> >>>>>>>>provided by a common set of developers should be entirely
> >>>>>>>>irrelevant to the end user.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>I think you might be missing something here. The standard does not
> >>>>>>>provide sufficient definition of how the components will be
> >>>>>>>implemented (and perhaps that is a good thing). There is a ton of
> >>>>>>>common code between all components that is not defined in the
> >>>>>>>standard. We can choose to re-implement that functionality in
> >>>>>>>tomahawk, copy and repackage or put it in a separate jar. Perhaps
> >>>>>>>
> >>>>>>>
> >>it
> >>
> >>
> >>>>>>>would be better to have more detail in the API for the component
> >>>>>>>classes and perhaps it would not be, either way the 1.1 and 1.2
> >>>>>>>versions of the spec don't have the detail needed to reuse complex
> >>>>>>>code across components. With the current spec its better IMO to
> >>>>>>>implement everything once and share it.
> >>>>>>>
> >>>>>>>I think the bottom line is that myfaces-share.jar is something
> >>>>>>>
> >>>>>>>
> >>like
> >>
> >>
> >>>>>>>commons-logging.jar. No one decries the fact that we depend on
> >>>>>>>logging (well perhaps 'no one' is a strong statement :-) so why
> >>>>>>>should we be put out by dependence on myfaces-share.jar. It could
> >>>>>>>just as easily be called html-utils.jar or jsf-component-building-
> >>>>>>>made-easy.jar or whatever.
> >>>>>>>
> >>>>>>>As far as separation of the projects goes. myfaces-impl.jar and
> >>>>>>>tomahawk.jar depend on myfaces-share.jar. myfaces-share.jar should
> >>>>>>>not depend on myfaces-impl.jar of course but could depend on
> >>>>>>>
> >>>>>>>
> >>myfaces-
> >>
> >>
> >>>>>>>api.jar. The last time I checked the dependency tree was as
> >>>>>>>
> >>>>>>>
> >>described
> >>
> >>
> >>>>>>>here so I think we are in good shape to make things look like
> >>>>>>>
> >>>>>>>
> >>this.
> >>
> >>
> >>>>>>>Anyway my $0.02 on this.
> >>>>>>>
> >>>>>>>TTFN,
> >>>>>>>
> >>>>>>>-bd-
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>--
> >>>>>>
> >>>>>>http://www.irian.at
> >>>>>>Your JSF powerhouse -
> >>>>>>JSF Trainings in English and German
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>--
> >>>>
> >>>>http://www.irian.at
> >>>>Your JSF powerhouse -
> >>>>JSF Trainings in English and German
> >>>>
> >>>>
> >>>>
> >>
> >>
> >
> >
> >--
> >
> >http://www.irian.at
> >Your JSF powerhouse -
> >JSF Trainings in English and German
> >
> >
> >
>
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: myfaces-share (was RC3...)

Posted by Keijo Nurmes <kn...@dnainternet.net>.

I imagine there is also loads of code to be refactored as shared. 
It’s most important that there is a clean spot (shared.jar common.jar whatever.jar)  
where to put all future common code. 

IMHO the trade-off between supporting freely mixing different versions of myfaces libraries 
and risking the quality of code is too high.

regards,

Keijo


Martin Marinschek wrote:

>together with John I have taken a look onto the shared classes, and he
>thinks there might be a solution to get rid of most shared classes and
>repackage the remaining ones as a util jar-file.
>
>Don't know yet if this will work out though!
>
>regards,
>
>Martin
>
>On 11/3/05, Craig McClanahan <cr...@apache.org> wrote:
>  
>
>>On 11/2/05, Sean Schofield <se...@gmail.com> wrote:
>>    
>>
>>>I'm not too wild about a new jar.  Craig made some good arguments a
>>>while back about keeping myfaces just two jars (impl and api).
>>>
>>>Perhaps he can be persuaded to share his thoughts with us again?  He
>>>has some relevant experience with this in the RI and trying to use the
>>>RI and MyFaces with Shale.
>>>      
>>>
>> The original argument went like this:  anyone who creates a build script
>>for the RI will define two properties (one for the API classes and one for
>>the implementation) ... and having the MyFaces distribution organized the
>>same way would facilitate people trying it out.  However, this was primarily
>>an argument to split the original all-in-one jar file into two.  It has less
>>relevance when thinking about a myfaces-share.jar file.
>>
>> Why?  Because the MyFaces implementation (as does the RI implementation)
>>has other external dependencies as well, so build scripts would already have
>>to accomodate that difference.  There this argument doesn't really apply to
>>whether myfaces-share.jar makes sense or not.
>>
>> On that topic, I *definitely* believe that it does make sense.  None of us
>>have enough time in the day to maintain two sets of code that does the same
>>thing, when its much easier to share a common set.  Ironically, this would
>>definitely put restrictions on API evolution of the shared classes ... but
>>those restrictions would be no different than the restrictions you
>>implicitly accept on any other third party libraries that are shared between
>>the JSF implementation and Tomahawk.  And, if *anyone* is going to be
>>motiviated to maintain API compatibility across different versions of the
>>implementation and the components, it's certainly convenient not to have to
>>look any further than yourselves :-).
>>
>> Craig
>>
>>
>>    
>>
>>>sean
>>>
>>>On 11/2/05, Martin Marinschek < martin.marinschek@gmail.com> wrote:
>>>      
>>>
>>>>Ok, let's have a look at this.
>>>>
>>>>Although I doubt that we will get rid of the *Renderer*Base classes.
>>>>
>>>>regards,
>>>>
>>>>Martin
>>>>
>>>>On 11/2/05, John Fallows <jo...@gmail.com> wrote:
>>>>        
>>>>
>>>>>On 11/2/05, Martin Marinschek <martin.marinschek@gmail.com > wrote:
>>>>>          
>>>>>
>>>>>>Yes, this is another option.
>>>>>>
>>>>>>make myfaces-share something like a common-jsf-utils or so.
>>>>>>
>>>>>>Thing is that changes should not happen very often in there, then.
>>>>>>            
>>>>>>
>>And
>>    
>>
>>>>>>incompatible changes never.
>>>>>>            
>>>>>>
>>>>> Right.
>>>>>
>>>>> This requires that the shared code be promoted to a public API, which
>>>>>reduces it's ability to change/refactor over time.  That's a big
>>>>>          
>>>>>
>>decision.
>>    
>>
>>>>>In general, it is usually best to keep the public API as small as
>>>>>          
>>>>>
>>reasonably
>>    
>>
>>>>>possible, so that the least number of constraints are placed on the
>>>>>implementation.
>>>>>
>>>>> Perhaps we can implement the common code once (to avoid maintenance
>>>>>headaches), but not actually share it in the same package across
>>>>>          
>>>>>
>>project
>>    
>>
>>>>>implementations (to avoid unnecessary package overlap).  It should be
>>>>>possible to automate this process as part of the build.
>>>>>
>>>>> This would allow the trunk to have a single source of truth, while
>>>>>          
>>>>>
>>deployed
>>    
>>
>>>>>implementation versions could still vary independently as they would
>>>>>          
>>>>>
>>for any
>>    
>>
>>>>>combination of standard runtime / extension to the standard.
>>>>>
>>>>> I think it would also be useful to do a thorough review of the actual
>>>>>integration points between the shared codebase and the two different
>>>>>implementations, with a goal of reducing the amount of shared code,
>>>>>especially the RendererBase classes and their supporting classes.  I
>>>>>          
>>>>>
>>can
>>    
>>
>>>>>look into this and report back to the group.  If anyone else wants to
>>>>>          
>>>>>
>>help,
>>    
>>
>>>>>please let me know.
>>>>>
>>>>> Suppose we don't solve this problem.  Out of all the component
>>>>>          
>>>>>
>>libraries
>>    
>>
>>>>>available for JavaServer Faces, do we really want to have to explain
>>>>>          
>>>>>
>>to end
>>    
>>
>>>>>users why the MyFaces Tomahawk project doesn't always work so well
>>>>>          
>>>>>
>>with the
>>    
>>
>>>>>MyFaces Runtime?
>>>>>
>>>>> Kind Regards,
>>>>> John Fallows.
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>On 11/2/05, Bill Dudney <bdudney@mac.com > wrote:
>>>>>>            
>>>>>>
>>>>>>>Hi John,
>>>>>>>
>>>>>>>On Nov 1, 2005, at 10:25 PM, John Fallows wrote:
>>>>>>>              
>>>>>>>
>>>>>>>>If you want to use a version of tomahawk that is incompatible
>>>>>>>>                
>>>>>>>>
>>with
>>    
>>
>>>>>>>>your MyFaces implementation on the web server, just upgrade the
>>>>>>>>MyFaces version.  Yes its a pain but it certainly doesn't seem
>>>>>>>>                
>>>>>>>>
>>to be
>>    
>>
>>>>>>>>insurmountable.
>>>>>>>>
>>>>>>>>This just proves that we depend on something other than the APIs
>>>>>>>>                
>>>>>>>>
>>in
>>    
>>
>>>>>>>>the specification to integrate the two projects together.  That
>>>>>>>>indicates that we haven't ensured proper isolation between the
>>>>>>>>projects.
>>>>>>>>
>>>>>>>>Am I misssing something here?  Is the problem more significant
>>>>>>>>                
>>>>>>>>
>>then
>>    
>>
>>>>>>>>upgrading your MyFaces implementation?
>>>>>>>>
>>>>>>>>I think you might be missing the point of having a standard. :-)
>>>>>>>>
>>>>>>>>The implementation of the standard runtime stands alone.  The
>>>>>>>>implementation of any extensions to the standard also stand
>>>>>>>>                
>>>>>>>>
>>alone.
>>    
>>
>>>>>>>>The current shared code approach breaks the guarantee that any
>>>>>>>>combination of standard runtime implementation and standard
>>>>>>>>extension implementation can work together.
>>>>>>>>
>>>>>>>>The fact that a certain combination of these implementations are
>>>>>>>>provided by a common set of developers should be entirely
>>>>>>>>irrelevant to the end user.
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>I think you might be missing something here. The standard does not
>>>>>>>provide sufficient definition of how the components will be
>>>>>>>implemented (and perhaps that is a good thing). There is a ton of
>>>>>>>common code between all components that is not defined in the
>>>>>>>standard. We can choose to re-implement that functionality in
>>>>>>>tomahawk, copy and repackage or put it in a separate jar. Perhaps
>>>>>>>              
>>>>>>>
>>it
>>    
>>
>>>>>>>would be better to have more detail in the API for the component
>>>>>>>classes and perhaps it would not be, either way the 1.1 and 1.2
>>>>>>>versions of the spec don't have the detail needed to reuse complex
>>>>>>>code across components. With the current spec its better IMO to
>>>>>>>implement everything once and share it.
>>>>>>>
>>>>>>>I think the bottom line is that myfaces-share.jar is something
>>>>>>>              
>>>>>>>
>>like
>>    
>>
>>>>>>>commons-logging.jar. No one decries the fact that we depend on
>>>>>>>logging (well perhaps 'no one' is a strong statement :-) so why
>>>>>>>should we be put out by dependence on myfaces-share.jar. It could
>>>>>>>just as easily be called html-utils.jar or jsf-component-building-
>>>>>>>made-easy.jar or whatever.
>>>>>>>
>>>>>>>As far as separation of the projects goes. myfaces-impl.jar and
>>>>>>>tomahawk.jar depend on myfaces-share.jar. myfaces-share.jar should
>>>>>>>not depend on myfaces-impl.jar of course but could depend on
>>>>>>>              
>>>>>>>
>>myfaces-
>>    
>>
>>>>>>>api.jar. The last time I checked the dependency tree was as
>>>>>>>              
>>>>>>>
>>described
>>    
>>
>>>>>>>here so I think we are in good shape to make things look like
>>>>>>>              
>>>>>>>
>>this.
>>    
>>
>>>>>>>Anyway my $0.02 on this.
>>>>>>>
>>>>>>>TTFN,
>>>>>>>
>>>>>>>-bd-
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>--
>>>>>>
>>>>>>http://www.irian.at
>>>>>>Your JSF powerhouse -
>>>>>>JSF Trainings in English and German
>>>>>>
>>>>>>            
>>>>>>
>>>>>          
>>>>>
>>>>--
>>>>
>>>>http://www.irian.at
>>>>Your JSF powerhouse -
>>>>JSF Trainings in English and German
>>>>
>>>>        
>>>>
>>    
>>
>
>
>--
>
>http://www.irian.at
>Your JSF powerhouse -
>JSF Trainings in English and German
>
>  
>

Re: myfaces-share (was RC3...)

Posted by Martin Marinschek <ma...@gmail.com>.

together with John I have taken a look onto the shared classes, and he
thinks there might be a solution to get rid of most shared classes and
repackage the remaining ones as a util jar-file.

Don't know yet if this will work out though!

regards,

Martin

On 11/3/05, Craig McClanahan <cr...@apache.org> wrote:
>
>
> On 11/2/05, Sean Schofield <se...@gmail.com> wrote:
> > I'm not too wild about a new jar.  Craig made some good arguments a
> > while back about keeping myfaces just two jars (impl and api).
> >
> > Perhaps he can be persuaded to share his thoughts with us again?  He
> > has some relevant experience with this in the RI and trying to use the
> > RI and MyFaces with Shale.
>
>  The original argument went like this:  anyone who creates a build script
> for the RI will define two properties (one for the API classes and one for
> the implementation) ... and having the MyFaces distribution organized the
> same way would facilitate people trying it out.  However, this was primarily
> an argument to split the original all-in-one jar file into two.  It has less
> relevance when thinking about a myfaces-share.jar file.
>
>  Why?  Because the MyFaces implementation (as does the RI implementation)
> has other external dependencies as well, so build scripts would already have
> to accomodate that difference.  There this argument doesn't really apply to
> whether myfaces-share.jar makes sense or not.
>
>  On that topic, I *definitely* believe that it does make sense.  None of us
> have enough time in the day to maintain two sets of code that does the same
> thing, when its much easier to share a common set.  Ironically, this would
> definitely put restrictions on API evolution of the shared classes ... but
> those restrictions would be no different than the restrictions you
> implicitly accept on any other third party libraries that are shared between
> the JSF implementation and Tomahawk.  And, if *anyone* is going to be
> motiviated to maintain API compatibility across different versions of the
> implementation and the components, it's certainly convenient not to have to
> look any further than yourselves :-).
>
>  Craig
>
>
> > sean
> >
> > On 11/2/05, Martin Marinschek < martin.marinschek@gmail.com> wrote:
> > > Ok, let's have a look at this.
> > >
> > > Although I doubt that we will get rid of the *Renderer*Base classes.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 11/2/05, John Fallows <jo...@gmail.com> wrote:
> > > > On 11/2/05, Martin Marinschek <martin.marinschek@gmail.com > wrote:
> > > > > Yes, this is another option.
> > > > >
> > > > > make myfaces-share something like a common-jsf-utils or so.
> > > > >
> > > > > Thing is that changes should not happen very often in there, then.
> And
> > > > > incompatible changes never.
> > > >
> > > >  Right.
> > > >
> > > >  This requires that the shared code be promoted to a public API, which
> > > > reduces it's ability to change/refactor over time.  That's a big
> decision.
> > > > In general, it is usually best to keep the public API as small as
> reasonably
> > > > possible, so that the least number of constraints are placed on the
> > > > implementation.
> > > >
> > > >  Perhaps we can implement the common code once (to avoid maintenance
> > > > headaches), but not actually share it in the same package across
> project
> > > > implementations (to avoid unnecessary package overlap).  It should be
> > > > possible to automate this process as part of the build.
> > > >
> > > >  This would allow the trunk to have a single source of truth, while
> deployed
> > > > implementation versions could still vary independently as they would
> for any
> > > > combination of standard runtime / extension to the standard.
> > > >
> > > >  I think it would also be useful to do a thorough review of the actual
> > > > integration points between the shared codebase and the two different
> > > > implementations, with a goal of reducing the amount of shared code,
> > > > especially the RendererBase classes and their supporting classes.  I
> can
> > > > look into this and report back to the group.  If anyone else wants to
> help,
> > > > please let me know.
> > > >
> > > >  Suppose we don't solve this problem.  Out of all the component
> libraries
> > > > available for JavaServer Faces, do we really want to have to explain
> to end
> > > > users why the MyFaces Tomahawk project doesn't always work so well
> with the
> > > > MyFaces Runtime?
> > > >
> > > >  Kind Regards,
> > > >  John Fallows.
> > > >
> > > >
> > > > > On 11/2/05, Bill Dudney <bdudney@mac.com > wrote:
> > > > > > Hi John,
> > > > > >
> > > > > > On Nov 1, 2005, at 10:25 PM, John Fallows wrote:
> > > > > > >
> > > > > > > If you want to use a version of tomahawk that is incompatible
> with
> > > > > > > your MyFaces implementation on the web server, just upgrade the
> > > > > > > MyFaces version.  Yes its a pain but it certainly doesn't seem
> to be
> > > > > > > insurmountable.
> > > > > > >
> > > > > > > This just proves that we depend on something other than the APIs
> in
> > > > > > > the specification to integrate the two projects together.  That
> > > > > > > indicates that we haven't ensured proper isolation between the
> > > > > > > projects.
> > > > > > >
> > > > > > > Am I misssing something here?  Is the problem more significant
> then
> > > > > > > upgrading your MyFaces implementation?
> > > > > > >
> > > > > > > I think you might be missing the point of having a standard. :-)
> > > > > > >
> > > > > > > The implementation of the standard runtime stands alone.  The
> > > > > > > implementation of any extensions to the standard also stand
> alone.
> > > > > > >
> > > > > > > The current shared code approach breaks the guarantee that any
> > > > > > > combination of standard runtime implementation and standard
> > > > > > > extension implementation can work together.
> > > > > > >
> > > > > > > The fact that a certain combination of these implementations are
> > > > > > > provided by a common set of developers should be entirely
> > > > > > > irrelevant to the end user.
> > > > > > >
> > > > > >
> > > > > > I think you might be missing something here. The standard does not
> > > > > > provide sufficient definition of how the components will be
> > > > > > implemented (and perhaps that is a good thing). There is a ton of
> > > > > > common code between all components that is not defined in the
> > > > > > standard. We can choose to re-implement that functionality in
> > > > > > tomahawk, copy and repackage or put it in a separate jar. Perhaps
> it
> > > > > > would be better to have more detail in the API for the component
> > > > > > classes and perhaps it would not be, either way the 1.1 and 1.2
> > > > > > versions of the spec don't have the detail needed to reuse complex
> > > > > > code across components. With the current spec its better IMO to
> > > > > > implement everything once and share it.
> > > > > >
> > > > > > I think the bottom line is that myfaces-share.jar is something
> like
> > > > > > commons-logging.jar. No one decries the fact that we depend on
> > > > > > logging (well perhaps 'no one' is a strong statement :-) so why
> > > > > > should we be put out by dependence on myfaces-share.jar. It could
> > > > > > just as easily be called html-utils.jar or jsf-component-building-
> > > > > > made-easy.jar or whatever.
> > > > > >
> > > > > > As far as separation of the projects goes. myfaces-impl.jar and
> > > > > > tomahawk.jar depend on myfaces-share.jar. myfaces-share.jar should
> > > > > > not depend on myfaces-impl.jar of course but could depend on
> myfaces-
> > > > > > api.jar. The last time I checked the dependency tree was as
> described
> > > > > > here so I think we are in good shape to make things look like
> this.
> > > > > >
> > > > > > Anyway my $0.02 on this.
> > > > > >
> > > > > > TTFN,
> > > > > >
> > > > > > -bd-
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > http://www.irian.at
> > > > > Your JSF powerhouse -
> > > > > JSF Trainings in English and German
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > > Your JSF powerhouse -
> > > JSF Trainings in English and German
> > >
> >
>
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: myfaces-share (was RC3...)

Posted by Craig McClanahan <cr...@apache.org>.

On 11/2/05, Sean Schofield <se...@gmail.com> wrote:
>
> I'm not too wild about a new jar. Craig made some good arguments a
> while back about keeping myfaces just two jars (impl and api).
>
> Perhaps he can be persuaded to share his thoughts with us again? He
> has some relevant experience with this in the RI and trying to use the
> RI and MyFaces with Shale.


The original argument went like this: anyone who creates a build script for
the RI will define two properties (one for the API classes and one for the
implementation) ... and having the MyFaces distribution organized the same
way would facilitate people trying it out. However, this was primarily an
argument to split the original all-in-one jar file into two. It has less
relevance when thinking about a myfaces-share.jar file.

Why? Because the MyFaces implementation (as does the RI implementation) has
other external dependencies as well, so build scripts would already have to
accomodate that difference. There this argument doesn't really apply to
whether myfaces-share.jar makes sense or not.

On that topic, I *definitely* believe that it does make sense. None of us
have enough time in the day to maintain two sets of code that does the same
thing, when its much easier to share a common set. Ironically, this would
definitely put restrictions on API evolution of the shared classes ... but
those restrictions would be no different than the restrictions you
implicitly accept on any other third party libraries that are shared between
the JSF implementation and Tomahawk. And, if *anyone* is going to be
motiviated to maintain API compatibility across different versions of the
implementation and the components, it's certainly convenient not to have to
look any further than yourselves :-).

Craig

sean
>
> On 11/2/05, Martin Marinschek <ma...@gmail.com> wrote:
> > Ok, let's have a look at this.
> >
> > Although I doubt that we will get rid of the *Renderer*Base classes.
> >
> > regards,
> >
> > Martin
> >
> > On 11/2/05, John Fallows <jo...@gmail.com> wrote:
> > > On 11/2/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > > Yes, this is another option.
> > > >
> > > > make myfaces-share something like a common-jsf-utils or so.
> > > >
> > > > Thing is that changes should not happen very often in there, then.
> And
> > > > incompatible changes never.
> > >
> > > Right.
> > >
> > > This requires that the shared code be promoted to a public API, which
> > > reduces it's ability to change/refactor over time. That's a big
> decision.
> > > In general, it is usually best to keep the public API as small as
> reasonably
> > > possible, so that the least number of constraints are placed on the
> > > implementation.
> > >
> > > Perhaps we can implement the common code once (to avoid maintenance
> > > headaches), but not actually share it in the same package across
> project
> > > implementations (to avoid unnecessary package overlap). It should be
> > > possible to automate this process as part of the build.
> > >
> > > This would allow the trunk to have a single source of truth, while
> deployed
> > > implementation versions could still vary independently as they would
> for any
> > > combination of standard runtime / extension to the standard.
> > >
> > > I think it would also be useful to do a thorough review of the actual
> > > integration points between the shared codebase and the two different
> > > implementations, with a goal of reducing the amount of shared code,
> > > especially the RendererBase classes and their supporting classes. I
> can
> > > look into this and report back to the group. If anyone else wants to
> help,
> > > please let me know.
> > >
> > > Suppose we don't solve this problem. Out of all the component
> libraries
> > > available for JavaServer Faces, do we really want to have to explain
> to end
> > > users why the MyFaces Tomahawk project doesn't always work so well
> with the
> > > MyFaces Runtime?
> > >
> > > Kind Regards,
> > > John Fallows.
> > >
> > >
> > > > On 11/2/05, Bill Dudney <bdudney@mac.com > wrote:
> > > > > Hi John,
> > > > >
> > > > > On Nov 1, 2005, at 10:25 PM, John Fallows wrote:
> > > > > >
> > > > > > If you want to use a version of tomahawk that is incompatible
> with
> > > > > > your MyFaces implementation on the web server, just upgrade the
> > > > > > MyFaces version. Yes its a pain but it certainly doesn't seem to
> be
> > > > > > insurmountable.
> > > > > >
> > > > > > This just proves that we depend on something other than the APIs
> in
> > > > > > the specification to integrate the two projects together. That
> > > > > > indicates that we haven't ensured proper isolation between the
> > > > > > projects.
> > > > > >
> > > > > > Am I misssing something here? Is the problem more significant
> then
> > > > > > upgrading your MyFaces implementation?
> > > > > >
> > > > > > I think you might be missing the point of having a standard. :-)
> > > > > >
> > > > > > The implementation of the standard runtime stands alone. The
> > > > > > implementation of any extensions to the standard also stand
> alone.
> > > > > >
> > > > > > The current shared code approach breaks the guarantee that any
> > > > > > combination of standard runtime implementation and standard
> > > > > > extension implementation can work together.
> > > > > >
> > > > > > The fact that a certain combination of these implementations are
> > > > > > provided by a common set of developers should be entirely
> > > > > > irrelevant to the end user.
> > > > > >
> > > > >
> > > > > I think you might be missing something here. The standard does not
> > > > > provide sufficient definition of how the components will be
> > > > > implemented (and perhaps that is a good thing). There is a ton of
> > > > > common code between all components that is not defined in the
> > > > > standard. We can choose to re-implement that functionality in
> > > > > tomahawk, copy and repackage or put it in a separate jar. Perhaps
> it
> > > > > would be better to have more detail in the API for the component
> > > > > classes and perhaps it would not be, either way the 1.1 and 1.2
> > > > > versions of the spec don't have the detail needed to reuse complex
> > > > > code across components. With the current spec its better IMO to
> > > > > implement everything once and share it.
> > > > >
> > > > > I think the bottom line is that myfaces-share.jar is something
> like
> > > > > commons-logging.jar. No one decries the fact that we depend on
> > > > > logging (well perhaps 'no one' is a strong statement :-) so why
> > > > > should we be put out by dependence on myfaces-share.jar. It could
> > > > > just as easily be called html-utils.jar or jsf-component-building-
> > > > > made-easy.jar or whatever.
> > > > >
> > > > > As far as separation of the projects goes. myfaces-impl.jar and
> > > > > tomahawk.jar depend on myfaces-share.jar. myfaces-share.jar should
> > > > > not depend on myfaces-impl.jar of course but could depend on
> myfaces-
> > > > > api.jar. The last time I checked the dependency tree was as
> described
> > > > > here so I think we are in good shape to make things look like
> this.
> > > > >
> > > > > Anyway my $0.02 on this.
> > > > >
> > > > > TTFN,
> > > > >
> > > > > -bd-
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > > Your JSF powerhouse -
> > > > JSF Trainings in English and German
> > > >
> > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> > Your JSF powerhouse -
> > JSF Trainings in English and German
> >
>

Re: myfaces-share (was RC3...)

Posted by Sean Schofield <se...@gmail.com>.

I'm not too wild about a new jar.  Craig made some good arguments a
while back about keeping myfaces just two jars (impl and api).

Perhaps he can be persuaded to share his thoughts with us again?  He
has some relevant experience with this in the RI and trying to use the
RI and MyFaces with Shale.

sean

On 11/2/05, Martin Marinschek <ma...@gmail.com> wrote:
> Ok, let's have a look at this.
>
> Although I doubt that we will get rid of the *Renderer*Base classes.
>
> regards,
>
> Martin
>
> On 11/2/05, John Fallows <jo...@gmail.com> wrote:
> > On 11/2/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > Yes, this is another option.
> > >
> > > make myfaces-share something like a common-jsf-utils or so.
> > >
> > > Thing is that changes should not happen very often in there, then. And
> > > incompatible changes never.
> >
> >  Right.
> >
> >  This requires that the shared code be promoted to a public API, which
> > reduces it's ability to change/refactor over time.  That's a big decision.
> > In general, it is usually best to keep the public API as small as reasonably
> > possible, so that the least number of constraints are placed on the
> > implementation.
> >
> >  Perhaps we can implement the common code once (to avoid maintenance
> > headaches), but not actually share it in the same package across project
> > implementations (to avoid unnecessary package overlap).  It should be
> > possible to automate this process as part of the build.
> >
> >  This would allow the trunk to have a single source of truth, while deployed
> > implementation versions could still vary independently as they would for any
> > combination of standard runtime / extension to the standard.
> >
> >  I think it would also be useful to do a thorough review of the actual
> > integration points between the shared codebase and the two different
> > implementations, with a goal of reducing the amount of shared code,
> > especially the RendererBase classes and their supporting classes.  I can
> > look into this and report back to the group.  If anyone else wants to help,
> > please let me know.
> >
> >  Suppose we don't solve this problem.  Out of all the component libraries
> > available for JavaServer Faces, do we really want to have to explain to end
> > users why the MyFaces Tomahawk project doesn't always work so well with the
> > MyFaces Runtime?
> >
> >  Kind Regards,
> >  John Fallows.
> >
> >
> > > On 11/2/05, Bill Dudney <bdudney@mac.com > wrote:
> > > > Hi John,
> > > >
> > > > On Nov 1, 2005, at 10:25 PM, John Fallows wrote:
> > > > >
> > > > > If you want to use a version of tomahawk that is incompatible with
> > > > > your MyFaces implementation on the web server, just upgrade the
> > > > > MyFaces version.  Yes its a pain but it certainly doesn't seem to be
> > > > > insurmountable.
> > > > >
> > > > > This just proves that we depend on something other than the APIs in
> > > > > the specification to integrate the two projects together.  That
> > > > > indicates that we haven't ensured proper isolation between the
> > > > > projects.
> > > > >
> > > > > Am I misssing something here?  Is the problem more significant then
> > > > > upgrading your MyFaces implementation?
> > > > >
> > > > > I think you might be missing the point of having a standard. :-)
> > > > >
> > > > > The implementation of the standard runtime stands alone.  The
> > > > > implementation of any extensions to the standard also stand alone.
> > > > >
> > > > > The current shared code approach breaks the guarantee that any
> > > > > combination of standard runtime implementation and standard
> > > > > extension implementation can work together.
> > > > >
> > > > > The fact that a certain combination of these implementations are
> > > > > provided by a common set of developers should be entirely
> > > > > irrelevant to the end user.
> > > > >
> > > >
> > > > I think you might be missing something here. The standard does not
> > > > provide sufficient definition of how the components will be
> > > > implemented (and perhaps that is a good thing). There is a ton of
> > > > common code between all components that is not defined in the
> > > > standard. We can choose to re-implement that functionality in
> > > > tomahawk, copy and repackage or put it in a separate jar. Perhaps it
> > > > would be better to have more detail in the API for the component
> > > > classes and perhaps it would not be, either way the 1.1 and 1.2
> > > > versions of the spec don't have the detail needed to reuse complex
> > > > code across components. With the current spec its better IMO to
> > > > implement everything once and share it.
> > > >
> > > > I think the bottom line is that myfaces-share.jar is something like
> > > > commons-logging.jar. No one decries the fact that we depend on
> > > > logging (well perhaps 'no one' is a strong statement :-) so why
> > > > should we be put out by dependence on myfaces-share.jar. It could
> > > > just as easily be called html-utils.jar or jsf-component-building-
> > > > made-easy.jar or whatever.
> > > >
> > > > As far as separation of the projects goes. myfaces-impl.jar and
> > > > tomahawk.jar depend on myfaces-share.jar. myfaces-share.jar should
> > > > not depend on myfaces-impl.jar of course but could depend on myfaces-
> > > > api.jar. The last time I checked the dependency tree was as described
> > > > here so I think we are in good shape to make things look like this.
> > > >
> > > > Anyway my $0.02 on this.
> > > >
> > > > TTFN,
> > > >
> > > > -bd-
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > > Your JSF powerhouse -
> > > JSF Trainings in English and German
> > >
> >
> >
>
>
> --
>
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German
>

Re: myfaces-share (was RC3...)

Posted by Martin Marinschek <ma...@gmail.com>.

Ok, let's have a look at this.

Although I doubt that we will get rid of the *Renderer*Base classes.

regards,

Martin

On 11/2/05, John Fallows <jo...@gmail.com> wrote:
> On 11/2/05, Martin Marinschek <ma...@gmail.com> wrote:
> > Yes, this is another option.
> >
> > make myfaces-share something like a common-jsf-utils or so.
> >
> > Thing is that changes should not happen very often in there, then. And
> > incompatible changes never.
>
>  Right.
>
>  This requires that the shared code be promoted to a public API, which
> reduces it's ability to change/refactor over time.  That's a big decision.
> In general, it is usually best to keep the public API as small as reasonably
> possible, so that the least number of constraints are placed on the
> implementation.
>
>  Perhaps we can implement the common code once (to avoid maintenance
> headaches), but not actually share it in the same package across project
> implementations (to avoid unnecessary package overlap).  It should be
> possible to automate this process as part of the build.
>
>  This would allow the trunk to have a single source of truth, while deployed
> implementation versions could still vary independently as they would for any
> combination of standard runtime / extension to the standard.
>
>  I think it would also be useful to do a thorough review of the actual
> integration points between the shared codebase and the two different
> implementations, with a goal of reducing the amount of shared code,
> especially the RendererBase classes and their supporting classes.  I can
> look into this and report back to the group.  If anyone else wants to help,
> please let me know.
>
>  Suppose we don't solve this problem.  Out of all the component libraries
> available for JavaServer Faces, do we really want to have to explain to end
> users why the MyFaces Tomahawk project doesn't always work so well with the
> MyFaces Runtime?
>
>  Kind Regards,
>  John Fallows.
>
>
> > On 11/2/05, Bill Dudney <bdudney@mac.com > wrote:
> > > Hi John,
> > >
> > > On Nov 1, 2005, at 10:25 PM, John Fallows wrote:
> > > >
> > > > If you want to use a version of tomahawk that is incompatible with
> > > > your MyFaces implementation on the web server, just upgrade the
> > > > MyFaces version.  Yes its a pain but it certainly doesn't seem to be
> > > > insurmountable.
> > > >
> > > > This just proves that we depend on something other than the APIs in
> > > > the specification to integrate the two projects together.  That
> > > > indicates that we haven't ensured proper isolation between the
> > > > projects.
> > > >
> > > > Am I misssing something here?  Is the problem more significant then
> > > > upgrading your MyFaces implementation?
> > > >
> > > > I think you might be missing the point of having a standard. :-)
> > > >
> > > > The implementation of the standard runtime stands alone.  The
> > > > implementation of any extensions to the standard also stand alone.
> > > >
> > > > The current shared code approach breaks the guarantee that any
> > > > combination of standard runtime implementation and standard
> > > > extension implementation can work together.
> > > >
> > > > The fact that a certain combination of these implementations are
> > > > provided by a common set of developers should be entirely
> > > > irrelevant to the end user.
> > > >
> > >
> > > I think you might be missing something here. The standard does not
> > > provide sufficient definition of how the components will be
> > > implemented (and perhaps that is a good thing). There is a ton of
> > > common code between all components that is not defined in the
> > > standard. We can choose to re-implement that functionality in
> > > tomahawk, copy and repackage or put it in a separate jar. Perhaps it
> > > would be better to have more detail in the API for the component
> > > classes and perhaps it would not be, either way the 1.1 and 1.2
> > > versions of the spec don't have the detail needed to reuse complex
> > > code across components. With the current spec its better IMO to
> > > implement everything once and share it.
> > >
> > > I think the bottom line is that myfaces-share.jar is something like
> > > commons-logging.jar. No one decries the fact that we depend on
> > > logging (well perhaps 'no one' is a strong statement :-) so why
> > > should we be put out by dependence on myfaces-share.jar. It could
> > > just as easily be called html-utils.jar or jsf-component-building-
> > > made-easy.jar or whatever.
> > >
> > > As far as separation of the projects goes. myfaces-impl.jar and
> > > tomahawk.jar depend on myfaces-share.jar. myfaces-share.jar should
> > > not depend on myfaces-impl.jar of course but could depend on myfaces-
> > > api.jar. The last time I checked the dependency tree was as described
> > > here so I think we are in good shape to make things look like this.
> > >
> > > Anyway my $0.02 on this.
> > >
> > > TTFN,
> > >
> > > -bd-
> > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> > Your JSF powerhouse -
> > JSF Trainings in English and German
> >
>
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: myfaces-share (was RC3...)

Posted by John Fallows <jo...@gmail.com>.

On 11/2/05, Martin Marinschek <ma...@gmail.com> wrote:
>
> Yes, this is another option.
>
> make myfaces-share something like a common-jsf-utils or so.
>
> Thing is that changes should not happen very often in there, then. And
> incompatible changes never.

Right.

This requires that the shared code be promoted to a public API, which
reduces it's ability to change/refactor over time. That's a big decision. In
general, it is usually best to keep the public API as small as reasonably
possible, so that the least number of constraints are placed on the
implementation.

Perhaps we can implement the common code once (to avoid maintenance
headaches), but not actually share it in the same package across project
implementations (to avoid unnecessary package overlap). It should be
possible to automate this process as part of the build.

This would allow the trunk to have a single source of truth, while deployed
implementation versions could still vary independently as they would for any
combination of standard runtime / extension to the standard.

I think it would also be useful to do a thorough review of the actual
integration points between the shared codebase and the two different
implementations, with a goal of reducing the amount of shared code,
especially the RendererBase classes and their supporting classes. I can look
into this and report back to the group. If anyone else wants to help, please
let me know.

Suppose we don't solve this problem. Out of all the component libraries
available for JavaServer Faces, do we really want to have to explain to end
users why the MyFaces Tomahawk project doesn't always work so well with the
MyFaces Runtime?

Kind Regards,
John Fallows.

On 11/2/05, Bill Dudney <bd...@mac.com> wrote:
> > Hi John,
> >
> > On Nov 1, 2005, at 10:25 PM, John Fallows wrote:
> > >
> > > If you want to use a version of tomahawk that is incompatible with
> > > your MyFaces implementation on the web server, just upgrade the
> > > MyFaces version. Yes its a pain but it certainly doesn't seem to be
> > > insurmountable.
> > >
> > > This just proves that we depend on something other than the APIs in
> > > the specification to integrate the two projects together. That
> > > indicates that we haven't ensured proper isolation between the
> > > projects.
> > >
> > > Am I misssing something here? Is the problem more significant then
> > > upgrading your MyFaces implementation?
> > >
> > > I think you might be missing the point of having a standard. :-)
> > >
> > > The implementation of the standard runtime stands alone. The
> > > implementation of any extensions to the standard also stand alone.
> > >
> > > The current shared code approach breaks the guarantee that any
> > > combination of standard runtime implementation and standard
> > > extension implementation can work together.
> > >
> > > The fact that a certain combination of these implementations are
> > > provided by a common set of developers should be entirely
> > > irrelevant to the end user.
> > >
> >
> > I think you might be missing something here. The standard does not
> > provide sufficient definition of how the components will be
> > implemented (and perhaps that is a good thing). There is a ton of
> > common code between all components that is not defined in the
> > standard. We can choose to re-implement that functionality in
> > tomahawk, copy and repackage or put it in a separate jar. Perhaps it
> > would be better to have more detail in the API for the component
> > classes and perhaps it would not be, either way the 1.1 and 1.2
> > versions of the spec don't have the detail needed to reuse complex
> > code across components. With the current spec its better IMO to
> > implement everything once and share it.
> >
> > I think the bottom line is that myfaces-share.jar is something like
> > commons-logging.jar. No one decries the fact that we depend on
> > logging (well perhaps 'no one' is a strong statement :-) so why
> > should we be put out by dependence on myfaces-share.jar. It could
> > just as easily be called html-utils.jar or jsf-component-building-
> > made-easy.jar or whatever.
> >
> > As far as separation of the projects goes. myfaces-impl.jar and
> > tomahawk.jar depend on myfaces-share.jar. myfaces-share.jar should
> > not depend on myfaces-impl.jar of course but could depend on myfaces-
> > api.jar. The last time I checked the dependency tree was as described
> > here so I think we are in good shape to make things look like this.
> >
> > Anyway my $0.02 on this.
> >
> > TTFN,
> >
> > -bd-
> >
> >
>
>
> --
>
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German
>

Re: myfaces-share (was RC3...)

Posted by Martin Marinschek <ma...@gmail.com>.

Yes, this is another option.

make myfaces-share something like a common-jsf-utils or so.

Thing is that changes should not happen very often in there, then. And
incompatible changes never.

regards,

Martin

On 11/2/05, Bill Dudney <bd...@mac.com> wrote:
> Hi John,
>
> On Nov 1, 2005, at 10:25 PM, John Fallows wrote:
> >
> > If you want to use a version of tomahawk that is incompatible with
> > your MyFaces implementation on the web server, just upgrade the
> > MyFaces version.  Yes its a pain but it certainly doesn't seem to be
> > insurmountable.
> >
> > This just proves that we depend on something other than the APIs in
> > the specification to integrate the two projects together.  That
> > indicates that we haven't ensured proper isolation between the
> > projects.
> >
> > Am I misssing something here?  Is the problem more significant then
> > upgrading your MyFaces implementation?
> >
> > I think you might be missing the point of having a standard. :-)
> >
> > The implementation of the standard runtime stands alone.  The
> > implementation of any extensions to the standard also stand alone.
> >
> > The current shared code approach breaks the guarantee that any
> > combination of standard runtime implementation and standard
> > extension implementation can work together.
> >
> > The fact that a certain combination of these implementations are
> > provided by a common set of developers should be entirely
> > irrelevant to the end user.
> >
>
> I think you might be missing something here. The standard does not
> provide sufficient definition of how the components will be
> implemented (and perhaps that is a good thing). There is a ton of
> common code between all components that is not defined in the
> standard. We can choose to re-implement that functionality in
> tomahawk, copy and repackage or put it in a separate jar. Perhaps it
> would be better to have more detail in the API for the component
> classes and perhaps it would not be, either way the 1.1 and 1.2
> versions of the spec don't have the detail needed to reuse complex
> code across components. With the current spec its better IMO to
> implement everything once and share it.
>
> I think the bottom line is that myfaces-share.jar is something like
> commons-logging.jar. No one decries the fact that we depend on
> logging (well perhaps 'no one' is a strong statement :-) so why
> should we be put out by dependence on myfaces-share.jar. It could
> just as easily be called html-utils.jar or jsf-component-building-
> made-easy.jar or whatever.
>
> As far as separation of the projects goes. myfaces-impl.jar and
> tomahawk.jar depend on myfaces-share.jar. myfaces-share.jar should
> not depend on myfaces-impl.jar of course but could depend on myfaces-
> api.jar. The last time I checked the dependency tree was as described
> here so I think we are in good shape to make things look like this.
>
> Anyway my $0.02 on this.
>
> TTFN,
>
> -bd-
>
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

myfaces-share (was RC3...)

Posted by Bill Dudney <bd...@mac.com>.

Hi John,

On Nov 1, 2005, at 10:25 PM, John Fallows wrote:
>
> If you want to use a version of tomahawk that is incompatible with
> your MyFaces implementation on the web server, just upgrade the
> MyFaces version.  Yes its a pain but it certainly doesn't seem to be
> insurmountable.
>
> This just proves that we depend on something other than the APIs in  
> the specification to integrate the two projects together.  That  
> indicates that we haven't ensured proper isolation between the  
> projects.
>
> Am I misssing something here?  Is the problem more significant then
> upgrading your MyFaces implementation?
>
> I think you might be missing the point of having a standard. :-)
>
> The implementation of the standard runtime stands alone.  The  
> implementation of any extensions to the standard also stand alone.
>
> The current shared code approach breaks the guarantee that any  
> combination of standard runtime implementation and standard  
> extension implementation can work together.
>
> The fact that a certain combination of these implementations are  
> provided by a common set of developers should be entirely  
> irrelevant to the end user.
>

I think you might be missing something here. The standard does not  
provide sufficient definition of how the components will be  
implemented (and perhaps that is a good thing). There is a ton of  
common code between all components that is not defined in the  
standard. We can choose to re-implement that functionality in  
tomahawk, copy and repackage or put it in a separate jar. Perhaps it  
would be better to have more detail in the API for the component  
classes and perhaps it would not be, either way the 1.1 and 1.2  
versions of the spec don't have the detail needed to reuse complex  
code across components. With the current spec its better IMO to  
implement everything once and share it.

I think the bottom line is that myfaces-share.jar is something like  
commons-logging.jar. No one decries the fact that we depend on  
logging (well perhaps 'no one' is a strong statement :-) so why  
should we be put out by dependence on myfaces-share.jar. It could  
just as easily be called html-utils.jar or jsf-component-building- 
made-easy.jar or whatever.

As far as separation of the projects goes. myfaces-impl.jar and  
tomahawk.jar depend on myfaces-share.jar. myfaces-share.jar should  
not depend on myfaces-impl.jar of course but could depend on myfaces- 
api.jar. The last time I checked the dependency tree was as described  
here so I think we are in good shape to make things look like this.

Anyway my $0.02 on this.

TTFN,

-bd-