JSF is not a major shift. It is just a way to let tools do the coding for
people who have difficulty with code. It is also not ahead of its time,
unless it has been ahead of its time for a record length of time. It is
just not a very good idea. It is VB for Java web frameworks. Only VB
I agree that its time for Shale to find a new home. I actually think
that living here in the Struts project is holding Shale back more then
its helping at this point. I also feel that Shale is still a little
ahead of its time. JSF is still gaining acceptance and Shale builds
on JSF.
Imagine
This is the same thing except giving the real problem, JSF force fit into
Struts, more importance. This intensifies rather than solves the problem.
Action and JSF are two different web frameworks. That is the bottom line.
Adroit talk, fancy speeches, etc., cannot change that and only serve to
These are not camps of a framework but competing frameworks. That is the
bottom line. Struts is dying and you guys, Gary, are killing it. Why not
man up and get your own space and try to survive on your own?
On 6/21/06, Gary VanMatre [EMAIL PROTECTED] wrote:
From: Ted Husted [EMAIL
I laughed when you were made a committer, Michael. That convinced me that
the end was inevitable. However, this I don't find at all funny. I really
would like to see Struts succeed.
On 6/20/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
On 6/20/06, Don Brown [EMAIL PROTECTED] wrote:
As
Why in the world cannot you people see that JSF just does not fit? Is it
impossible to accept the truth? Would Craig be too angry?
On 6/20/06, Ted Husted [EMAIL PROTECTED] wrote:
Yes, it would be helpful to find a good way to make JSF easier to use
in a conventional Action-based application,
That's right. The problem is the presence of any and all JSF hacks.
On 6/21/06, Alexandru Popescu [EMAIL PROTECTED] wrote:
Hi everybody!
I've read this thread a couple of times, because I was having a
somehow weird sentiment while doing it. Now, I think I have figured it
out :-). So, please
Struts is not advocating a preference? The Orwellian Speak continues.
Struts is Action. Struts is NOT JSF. Struts does not have a preference
because Struts IS one of the alternatives and one of the alternatives is NOT
Struts. I get a kick out of Don calling people willing to state that the
( I send this off list - I hate struts flamewars )
Jack,
you are saying right things to people who fail
to understand them...
Struts was already brain-dead in 2001, and they
will fail to assimilate webwork properly.
(I will be first in line to fork it or apply to
comimter status at
Heh, I have an idea, since JSF is so independent, why don't you start an
open source project for JSF? Then we could see if people really want it and
we could begin to tell what in the h -- e -- l -- l is going on with
Struts.
On 6/21/06, Craig McClanahan [EMAIL PROTECTED] wrote:
The short
You cannot marry a pig and a fox, Don. Let's get honest. The only thing
that is ever going to satisfy Craig is to get the Struts name for JSF,
period. Let him go ahead and try to make it on his own. That won't work
and its failure will keep JSF from continuing its trampy attempt to
integrate
The obvious truth is so easy to state. Thanks, Tim.
On 6/21/06, Tim O'Brien [EMAIL PROTECTED] wrote:
...we're dealing with the ramifications of dismantling Jakarta from years
ago.I actually think that this situation would have never arose if
Struts and Shale were two sibling subprojects
This is so odd. You begin by recognizing the problem and trying to hide
it. Now you deny the problem and want to continue it in spades. Everyone
who knows anything about frameworks sees that these two frameworks are
inherently incompatible. They have been from the start. That is the
problem.
Thanks, Ted. Well said!
On 6/21/06, Ted Husted [EMAIL PROTECTED] wrote:
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
I put this proposal out to help bring us together,
not precipitate a divorce :)
We're not divorcing Tiles. Neither did we divorce any of the
components that now live in
The Front Controller is not really a controller. It is a child's tool for
people who are challenged by OOP and need tool help.
On 6/21/06, Craig McClanahan [EMAIL PROTECTED] wrote:
Comments interspersed.
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
Craig, thanks for your honesty and
The problem is that there is no common ground. Pretence is great, but not
really effective. It will bit you in the butt later.
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
You make a lot of good points, and a strong argument for rallying around
the JSF
flag. To this end, Shale is a great
The success of Spring is not that people like modularity.
On 6/21/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Ted Husted wrote:
So, in addition to including the Action 1.3 JARs in the SAF 2.0
release, essentially, you are suggesting that we also include the
Shale 1.x JARs in the same
It would be impossible to pull off. Since Struts and JSF are inherently
incompatible, there would be a my way or I will run away from home from
Craig and an unwillingness of the Struts community to quit a true controller
based framework. There is no way to make this marriage work.
On 6/21/06,
What is the problem? Who caused it? Bingo! Eureka?
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
Paul Benedict wrote:
I don't see the point in bundling Shale into a Struts 2.0
distribution. No
offense to anyone who develops Shale, but when we have packages called
action2, it makes it
From: Dakota Jack [EMAIL PROTECTED]
These are not camps of a framework but competing frameworks. That is the
bottom line. Struts is dying and you guys, Gary, are killing it. Why not
man up and get your own space and try to survive on your own?
I'm not opposed to Shale moving out if the
On Jun 21, 2006, at 8:31 PM, Ted Husted wrote:
We like to chatter about what's best for Struts, or what Struts is,
but I think the key question is what's Shale, and what's best for
Shale? I remain concerned that, after two years on a greenfield, there
has not been a GA release of Shale. I have
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
Again, Struts Action and Struts Shale would both retain their separate projects,
codebases, and release cycles. Struts 2.0 is about building something on top of
our Struts efforts to create a unified front to users. Users don't care about
all the
On 6/22/06, Wendy Smoak [EMAIL PROTECTED] wrote:
This is going to be short, both because I'm on a deadline and because
I think the important points have already been covered.
I'm not in favor of distributing Shale as a library behind a Struts 2
that promotes the Action 2 controller. Shale's
My 2 cents.
I agree with Don that we have created user confusion by having two
competing frameworks. However I think if we're going to continue to
have both then they should both be first class citizens - rather
than relegating Shale.
Personally, user confusion is secondary IMO to whether the
On 6/22/06, Niall Pemberton [EMAIL PROTECTED] wrote:
P.S. I was at a Sun java roadshow this week - they were putting out
the message that Shale is the next Struts
I've seen this several times. People should clarify what they mean by
this. Is it more like The Queen is dead. Long live the
On 6/22/06, Greg Reddin [EMAIL PROTECTED] wrote:
The problem with moving it is that we have to set
up all the infrastructure to support it. Not just the bureaucracy of
its own TLP and PMC, but the spreading thinner of the people
involved. For example, how many Apache projects can somebody like
On 6/22/06, Hubert Rabago [EMAIL PROTECTED] wrote:
On 6/22/06, Wendy Smoak [EMAIL PROTECTED] wrote:
This is going to be short, both because I'm on a deadline and because
I think the important points have already been covered.
I'm not in favor of distributing Shale as a library behind a
On 6/22/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
In the meantime I want to make sure that SAF1 will not be simply
removed from source repository just because SAF2 is the official
future.
The future belongs to the volunteers willing to do the work. So long
as we have volunteers to work on
Where is lives is less of a concern, but I'd be happy either as a TLP
or as part of MyFaces. I'm very glad that Shale was accepted here
and given time to grow and develop a community, but I think it's time
to find a new home. I'd like to see Struts (the project) return to a
focus on
On 6/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
What about a generic Faces project, like portals or ws ?
Apache Faces.
To me Shale fits fine into that.
There - in an apache faces land - is enough space for:
Myfaces
Tomahawk
Tobago
Shale
Sandbox (well, our sandbox)
and soon Trinidad
To me it makes more sense to have an Apache Faces TLP
with lot's of subprojects.
MyFaces as TLP is sometimes confusing too.
Why all these component libs.
For instance you can't mix Tobago with Tomahawk.
... but you can use Tobago with each JSF impl
so, hey I am +1 for a Apache Faces TLP
and +1
Who would they be? Did anyone notice that Craig resurrected the failing
JSF for Sun? I really like Sun but this has to be the worst thing they have
managed to back.
On 6/22/06, Niall Pemberton [EMAIL PROTECTED] wrote:
My 2 cents.
I agree with Don that we have created user confusion by
I see a lot more than user confusion, Niall. I see total confusion.
On 6/22/06, Niall Pemberton [EMAIL PROTECTED] wrote:
My 2 cents.
I agree with Don that we have created user confusion by having two
competing frameworks. However I think if we're going to continue to
have both then they
I am just trying to figure out how all the movement the last few years fits
into this supposed picture of reality. How does Shale fit into this? How
does WebWorks fit into this? This is mere words without any inkling of the
reality of what happens on Struts.
On 6/22/06, Ted Husted [EMAIL
Hi everybody!
I've read this thread a couple of times, because I was having a
somehow weird sentiment while doing it. Now, I think I have figured it
out :-). So, please bear with me for the short following paragraphs (I
am not a good writer yet):
1. even if I don't know too many details about
If the goal is to separate the life cycles or to share code, then I am
all for it.
But I don't think the end users perception is going to be any different
by this proposed change. The question is still going to be are we
going to use a JSF or action framework? Struts is not advocating a
The short answer is that no, as long as I have any say in it, Shale will not
morph to be dependent on Action2. SAF2 is too heavyweight and too
complexfor my tastes (see below for more about that remark), besdes the fact
that it implements a lot of stuff that is redundant to what is already part
On 6/21/06, Craig McClanahan [EMAIL PROTECTED] wrote:
If that means a (hopefully amicable) divorce, then so be it.
If that's what the people working on Shale want, I doubt that the PMC
would oppose a change of venue.
If that is the case, then the next question would be whether Shale
would be
Craig, thanks for your honesty and candor. I know this is a delicate
topic, and I appreciate you approaching the topic openly.
A couple of clarifications:
1. I'm not proposing Shale _ever_ depend on Action 2, only that they
should work well together. In fact, I mean to start including
One other point of clarification I forgot - this proposal would have no effect
on the Struts Shale project from a code or release perspective. The Struts
Shale project would continue, put out its releases, and continue to support JSF
applications.
I'm really only suggesting we wrap it all
...we're dealing with the ramifications of dismantling Jakarta from years
ago.I actually think that this situation would have never arose if
Struts and Shale were two sibling subprojects in a larger Jakarta project.
But, the Board spoke years ago, and umbrella projects were broken up because
Tim O'Brien wrote:
There is obviously a good deal
of exchange, but the frameworks compete (not my words).
While this may be true politically, from a code perspective, I completely
disagree. Just about every feature of Shale, AFAIK can easily be used with
Action 2: Spring integration, clay,
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
I put this proposal out to help bring us together,
not precipitate a divorce :)
We're not divorcing Tiles. Neither did we divorce any of the
components that now live in the commons. We believed each of these
codebase could attract a larger
Comments interspersed.
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
Craig, thanks for your honesty and candor. I know this is a delicate
topic, and I appreciate you approaching the topic openly.
LIkewise ... I may have sounded a bit grumpy in my response, but I don't
ascribe any
You make a lot of good points, and a strong argument for rallying around the JSF
flag. To this end, Shale is a great idea and provides a nice realization of
this approach. Undoubtedly, there are many developers who think similarly and
may not ever be interested in the Action 2 controller, and
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
And this is why Shale needs to continue, and I'd argue, continue to exist as
part of the larger Struts community, and a step further, under a larger Struts
2.0 product. I think despite providing multiple alternatives and solutions,
there is a
At 3:22 PM -0400 6/21/06, Ted Husted wrote:
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
And this is why Shale needs to continue, and I'd argue, continue to exist as
part of the larger Struts community, and a step further, under a
larger Struts
2.0 product. I think despite providing
Ted Husted wrote:
So, in addition to including the Action 1.3 JARs in the SAF 2.0
release, essentially, you are suggesting that we also include the
Shale 1.x JARs in the same distribution, so that anyone obtaining SAF2
can use Action 1, Action 2, and/or Shale 1?
Even though Don hasn't answered
I'm suggesting something bigger: Struts 2.0. This release will come with SAF2,
Shale, Tags, and maybe Action 1.x for legacy reasons. We would continue to
develop SAF2, Shale, and Tags, but the world would just need to see Struts 2.0.
Its documentation will tie the projects together and
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
I'm suggesting something bigger: Struts 2.0. This release will come with
SAF2,
Shale, Tags, and maybe Action 1.x for legacy reasons. We would continue
to
develop SAF2, Shale, and Tags, but the world would just need to see Struts
2.0.
Its
Craig McClanahan wrote:
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
I'm suggesting something bigger: Struts 2.0. This release will come with
SAF2,
Shale, Tags, and maybe Action 1.x for legacy reasons. We would continue
to
develop SAF2, Shale, and Tags, but the world would just need to see
My quick thoughts: I think realistically either of the following two outcomes
are positive developments for everyone:
1) We move in the direction of Struts 2.0, which houses all SAF2 and Shale
and get back for it being OK for folks to say, I use Struts. We've all said
we want to work together
I don't see the point in bundling Shale into a Struts 2.0 distribution. No
offense to anyone who develops Shale, but when we have packages called
action2, it makes it pretty clear Shale is not Struts 2.0 -- only the action
framework. Separate frameworks, imo, get different names and
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
It goes back to Struts' roots as a single solution for web development needs.
:) Hmmm, I think you would need to look to Matt Raible's stuff for that :)
Historically, people always *wanted* Struts to be a single solution,
but we always tried to
On 6/21/06, Patrick Lightbody [EMAIL PROTECTED] wrote:
2) Shale becomes a TLP. We continue to share code and ideas where it makes
sense,
Or, in other words, the same relationship we have with XWork, OGNL,
FreeMarker, JasperReports, and Dojo.
-Ted.
Ted Husted wrote:
If we wanted Struts 2.0 to be a true omnibus product, then it should
include a data access solution, a data indexing solution, a menuing
solution, a security solution, a wizard solution, and an (even better)
AJAX solution. We're not even coming close to bundling everything a
Paul Benedict wrote:
I don't see the point in bundling Shale into a Struts 2.0 distribution. No
offense to anyone who develops Shale, but when we have packages called
action2, it makes it pretty clear Shale is not Struts 2.0 -- only the action
framework. Separate frameworks, imo, get different
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
Paul Benedict wrote:
I don't see the point in bundling Shale into a Struts 2.0 distribution. No
offense to anyone who develops Shale, but when we have packages called
action2, it makes it pretty clear Shale is not Struts 2.0 -- only the action
Don, I suppose I generally agree with you I guess. The problem is, which
always seems to be the case here in this group, is that every year someone is
trying to answer the question: What is Struts really about? At first it was
an action framework, and then it was a JSF framework, and then
On 6/21/06, Don Brown [EMAIL PROTECTED] wrote:
Again, Struts Action and Struts Shale would both retain their separate projects,
codebases, and release cycles. Struts 2.0 is about building something on top of
our Struts efforts to create a unified front to users. Users don't care about
all the
As Shale and Action zero in on their first GA release, I don't think it is too
late to ask the question, Does Struts really need two frameworks? We have
been putting out the message, two frameworks, one community, for almost a year
now, but I still sense a lot of confusion and even rejection
On 6/20/06, Don Brown [EMAIL PROTECTED] wrote:
As Shale and Action zero in on their first GA release, I don't think it is too
late to ask the question, Does Struts really need two frameworks?
I bet DJ and JR are laughing their asses off.
Just last week I was talking to another senior architect at my company,
and he was asking me how a developer knows what they should get when
they go to the Struts site? He was asking me what Struts was at this
point. It was more than just a navigation issue, he thought there was a
very
On 6/20/06, Don Brown [EMAIL PROTECTED] wrote:
As Shale and Action zero in on their first GA release, I don't think it is too
late to ask the question, Does Struts really need two frameworks? We have
been putting out the message, two frameworks, one community, for almost a year
now, but I still
Yes, it would be helpful to find a good way to make JSF easier to use
in a conventional Action-based application, much the same way we are
trying to make Ajax easier to use in SAF2.
Our first attempt (as a project) at JSF/Action integration was the
Struts JSF taglib. The promise here was to
Ted Husted wrote:
As for making the UI tags an independant extension, a al Tiles, that
sounds good too. (Even better if we include the value added Ajax
support.) But I don't know if we want to hold back the SAF 2.0.0 to
make it happen. But, for phase 2, sure!
Actually, I'm thinking splitting off
66 matches
Mail list logo
