struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject Re: [shale] jsf-commons??
Date Fri, 09 Dec 2005 18:24:22 GMT
On 12/9/05, Craig McClanahan <craigmcc@apache.org> wrote:
>
> On 12/8/05, Martin Cooper <martinc@apache.org> wrote:
> >
> > On 12/8/05, Mike Kienenberger <mkienenb@gmail.com> wrote:
> > >
> > > I think it makes the most sense to leave it under MyFaces.
> > > All of the tomahawk and sandbox components directly depend upon it, as
> > > does parts of the MyFaces implementation.   Moving it into another
> > > project doesn't gain anything, and would make code sychronization more
> > > difficult.  As long as it's a separate jar, it doesn't make any
> > > difference to end-users whether it's hosted at MyFaces or another
> > > project.
> >
> >
> > It may not make a different to MyFaces end users, but, assuming the
> common
> > code is also used by Shale, which is what I thought we were discussing
> > here,
> > telling JSF RI users that they have to get a component from MyFaces to
> use
> > Shale with the RI would be a little odd...
>
>
> Well, only sort of ... the tomahawk components will certainly work very
> nicely with Shale, and they are from MyFaces too.


Oh, sure. But that's not "have to get", that's "want the additional
functionality". You don't "have to get" Tomahawk before you can use Shale.

Let's say that Shale and MyFaces wanted to share some underpinning code,
meaning that neither will run without it. Just for the sake of argument,
let's pretend it's something like Commons Resources, but it lives at
MyFaces. Now someone who has been using the JSF RI decides they want to use
Shale as well. It seems pretty odd to me to have to tell them that they
*have to* go get some extra component from another project that is largely
viewed as a competing JSF implementation to the one they're already using.

--
Martin Cooper


Craig
>
>
> --
> > Martin Cooper
> >
> >
> > On 12/8/05, Martin Cooper <martinc@apache.org> wrote:
> > > > On 12/8/05, Sean Schofield <sean.schofield@gmail.com> wrote:
> > > > >
> > > > > I think a jsf-commons project would be nice.  Craig's suggestions
> > > > > certainly make for good candidates.  There are a few in MyFaces
> that
> > > > > would definitely be appropriate as well.
> > > > >
> > > > > For MyFaces the plan is to rename the "share" subproject to
> > "commons"
> > > > > and to start releasing it as its own jar.  In the shortrun I think
> > we
> > > > > should stick with that stuff in MyFaces but in the long run, I
> don't
> > > > > see any problem with moving it to jakarta-commons.  There are a
> few
> > > > > issues to consider (such as committer rights and a different set
> of
> > > > > rules and conventions.)  Perhaps Craig could speak to that more
> > > > > specifically.  Ultimately we are all in the ASF family so maybe it
> > > > > wouldn't be too big of a change.
> > > >
> > > >
> > > > I don't think this would go to Jakarta Commons. It would, however,
> be
> > a
> > > good
> > > > candidate for the Silk subproject, assuming that gets off the
> ground.
> > > (Think
> > > > of Silk as WebApp Commons.) Silk still seems to be pending name
> > > approval,
> > > > but once that gets cleared up, it would be a good place to build
> > > libraries
> > > > that could be shared by Shale, MyFaces, et al.
> > > >
> > > > --
> > > > Martin Cooper
> > > >
> > > >
> > > > I think we'll need to do a careful analysis of the myfaces commons
> > > > > stuff before moving it into jakarta-commons.  I supposed most of
> it
> > is
> > > > > useful beyond creating a JSF implementation b/c the stuff in there
> > is
> > > > > basically stuff that is used for the MyFaces implementation as
> well
> > as
> > > > > the Tomahawk components.  So certainly custom component builders
> > might
> > > > > be interested.
> > > > >
> > > > > Something to consider but IMO there's no rush on this.  We have
> some
> > > > > major infrastructure changes coming up (Maven, zones) and then
> > there's
> > > > > the 1.2 spec.  Plus on the Shale side we're trying to raise the
> > > > > profile of that project and get some releases out the door.
> > > > > Personally I'd rather see a few other things addressed like a "pet
> > > > > shop" type application that would show off MyFaces and Shale
> working
> > > > > together.  I think that would do a lot to help promote the two
> > > > > technologies.
> > > > >
> > > > > sean
> > > > >
> > > > >
> > > > > On 12/8/05, Craig McClanahan <craigmcc@apache.org> wrote:
> > > > > > On 12/8/05, Mike Kienenberger <mkienenb@gmail.com> wrote:
> > > > > > >
> > > > > > > This has come up recently on the Myfaces-dev mailing list.
> > We're
> > > > > > > probably going to be splitting off a "jsf commons" package
at
> > some
> > > > > > > point.   Myfaces/share contains what would probably end
up in
> > such
> > > a
> > > > > > > package.
> > > > > > >
> > > > > > > Do a search for thread "[proposal] myfaces-core.jar" on
the
> > > > > > > myfaces-dev mailing list, Nov 29th to 30th.
> > > > > >
> > > > > >
> > > > > > For the simple kinds of utilities you're describing, hosting
> such
> > a
> > > > > commons
> > > > > > at the MyFaces project would make a lot of sense -- all the
> > > developers
> > > > > there
> > > > > > would be JSF savvy and the users of the JSF implementation,
> and/or
> > > the
> > > > > > components, would both be interested in this kind of stuff.
> > > > > >
> > > > > > On the other hand, if the functionality you are implementing
is
> > very
> > > > > > specific to a framework, the utilities ought to stay with that
> > > > > framwork.  In
> > > > > > the current Shale code, for example, you could argue that the
> > > > > > LoadBundle.java and Messages.java utilities are sufficiently
> > general
> > > > > purpose
> > > > > > that they might fit into a commons (and it would be fine with
me
> > if
> > > the
> > > > > > commons project wanted to copy them) -- but something like
> > > > > > AbstractViewController should stay in Shale because it's
> > fundamental
> > > > > > functionality of the framework.
> > > > > >
> > > > > > AbstractFacesBean.java would be another commons candidate,
> because
> > > it is
> > > > > not
> > > > > > really framework specific.
> > > > > >
> > > > > > Craig
> > > > > >
> > > > > > On 12/8/05, Alexandre Poitras <alexandre.poitras@gmail.com>
> wrote:
> > > > > > > > I was wondering if it would be a good idea to start
a jsf
> > > commons
> > > > > > > > project because every JSF applications seem to use
a class
> > Util
> > > with
> > > > > > > > the same methods or some variants of it (set and get
some
> > > attributes
> > > > > > > > with binding expressions, passthrought some default
> attributes
> > > > > during
> > > > > > > > encoding). What do you think? Would the classes under
the
> > > package
> > > > > util
> > > > > > > > in Shale be good candidates? I would like to contribute
if
> it
> > > starts
> > > > > > > > but I can't write it all by myself because I am still
far
> from
> > > being
> > > > > a
> > > > > > > > JSF expert.
> > > > > >
> > > > > >
> > > > > >
> > > > > > > --
> > > > > > > > Alexandre Poitras
> > > > > > > > Qu├ębec, Canada
> > > > > > > >
> > > > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message