[shale] jsf-commons??

[Alexandre Poitras <al...@gmail.com>]

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

Re: [shale] jsf-commons??

[Mike Kienenberger <mk...@gmail.com>]

On 12/12/05, Hubert Rabago <hr...@gmail.com> wrote:
> Some of the code that's an integral part of Struts are in commons,
> such as BeanUtils and Chain.  If the shared code is not
> tomahawk/myfaces specific, then this sounds like more reason to put
> this in a "commons"-type package.  It sounds like anyone out there
> building in-house components might be able to use the package.  It
> might benefit as well from the additional exposure.

Yes, that's what we're discussing.   MyFaces is likely going to be
releasing this as a "shared" or "commons" jar in the future.    In
some ways, you can look at tomahawk as a demo or example set of the
shared component-building library :)


On 12/12/05, Martin Cooper <ma...@apache.org> wrote:
> You're still not understanding what I'm saying. I'm talking about a
> situation in which someone wants to use Shale with the RI and it *will not
> work* without some extra pieces from MyFaces. That doesn't make sense to me,
> and it's not going to go over well with some organisations that want to
> standardise on the RI.

I understand what you're saying.  Maybe you're not understanding my
reply.   You can use Tomahawk (and the underlying shared component
jar) without using the MyFaces implementation.    End-users already
use tomahawk components with the RI.   Tomahawk is
JSF-implementation-agnostic, and so is the underlying shared code.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] jsf-commons??

[Martin Cooper <ma...@apache.org>]

On 12/12/05, Mike Kienenberger <mk...@gmail.com> wrote:
>
> On 12/9/05, Martin Cooper <ma...@apache.org> wrote:
> > 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.
>
> MyFaces is both a "completing" JSF implementation (Myfaces impl) and
> also one of the largest 3rd-party add-ons of extra functionality
> (components, validators) for all JSF implementations
> (Tomahawk/Sandbox).    So it's not quite that unusual.   After all,
> people come to the Struts project to get Shale or Tiles, even though
> they're not using the "competing" Struts framework.


You're still not understanding what I'm saying. I'm talking about a
situation in which someone wants to use Shale with the RI and it *will not
work* without some extra pieces from MyFaces. That doesn't make sense to me,
and it's not going to go over well with some organisations that want to
standardise on the RI.

--
Martin Cooper


The shared code in tomahawk is primarily for building components
> better and easier.   It certainly makes the most sense to keep this
> code with Tomahawk since it's an integral part of all tomahawk
> components.
>
> There's probably a certain class of sharable code that's not closely
> tied to anything else (end-user utility functions) and could be put
> into any project: shale, tomahawk, or a new jsf-commons.   The shale
> base backing bean class is a good example of this.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: [shale] jsf-commons??

[Hubert Rabago <hr...@gmail.com>]

On 12/12/05, Mike Kienenberger <mk...@gmail.com> wrote:

> The shared code in tomahawk is primarily for building components
> better and easier.   It certainly makes the most sense to keep this
> code with Tomahawk since it's an integral part of all tomahawk
> components.

Some of the code that's an integral part of Struts are in commons,
such as BeanUtils and Chain.  If the shared code is not
tomahawk/myfaces specific, then this sounds like more reason to put
this in a "commons"-type package.  It sounds like anyone out there
building in-house components might be able to use the package.  It
might benefit as well from the additional exposure.

Hubert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] jsf-commons??

[Mike Kienenberger <mk...@gmail.com>]

On 12/9/05, Martin Cooper <ma...@apache.org> wrote:
> 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.

MyFaces is both a "completing" JSF implementation (Myfaces impl) and
also one of the largest 3rd-party add-ons of extra functionality
(components, validators) for all JSF implementations
(Tomahawk/Sandbox).    So it's not quite that unusual.   After all,
people come to the Struts project to get Shale or Tiles, even though
they're not using the "competing" Struts framework.

The shared code in tomahawk is primarily for building components
better and easier.   It certainly makes the most sense to keep this
code with Tomahawk since it's an integral part of all tomahawk
components.

There's probably a certain class of sharable code that's not closely
tied to anything else (end-user utility functions) and could be put
into any project: shale, tomahawk, or a new jsf-commons.   The shale
base backing bean class is a good example of this.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] jsf-commons??

[Martin Cooper <ma...@apache.org>]

On 12/9/05, Craig McClanahan <cr...@apache.org> wrote:
>
> On 12/8/05, Martin Cooper <ma...@apache.org> wrote:
> >
> > On 12/8/05, Mike Kienenberger <mk...@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 <ma...@apache.org> wrote:
> > > > On 12/8/05, Sean Schofield <se...@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 <cr...@apache.org> wrote:
> > > > > > On 12/8/05, Mike Kienenberger <mk...@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 <al...@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
> > >
> > >
> >
> >
>
>

Re: [shale] jsf-commons??

[Craig McClanahan <cr...@apache.org>]

On 12/8/05, Martin Cooper <ma...@apache.org> wrote:
>
> On 12/8/05, Mike Kienenberger <mk...@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.

Craig


--
> Martin Cooper
>
>
> On 12/8/05, Martin Cooper <ma...@apache.org> wrote:
> > > On 12/8/05, Sean Schofield <se...@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 <cr...@apache.org> wrote:
> > > > > On 12/8/05, Mike Kienenberger <mk...@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 <al...@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
> >
> >
>
>

Re: [shale] jsf-commons??

[Martin Cooper <ma...@apache.org>]

On 12/8/05, Mike Kienenberger <mk...@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...

--
Martin Cooper


On 12/8/05, Martin Cooper <ma...@apache.org> wrote:
> > On 12/8/05, Sean Schofield <se...@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 <cr...@apache.org> wrote:
> > > > On 12/8/05, Mike Kienenberger <mk...@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 <al...@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
>
>

Re: [shale] jsf-commons??

[Mike Kienenberger <mk...@gmail.com>]

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.

On 12/8/05, Martin Cooper <ma...@apache.org> wrote:
> On 12/8/05, Sean Schofield <se...@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 <cr...@apache.org> wrote:
> > > On 12/8/05, Mike Kienenberger <mk...@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 <al...@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

Re: [shale] jsf-commons??

[Martin Cooper <ma...@apache.org>]

On 12/8/05, Sean Schofield <se...@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 <cr...@apache.org> wrote:
> > On 12/8/05, Mike Kienenberger <mk...@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 <al...@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
>
>

Re: [shale] jsf-commons??

[Sean Schofield <se...@gmail.com>]

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 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 <cr...@apache.org> wrote:
> On 12/8/05, Mike Kienenberger <mk...@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 <al...@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

Re: [shale] jsf-commons??

[Craig McClanahan <cr...@apache.org>]

On 12/8/05, Mike Kienenberger <mk...@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 <al...@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
>
>

Re: [shale] jsf-commons??

[Mike Kienenberger <mk...@gmail.com>]

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.

On 12/8/05, Alexandre Poitras <al...@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