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 <[EMAIL PROTECTED]> wrote:
On 11/2/05, Sean Schofield <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
On 11/2/05, Martin Marinschek <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED] > 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
