You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by dusty <du...@yahoo.com> on 2008/10/19 08:32:24 UTC
Concerned Strutszien: A Manifesto
Struts1 is arguably the most successful web framework, but it always felt
heavy. It's how I found WebWork, which I am convinced is the greatest web
framework. When WebWork made the move to Apache as Struts 2, I was excited
since it meant this great framework would continue on after the great work
by Jason and Patrick after Rickard's original masterpiece (I am sure there
are others but those are the ones I know).
So now we have been Struts 2 since Jan 29, 2007. I think there have been
great improvements during its almost two year stay, but I worry that
recently the project suffers from either two many cooks or not enough
generals. I know I am barely good enough to use Struts2, so I am certainly
not nominating myself as any kind of solution, but I wonder if others share
my worries.
We all use Struts2 because it is such a powerful and flexible framework. It
makes many more patterns easy than it makes hard and is fairly easy to
understand at the level you need to be useful with it. But we commit to
Struts2 because we believe it has a future and because many others like us
believe that too.
In order for this to be true, Struts2 needs to progress with a unified
vision and efficient releases that move the platform forward. There is lots
of competition out there, Rails, Grails, Spring MVC, Wicket, Stripes, Seam
among a 100 others. I think Struts2 is positioned to capture a large part
of that market but I also think there are things that need to be addressed
to do so:
* OGNL - Is is staying? Is it going? Can it be secure? Is it fast enough?
* Convention - Buzz factor to me, but buzz none the less. I type pretty
fast.
* REST - Great way to organize web based applications
* Lower Level Customization Documentation - ActionMapper, Configuration
Manager, Plugin Patterns -- How to get the most out of Struts2 by
understanding not only how it works but how customize it to meet your needs.
* Model and Service Layer - We know Struts2 is a web framework and its good
at it. So there is Appfuse and that is something I have worked on.
Stripping down Appfuse and hopefully making some kind of Groovy-based Model,
Service, Action, View generator. More on that here:
http://www.nabble.com/RE%3A-Getting-ready-for-Struts-2.1.1-td17446803s2369.html#a17461105.
I think the plan is good, but I haven't done as much as I need to yet
* AJAX - Never been a fan of the Dojo tags -- DWR? Prototype/Scriptaculous?
JQuery? I used proto and scriptac for a while but I have moved to JQuery
recently.
* Stable and public API to keep backward compatibility
* Portlets are still first class citizens?
How do we tackle all this? Do we have a meeting? Do we create a Chief who
can make decisions for better or for worse? Clearly decisions need to be
made. Do we start StrutsCon 2009 and lock everyone in a room until the
decisions are made? I started to also write apps in Rails and I promised
myself I would learn Grails to stay current, but judging from Phillip's
session at JavaOne and the traffic on the mailing list there is still A LOT
of interest in S2. Ideas? Volunteers? Beueller?
"So little to do and so much time. Wait. Strike that. Reverse it."
-Willy Wonka
http://www.nabble.com/-s2--2.1-to-2.5-Roadmap-discussions-td17585419.html#a17585419
http://www.nabble.com/-s2--Roadmap-%28was-Tag-it-and-Roll-it-%29-td5474867.html#a5474867
--
View this message in context: http://www.nabble.com/Concerned-Strutszien%3A-A-Manifesto-tp20053620p20053620.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Al Sutton <al...@alsutton.com>.
>> * REST - Great way to organize web based applications
>>
>
>
> Nobody is working on this right?
>
>
I'm not working on it, but I have a few projects deployed using it, so i
would wonder if it needs
much in the way of work (if any at all).
Al.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Musachy Barroso <mu...@gmail.com>.
>
>
> * OGNL - Is is staying? Is it going? Can it be secure? Is it fast enough?
>
Params interceptor was the biggest security problem and it has been patched.
It MVEL gets integrated then it will get interesting.
>
> * Convention - Buzz factor to me, but buzz none the less. I type pretty
> fast.
It is coming, we need to get 2.1 out and I need to rewrite some ugly patch I
wrote for multiple unknown handlers.
>
> * REST - Great way to organize web based applications
Nobody is working on this right?
>
> * Model and Service Layer - We know Struts2 is a web framework and its good
> at it. So there is Appfuse and that is something I have worked on.
> Stripping down Appfuse and hopefully making some kind of Groovy-based
> Model,
> Service, Action, View generator. More on that here:
>
> http://www.nabble.com/RE%3A-Getting-ready-for-Struts-2.1.1-td17446803s2369.html#a17461105
> .
> I think the plan is good, but I haven't done as much as I need to yet
>
My poor man's version of it: http://code.google.com/p/strutson/ . I use it
for new projects and it kind of works.
>
> * AJAX - Never been a fan of the Dojo tags -- DWR?
> Prototype/Scriptaculous?
> JQuery? I used proto and scriptac for a while but I have moved to JQuery
> recently.
>
kill -9 DojoPlugin
>
> * Stable and public API to keep backward compatibility
Stale
>
> * Portlets are still first class citizens?
I am no a user of them myself, but I see Nils answering questions and fixing
bugs, so I think they still are.
>
> How do we tackle all this? Do we have a meeting? Do we create a Chief who
> can make decisions for better or for worse? Clearly decisions need to be
> made. Do we start StrutsCon 2009 and lock everyone in a room until the
> decisions are made? I started to also write apps in Rails and I promised
> myself I would learn Grails to stay current, but judging from Phillip's
> session at JavaOne and the traffic on the mailing list there is still A LOT
> of interest in S2. Ideas? Volunteers? Beueller?
>
These are my 2 pesos on what the problem is. As I have seen so far, all
these things get sorted out as people pick up things that they are
interested in, but, in order to move we need builds/releases and we need
them often. Without build, changes go to trunk and stay there for a long
time (sometimes, years) without getting released, and either the people
working on them lose interest, or the discussions get stale. In short: we
need people to roll releases often. As I type this my conscience is
screaming at me: "why haven't you done it? you could do it instead of asking
for it, shame on you" :)
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
Re: Concerned Strutszien: A Manifesto
Posted by dusty <du...@yahoo.com>.
Thanks Frank! Your comments are appreciated and obviously well thought out.
> What is there in S2 to truly excite Web 2.0
>developers in S2 as compared to other frameworks?
Hmmm. From what I can tell you are describing Web 2.0 in terms of
client-heavy scripting language driven websites. In my experience these
are sites that are built with amazing speed and feature the latest in
front-end usability. So developers of these applications value speed and
visual impact. There will always be a place for this sort of development
and S2 is not really in that game. In fact, I think S2 should take a step
back from its recent attempts to get in that game (*ahem* *dojo* *cough*).
Struts2 is the best Java-based framework for building applications intended
to survive the test of time. In my experience the applications I create
with S2 require significant architectural thought and planning. Not because
I am using S2, but because the business problem is unique or challenging.
S2 provides me with an unmatchable toolkit to attack just about any
requirement I may encounter involving HTTP requests. The time it takes me
to write XML config or get CRUD operations up and running for basic domain
objects is insignificant compared to the time I spend working on the really
tough integration issues that most business applications face.
So I guess I was less worried about adoption by developers focused on the
arms race to generate CRUD screens at developer conferences and more about
the overall cohesion and survivability of the S2 code base and community
supporting it. If the community was depleted then I figured we needed to
improve our marketing to gain adoption by the level of engineers we have
been lucky enough to have as committers so far.
I think there is a rather long and steep learning curve for S2 and the
related technologies (Hibernate, Spring, Acegi, etc). I personally don't
think that is a bad thing but I think that road to the top of that curve can
be and will be made more clear. There are some tools that help like
Appfuse, JCatapult, StrutsOn or Dusty's Awesome Starter Kit but nothing that
has been built by the S2 community for the S2 community.
I am encouraged by all the responses. One immediate result may be the
creation of a streamlined build process! There is also interest in
improving the documentation and examples used to teach S2 to the new
developers we hope to hand stuff off to so we can move on to something else
;-). I think the future is bright for S2 because it has a talented and
active community as well as an organized and modular code base.
So I am glad you asked the question, but I think its difficult to answer
depending on the context of Web 2.0 developers. I think I would say, "There
has been a burst of frameworks created that focus on speed and/or visual
impact. This is good in that it democratizes the creation of data driven
web applications. Lets call it the VB-Web-Effect or just VisualWeb for
short. S2 would not appeal to the typical VW developer because its focus is
lower level with entirely different goals. There may be fewer S2 apps as
the number of VW frameworks and apps explode. But by their nature, S2 apps
will be more robust and sustainable then their disposable script-based
cousins."
Frank W. Zammetti wrote:
>
> dusty wrote:
>> So we get more aggressive with our releases. We definitely want to
>> preserve
>> compatibility but if we have a good reason for breaking compatibility we
>> let
>> people know and show them how to migrate. At the same time we get more
>> aggressive with marketing, by overhauling the website, getting the
>> project
>> blog going, re-organizing the wiki and documentation, getting the source
>> available from Fisheye, maybe even start a conference. Everything but
>> the
>> conference part seems pretty doable.
>>
> I for one don't think S2 needs any marketing, or a web site overhaul, or
> any of that sort of thing. I can't think of too many projects that have
> become a big-time success based on that sort of thing... in fact, JSF is
> one great counter-example to that theory. Many people got turned off to
> JSF early because for a long time it was nothing but marketing hype. It
> basically took people stopping the hype train for a while and actually
> churning out some half-way decent technology for it to be seen as
> something more at this point.
>
> I think in terms of die-hard Struts developers, there's decent buy-in
> for S2. I think many Struts developers are migrating to S2 (not
> necessarily migrating existing apps, but in terms of new development).
> Where I get the impression there's a shortcoming is in attracting new
> developers.
>
> Assuming that's true, the question should be why that is... why are
> other frameworks gaining mindshare while S2 maybe isn't (or at least not
> as fast as it should be given its lineage and Apache branding, which is
> still a big positive for any project). I think the answer is twofold.
>
> First, in terms of what S2 offers, frankly, there's not really a whole
> lot that truly excites developers. There's nothing revolutionary about
> it. Some would say that's a positive, and part of me would agree, but
> when there's so many frameworks to choose from, if you don't have
> anything that truly differentiates your offering then it's just going to
> be one more option among many.
>
> I think however that there's a really more fundamental problem that
> isn't S2's fault at all: many new development projects, maybe even most
> at this point, are (buzzword alert!) Web 2.0 in nature. They are much
> more client-heavy and just fundamentally work differently than what
> Struts has historically been used to build (yes, that's a generality to
> be sure, but I think it is, *generally*, true). If you buy that theory,
> then you have to reasonably ask what does S2 offer to make developing
> those types of applications easier?
>
> And then when you have an answer to that question you have to compare it
> to other frameworks that people are using for applications of that
> nature. Things like ZK, GWT, JSF, Rails, and so on. You can even
> compare it to using something like Dojo or Ext JS with a more
> lightweight back-end based on something like DWR. Does S2 give me
> something tangible compared to those? Does it fundamentally make my job
> easier, or my application better? If you are unable to articulate
> really clearly and strongly and in a demonstratable fashion where S2
> helps in this regard, then I believe it's a losing proposition.
>
> To be sure, there *are* some cool things in S2. What I for one don't
> see, and I've heard a similar feeling expressed by many as recently as
> at The Ajax Experience earlier this month, is a clear, coherent vision
> of how S2 lets me develop these so-called Web 2.0 applications better
> than any other framework. What is there in S2 to truly excite Web 2.0
> developers in S2 as compared to other frameworks? That to me is the
> fundamental question to be answered, and the fundamental reason S2
> doesn't have the uptake many feel it should. I hesitate to put it this
> way because it seems potentially unfair, but I'll say it anyway: it's
> almost like S2 is standing on the sidelines while the web development
> world moves in a fundamentally different direction, and S2 isn't keeping
> up as well as it needs to in order to be the success S1 was.
>
> Please understand I'm not at all being critical of S2 or of anyone
> involved in it. These are my impressions of things, but they are in
> part based on conversations I've had with other developers expressing
> similar thoughts, so I know it's not just me. My hope is that something
> constructive can come from these comments, and that's certainly my
> purpose in taking the time to write this reply.
>
> Frank
>
> --
> Frank W. Zammetti
> Author of "Practical Dojo Projects"
> and "Practical DWR 2 Projects"
> and "Practical JavaScript, DOM Scripting and Ajax Projects"
> and "Practical Ajax Projects With Java Technology"
> (For info: apress.com/book/search?searchterm=zammetti&act=search)
> My "look ma, I have a blog too!" blog: zammetti.com/blog
>
>
>> Don has been a kind of de-facto leader for the project. I wonder what he
>> is
>> thinking.....
>>
>>
>>
>> Jeromy Evans - Blue Sky Minds wrote:
>>
>>> I share similar sentiment. Whenever I take a critical look as to whether
>>> to use struts2 I keep coming back to the conclusion that it's
>>> fundamentally sound as far as java frameworks go.
>>> I'd categorize the problem as not enough generals. Most of us can make
>>> incremental improvements or start new plugins but few have the courage
>>> to to drive through fundamental changes or remove features. I'd join
>>> some kind of coordinated hack-a-thon to break through the inertia.
>>>
>>> My #1 issue is that it's *too difficult and time-consuming to create a
>>> release* on the 2.1 trunk. If releases are difficult and dependent on a
>>> few key individuals then momentum slows and the project inevitably
>>> stalls.
>>>
>>> I've been independently tinkering with release process to try to
>>> automate all assembly within a CI system so a formal release is an
>>> administrative process only, but it's not much fun.
>>>
>>>
>>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Concerned-Strutszien%3A-A-Manifesto-tp20053620p20159172.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Ian Roughley <ia...@fdar.com>.
> To be sure, there *are* some cool things in S2. What I for one don't
> see, and I've heard a similar feeling expressed by many as recently as
> at The Ajax Experience earlier this month, is a clear, coherent vision
> of how S2 lets me develop these so-called Web 2.0 applications better
> than any other framework. What is there in S2 to truly excite Web 2.0
> developers in S2 as compared to other frameworks? That to me is the
> fundamental question to be answered, and the fundamental reason S2
> doesn't have the uptake many feel it should. I hesitate to put it
> this way because it seems potentially unfair, but I'll say it anyway:
> it's almost like S2 is standing on the sidelines while the web
> development world moves in a fundamentally different direction, and S2
> isn't keeping up as well as it needs to in order to be the success S1
> was.
I would agree to this. I would also suggest that for all the core team
(for me at least) there is limited time to commit to the project, and
unclear feature direction. Regular releases come not only from a smooth
release process, but also having enough new feature and bugs resolves to
warrant it :-) With limited time to devote to a project, having
cohesion on the features being worked on, and having multiple developers
work on them to completion, seems like a better alternative than having
everyone work on their "pet" feature, whenever they have time (that
exponential decreases).
Just my thoughts...
/Ian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
dusty wrote:
> So we get more aggressive with our releases. We definitely want to preserve
> compatibility but if we have a good reason for breaking compatibility we let
> people know and show them how to migrate. At the same time we get more
> aggressive with marketing, by overhauling the website, getting the project
> blog going, re-organizing the wiki and documentation, getting the source
> available from Fisheye, maybe even start a conference. Everything but the
> conference part seems pretty doable.
>
I for one don't think S2 needs any marketing, or a web site overhaul, or
any of that sort of thing. I can't think of too many projects that have
become a big-time success based on that sort of thing... in fact, JSF is
one great counter-example to that theory. Many people got turned off to
JSF early because for a long time it was nothing but marketing hype. It
basically took people stopping the hype train for a while and actually
churning out some half-way decent technology for it to be seen as
something more at this point.
I think in terms of die-hard Struts developers, there's decent buy-in
for S2. I think many Struts developers are migrating to S2 (not
necessarily migrating existing apps, but in terms of new development).
Where I get the impression there's a shortcoming is in attracting new
developers.
Assuming that's true, the question should be why that is... why are
other frameworks gaining mindshare while S2 maybe isn't (or at least not
as fast as it should be given its lineage and Apache branding, which is
still a big positive for any project). I think the answer is twofold.
First, in terms of what S2 offers, frankly, there's not really a whole
lot that truly excites developers. There's nothing revolutionary about
it. Some would say that's a positive, and part of me would agree, but
when there's so many frameworks to choose from, if you don't have
anything that truly differentiates your offering then it's just going to
be one more option among many.
I think however that there's a really more fundamental problem that
isn't S2's fault at all: many new development projects, maybe even most
at this point, are (buzzword alert!) Web 2.0 in nature. They are much
more client-heavy and just fundamentally work differently than what
Struts has historically been used to build (yes, that's a generality to
be sure, but I think it is, *generally*, true). If you buy that theory,
then you have to reasonably ask what does S2 offer to make developing
those types of applications easier?
And then when you have an answer to that question you have to compare it
to other frameworks that people are using for applications of that
nature. Things like ZK, GWT, JSF, Rails, and so on. You can even
compare it to using something like Dojo or Ext JS with a more
lightweight back-end based on something like DWR. Does S2 give me
something tangible compared to those? Does it fundamentally make my job
easier, or my application better? If you are unable to articulate
really clearly and strongly and in a demonstratable fashion where S2
helps in this regard, then I believe it's a losing proposition.
To be sure, there *are* some cool things in S2. What I for one don't
see, and I've heard a similar feeling expressed by many as recently as
at The Ajax Experience earlier this month, is a clear, coherent vision
of how S2 lets me develop these so-called Web 2.0 applications better
than any other framework. What is there in S2 to truly excite Web 2.0
developers in S2 as compared to other frameworks? That to me is the
fundamental question to be answered, and the fundamental reason S2
doesn't have the uptake many feel it should. I hesitate to put it this
way because it seems potentially unfair, but I'll say it anyway: it's
almost like S2 is standing on the sidelines while the web development
world moves in a fundamentally different direction, and S2 isn't keeping
up as well as it needs to in order to be the success S1 was.
Please understand I'm not at all being critical of S2 or of anyone
involved in it. These are my impressions of things, but they are in
part based on conversations I've had with other developers expressing
similar thoughts, so I know it's not just me. My hope is that something
constructive can come from these comments, and that's certainly my
purpose in taking the time to write this reply.
Frank
--
Frank W. Zammetti
Author of "Practical Dojo Projects"
and "Practical DWR 2 Projects"
and "Practical JavaScript, DOM Scripting and Ajax Projects"
and "Practical Ajax Projects With Java Technology"
(For info: apress.com/book/search?searchterm=zammetti&act=search)
My "look ma, I have a blog too!" blog: zammetti.com/blog
> Don has been a kind of de-facto leader for the project. I wonder what he is
> thinking.....
>
>
>
> Jeromy Evans - Blue Sky Minds wrote:
>
>> I share similar sentiment. Whenever I take a critical look as to whether
>> to use struts2 I keep coming back to the conclusion that it's
>> fundamentally sound as far as java frameworks go.
>> I'd categorize the problem as not enough generals. Most of us can make
>> incremental improvements or start new plugins but few have the courage
>> to to drive through fundamental changes or remove features. I'd join
>> some kind of coordinated hack-a-thon to break through the inertia.
>>
>> My #1 issue is that it's *too difficult and time-consuming to create a
>> release* on the 2.1 trunk. If releases are difficult and dependent on a
>> few key individuals then momentum slows and the project inevitably stalls.
>>
>> I've been independently tinkering with release process to try to
>> automate all assembly within a CI system so a formal release is an
>> administrative process only, but it's not much fun.
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Dave Newton <ne...@yahoo.com>.
--- On Wed, 10/22/08, Philip Luppens wrote:
> Javadoc makes a very poor format for creating example code;
Not in JavaDoc, as Java/JSP/FreeMarker/etc. and pulled in to the wiki via snippets. That way they're examples that actually work.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Philip Luppens <ph...@gmail.com>.
On Wed, Oct 22, 2008 at 8:45 PM, Dave Newton <ne...@yahoo.com> wrote:
> --- On Wed, 10/22/08, Philip Luppens wrote:
>> - Documentation: no more (example) documentation in the
>> Javadocs so non-committers can make changes in the wiki.
>
> I'd augment this a bit
>
> I'd really like all the examples to be in source control and have associated tests, and I'm willing to spend some effort to do that (starting at the beginning of 2009; this year is packed).
>
> Yes, that means that either non-committers can't write "official" examples, although un-official examples would be supported--as they are now--on the wiki. I don't see a whole lot of non-developer-driven examples, however, although they exist.
>
> We're still hammered by documentation (2.0 v. 2.1 issues) and I'd *really* like to see two Confluence spaces for that. Yeah, I know 2.1 is (in theory) rolling soon, but not everyone may upgrade right away. I'm also willing to put some work into that.
>
> I agree with one of the initial statements that the documentation could be better organized, although I think that could be handled with some aggregate pages that organize existing documentation in different (hopefully better) ways.
>
> I also like the tags being documented through the annotations, but either the annotations or the processing tool should include some information regarding when attributes were introduced etc.
>
> Dave
At the risk of going out of scope with this discussion (there was a
thread a couple of months ago about this), just some thoughts:
Javadoc makes a very poor format for creating example code; esp. in
combination with the escaping of tags - xml configuration for example
is pretty hard to get correct on the first commit. So no, keep the
best tool for the job: code examples and configuration in the wiki,
the javadocs in the source code. If you really want 'official
examples' then just limit the people that can edit the page.
Btw, regarding the static export of pages: when looking for
documentation through google, I always end up at hopelessly outdated
versions - even though various newer version exists, often with
corrections and new content. Very annoying and confusing for everyone
consulting the documentation.
Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"We cannot change the cards we are dealt, just how we play the hand."
- Randy Pausch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Dave Newton <ne...@yahoo.com>.
--- On Wed, 10/22/08, Philip Luppens wrote:
> - Documentation: no more (example) documentation in the
> Javadocs so non-committers can make changes in the wiki.
I'd augment this a bit
I'd really like all the examples to be in source control and have associated tests, and I'm willing to spend some effort to do that (starting at the beginning of 2009; this year is packed).
Yes, that means that either non-committers can't write "official" examples, although un-official examples would be supported--as they are now--on the wiki. I don't see a whole lot of non-developer-driven examples, however, although they exist.
We're still hammered by documentation (2.0 v. 2.1 issues) and I'd *really* like to see two Confluence spaces for that. Yeah, I know 2.1 is (in theory) rolling soon, but not everyone may upgrade right away. I'm also willing to put some work into that.
I agree with one of the initial statements that the documentation could be better organized, although I think that could be handled with some aggregate pages that organize existing documentation in different (hopefully better) ways.
I also like the tags being documented through the annotations, but either the annotations or the processing tool should include some information regarding when attributes were introduced etc.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Philip Luppens <ph...@gmail.com>.
On Wed, Oct 22, 2008 at 4:20 AM, dusty <du...@yahoo.com> wrote:
>
> So the more I think about it the more thoughts I have....
>
> The major users like Atlassian and Google forked Webwork a while ago I think
> and they don't run their stuff off the Struts2 code base. Don has been
> awesome for Struts2, but I don't know if there are any other commiters from
> Atlassian or Google. Alexandru uses Webwork for InfoQ, and I am not sure if
> he ever moved to Struts2 either. I am not sure what Patrick and Jason are
> doing these days but we have a large population of WebWork people that seem
> to have not moved to the Struts side of the world. I don't know if that
> matters or not. As long as we have enough smart people, and we do, to keep
> things going in the right direction. And as long as there is interest and
> growing adoption....
>
> So we get more aggressive with our releases. We definitely want to preserve
> compatibility but if we have a good reason for breaking compatibility we let
> people know and show them how to migrate. At the same time we get more
> aggressive with marketing, by overhauling the website, getting the project
> blog going, re-organizing the wiki and documentation, getting the source
> available from Fisheye, maybe even start a conference. Everything but the
> conference part seems pretty doable.
>
> Don has been a kind of de-facto leader for the project. I wonder what he is
> thinking.....
>
Allow me to jump in for a moment with some more info. It's true that
most WW devs are not active (anymore) these days. I blame it on too
much work and shifting priorities. Alex is working on InfoQ, TestNG,
Groovy (and probably a dozen other things), Toby returned to WW
because he needed that one for his projects, but being one guy, it's
hard to pull off releases .. unless you're Rainer, which has been
taking care of XW, but judging by the way his commits drop in, I think
he's just way too busy (pretty much like Rene). Patrick has only
recently 'revived' after some things that required some other
commitment ;-), Jason is just vanished from the earth afaik, and
everyone else is either MIA or just too busy. Ian also has other
commitments and probably won't have much sleep at all for the next 6
months ;-)
S2 holds its ground against other web frameworks - the code you can
write with it is very elegant, very concise and S2 is extremely
flexible. New developers can get up to speed really quick (but some
guidance is needed for those coming from S1). The documentation is
perhaps a bit shattered (and the automatic static publishing doesn't
work correctly, afaict) and outdated in some places, but like most
habits it's quite hard to see the problem zones after all these years.
Personally, my only gripe is OGNL which kills performance when using
S2 tags in a heavily concurrent environment - but for most projects,
it's fast enough. Like I stated before, I've begun MVEL integration a
few weeks ago, but lack of spare time has halted that one for now.
Again.
Some points:
- XWork: integrate it into S2.
- OGNL: drop or at least provide alternate implementation using MVEL.
- REST: I agree, we need that.
- COC: No real need for it, it helps at first, but that makes a 0.1%
difference, which I'll happily sacrifice for increased readability in
my struts-*.xml files. Never understood the whole XML verbosity
problem. S2 plugin for IntelliJ helps here though, so I might be
biased.
- Ajax: throw out Dojo and either replace it with JQuery or another
lightweight JS library, or drop Ajax themes completely and rely on 3rd
party plugins.
- Lower level customization documentation: would be nice, but
normally, if you're going to dive into those, you're smart enough to
read the source code and figure things out yourself. Entry level
documentation (like the screencasts and best practices) would have a
bigger impact.
- Portlets: seems like only Nils is working on those, but quite a few
people seem to use it. I've never used it, but personally I think it's
a great testimony for the flexibility of S2.
- Documentation: no more (example) documentation in the Javadocs so
non-committers can make changes in the wiki.
My 2 cents.
Phil
>
>
> Jeromy Evans - Blue Sky Minds wrote:
>>
>> I share similar sentiment. Whenever I take a critical look as to whether
>> to use struts2 I keep coming back to the conclusion that it's
>> fundamentally sound as far as java frameworks go.
>> I'd categorize the problem as not enough generals. Most of us can make
>> incremental improvements or start new plugins but few have the courage
>> to to drive through fundamental changes or remove features. I'd join
>> some kind of coordinated hack-a-thon to break through the inertia.
>>
>> My #1 issue is that it's *too difficult and time-consuming to create a
>> release* on the 2.1 trunk. If releases are difficult and dependent on a
>> few key individuals then momentum slows and the project inevitably stalls.
>>
>> I've been independently tinkering with release process to try to
>> automate all assembly within a CI system so a formal release is an
>> administrative process only, but it's not much fun.
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Concerned-Strutszien%3A-A-Manifesto-tp20053620p20102920.html
> Sent from the Struts - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"We cannot change the cards we are dealt, just how we play the hand."
- Randy Pausch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by dusty <du...@yahoo.com>.
So the more I think about it the more thoughts I have....
The major users like Atlassian and Google forked Webwork a while ago I think
and they don't run their stuff off the Struts2 code base. Don has been
awesome for Struts2, but I don't know if there are any other commiters from
Atlassian or Google. Alexandru uses Webwork for InfoQ, and I am not sure if
he ever moved to Struts2 either. I am not sure what Patrick and Jason are
doing these days but we have a large population of WebWork people that seem
to have not moved to the Struts side of the world. I don't know if that
matters or not. As long as we have enough smart people, and we do, to keep
things going in the right direction. And as long as there is interest and
growing adoption....
So we get more aggressive with our releases. We definitely want to preserve
compatibility but if we have a good reason for breaking compatibility we let
people know and show them how to migrate. At the same time we get more
aggressive with marketing, by overhauling the website, getting the project
blog going, re-organizing the wiki and documentation, getting the source
available from Fisheye, maybe even start a conference. Everything but the
conference part seems pretty doable.
Don has been a kind of de-facto leader for the project. I wonder what he is
thinking.....
Jeromy Evans - Blue Sky Minds wrote:
>
> I share similar sentiment. Whenever I take a critical look as to whether
> to use struts2 I keep coming back to the conclusion that it's
> fundamentally sound as far as java frameworks go.
> I'd categorize the problem as not enough generals. Most of us can make
> incremental improvements or start new plugins but few have the courage
> to to drive through fundamental changes or remove features. I'd join
> some kind of coordinated hack-a-thon to break through the inertia.
>
> My #1 issue is that it's *too difficult and time-consuming to create a
> release* on the 2.1 trunk. If releases are difficult and dependent on a
> few key individuals then momentum slows and the project inevitably stalls.
>
> I've been independently tinkering with release process to try to
> automate all assembly within a CI system so a formal release is an
> administrative process only, but it's not much fun.
>
>
--
View this message in context: http://www.nabble.com/Concerned-Strutszien%3A-A-Manifesto-tp20053620p20102920.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Musachy Barroso <mu...@gmail.com>.
These are the steps:
http://struts.apache.org/2.x/docs/creating-and-signing-a-struts-21x-distribution.html
If they were easier, and there's got to be a way to make it easier, builds
would be coming out more often I am sure.
On Tue, Oct 21, 2008 at 9:50 PM, dusty <du...@yahoo.com> wrote:
>
>
>
> Jeromy Evans - Blue Sky Minds wrote:
> >
> > I share similar sentiment. Whenever I take a critical look as to whether
> > to use struts2 I keep coming back to the conclusion that it's
> > fundamentally sound as far as java frameworks go.
> > I'd categorize the problem as not enough generals. Most of us can make
> > incremental improvements or start new plugins but few have the courage
> > to to drive through fundamental changes or remove features. I'd join
> > some kind of coordinated hack-a-thon to break through the inertia.
> >
> > My #1 issue is that it's *too difficult and time-consuming to create a
> > release* on the 2.1 trunk. If releases are difficult and dependent on a
> > few key individuals then momentum slows and the project inevitably
> stalls.
> >
> > I've been independently tinkering with release process to try to
> > automate all assembly within a CI system so a formal release is an
> > administrative process only, but it's not much fun.
> >
> >
>
> I am not familiar with the formal release process. Are there Apache steps?
> Is it not a matter of building the relative zips, tars and putting the jars
> up on maven? I think there is a Bamboo server somewhere for this. Is that
> the CI you are working with?
>
> I am willing to help with what I can. One area where we can do better is
> the web site. Its downright confusing. It really should be much more
> simple. Either the Rails or the Grails sites are good examples of what we
> should be doing. I have had a screencast site in the works forever for
> Struts2. I need to just get that going.
>
> Is being part of "Apache" killing this framework? If we can get the
> releases out the door and improve the marketing and help material we should
> be able to get over the hump.
>
> What would be your process if you could make it up Jeromy? Muscachy?
> --
> View this message in context:
> http://www.nabble.com/Concerned-Strutszien%3A-A-Manifesto-tp20053620p20102714.html
> Sent from the Struts - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
Re: Concerned Strutszien: A Manifesto
Posted by dusty <du...@yahoo.com>.
Jeromy Evans - Blue Sky Minds wrote:
>
> I share similar sentiment. Whenever I take a critical look as to whether
> to use struts2 I keep coming back to the conclusion that it's
> fundamentally sound as far as java frameworks go.
> I'd categorize the problem as not enough generals. Most of us can make
> incremental improvements or start new plugins but few have the courage
> to to drive through fundamental changes or remove features. I'd join
> some kind of coordinated hack-a-thon to break through the inertia.
>
> My #1 issue is that it's *too difficult and time-consuming to create a
> release* on the 2.1 trunk. If releases are difficult and dependent on a
> few key individuals then momentum slows and the project inevitably stalls.
>
> I've been independently tinkering with release process to try to
> automate all assembly within a CI system so a formal release is an
> administrative process only, but it's not much fun.
>
>
I am not familiar with the formal release process. Are there Apache steps?
Is it not a matter of building the relative zips, tars and putting the jars
up on maven? I think there is a Bamboo server somewhere for this. Is that
the CI you are working with?
I am willing to help with what I can. One area where we can do better is
the web site. Its downright confusing. It really should be much more
simple. Either the Rails or the Grails sites are good examples of what we
should be doing. I have had a screencast site in the works forever for
Struts2. I need to just get that going.
Is being part of "Apache" killing this framework? If we can get the
releases out the door and improve the marketing and help material we should
be able to get over the hump.
What would be your process if you could make it up Jeromy? Muscachy?
--
View this message in context: http://www.nabble.com/Concerned-Strutszien%3A-A-Manifesto-tp20053620p20102714.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Rene Gielen <gi...@it-neering.net>.
Lots of the "pain" when doing a release comes from the administrative
side. Getting Jira issues in shape and tagged for the release, preparing
release notes and docs export, fixing site texts, managing the vote
process, doing announcements etc. In addition, there are some time
consuming and maybe more automizable tasks such as signing assemblies,
promoting files to the staging, mirroring and download areas along with
subsequently fixing permissions and ownership. The actual technical deploy
/ assembly steps are not really complicated in the end (well, for 2.0.x
they still sometimes are, 2.1.x does better here).
As I do from time to time some work an 2.0.x branch, which afaik is not
covered any more by bamboo, I have set up my own little hudson CI for the
2.0.x branch, which works like a charm and delivers automated snapshots,
and should theoretically be able to perform most of the "technical"
release side. Still, the administrative side as described above remains
very time consuming, and since we have clear rules on how to deal with
releases, I see no way around investing this time.
That said, I believe that doing automated snapshot / nightly builds
(including assemblies) would help a lot on delivering a solution for early
adopters, which in return would help to get very stable release candidates
which are most likely to pass the GA votes - every release manager is IMO
praying to have the release pass the vote, because preparing is hard and
time consuming and he will have to do the whole cycle again if it does not
pass.
- Rene
Am Mi, 22.10.2008, 04:58, schrieb Wendy Smoak:
> On Tue, Oct 21, 2008 at 6:01 PM, Bob Tiernay <bt...@hotmail.com> wrote:
>> I get the sense that CI + Maven is a like wrestling with a slinky. Is
>> this
>> problem endemic to s2? What do other open source projects do to
>> alleviate
>> this?
>
> The release process here could be *much* simpler, but it's really hard
> to change someone else's process. :) It's going to take someone to
> volunteer to be release manager and refine the process and the build
> once or twice.
>
> Compare to... http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>
> It really should be those two steps-- "mvn release:prepare" and "mvn
> release:perform"
>
> The first thing I'd do is flip things around so that everything builds
> by default, and use profiles to *exclude* things if necessary. But
> since I'm pretty sure that would break Bamboo, I won't do it. I will
> make time to help if someone wants to drive this.
>
> I think Maven and CI is pretty easy... Continuum or Hudson work fine,
> and they both have integration with Maven release. But CI may be
> problematic for releases here due to the PGP signing requirement-- you
> wouldn't want to put your private signing key on a shared CI server.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
René Gielen
IT-Neering.net
Saarstrasse 100, 52062 Aachen, Germany
Tel: +49-(0)241-4010770
Fax: +49-(0)241-4010771
Cel: +49-(0)177-3194448
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Musachy Barroso <mu...@gmail.com>.
> The release process here could be *much* simpler, but it's really hard
> to change someone else's process. :) It's going to take someone to
> volunteer to be release manager and refine the process and the build
> once or twice.
>
>
Whose process? Apache's? Either way, if it can be *much* simpler, lets do it
:)
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
Re: Concerned Strutszien: A Manifesto
Posted by Musachy Barroso <mu...@gmail.com>.
Did you get anywhere with this?
On Tue, Oct 21, 2008 at 10:16 PM, Jeromy Evans <
jeromy.evans@blueskyminds.com.au> wrote:
> Wendy Smoak wrote:
>
>> On Tue, Oct 21, 2008 at 6:01 PM, Bob Tiernay <bt...@hotmail.com>
>> wrote:
>>
>>
>>> I get the sense that CI + Maven is a like wrestling with a slinky. Is
>>> this
>>> problem endemic to s2? What do other open source projects do to alleviate
>>> this?
>>>
>>>
>>
>> The release process here could be *much* simpler, but it's really hard
>> to change someone else's process. :) It's going to take someone to
>> volunteer to be release manager and refine the process and the build
>> once or twice.
>>
>> Compare to...
>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>
>> It really should be those two steps-- "mvn release:prepare" and "mvn
>> release:perform"
>>
>> The first thing I'd do is flip things around so that everything builds
>> by default, and use profiles to *exclude* things if necessary. But
>> since I'm pretty sure that would break Bamboo, I won't do it. I will
>> make time to help if someone wants to drive this.
>>
>>
>>
>
> I'll create a branch and attempt this. I'll try to automate the builds
> from my own server for now (TeamCity). Will keep you updated.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
Re: Concerned Strutszien: A Manifesto
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Wendy Smoak wrote:
> On Tue, Oct 21, 2008 at 6:01 PM, Bob Tiernay <bt...@hotmail.com> wrote:
>
>> I get the sense that CI + Maven is a like wrestling with a slinky. Is this
>> problem endemic to s2? What do other open source projects do to alleviate
>> this?
>>
>
> The release process here could be *much* simpler, but it's really hard
> to change someone else's process. :) It's going to take someone to
> volunteer to be release manager and refine the process and the build
> once or twice.
>
> Compare to... http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>
> It really should be those two steps-- "mvn release:prepare" and "mvn
> release:perform"
>
> The first thing I'd do is flip things around so that everything builds
> by default, and use profiles to *exclude* things if necessary. But
> since I'm pretty sure that would break Bamboo, I won't do it. I will
> make time to help if someone wants to drive this.
>
>
I'll create a branch and attempt this. I'll try to automate the builds
from my own server for now (TeamCity). Will keep you updated.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Musachy Barroso <mu...@gmail.com>.
> The first thing I'd do is flip things around so that everything builds
> by default, and use profiles to *exclude* things if necessary. But
> since I'm pretty sure that would break Bamboo, I won't do it. I will
> make time to help if someone wants to drive this.
>
I think this much I could do, I will be bugging you in #struts in the next
few days about what would be the next steps.
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
Re: Concerned Strutszien: A Manifesto
Posted by Wendy Smoak <ws...@gmail.com>.
On Tue, Oct 21, 2008 at 6:01 PM, Bob Tiernay <bt...@hotmail.com> wrote:
> I get the sense that CI + Maven is a like wrestling with a slinky. Is this
> problem endemic to s2? What do other open source projects do to alleviate
> this?
The release process here could be *much* simpler, but it's really hard
to change someone else's process. :) It's going to take someone to
volunteer to be release manager and refine the process and the build
once or twice.
Compare to... http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
It really should be those two steps-- "mvn release:prepare" and "mvn
release:perform"
The first thing I'd do is flip things around so that everything builds
by default, and use profiles to *exclude* things if necessary. But
since I'm pretty sure that would break Bamboo, I won't do it. I will
make time to help if someone wants to drive this.
I think Maven and CI is pretty easy... Continuum or Hudson work fine,
and they both have integration with Maven release. But CI may be
problematic for releases here due to the PGP signing requirement-- you
wouldn't want to put your private signing key on a shared CI server.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Bob Tiernay <bt...@hotmail.com>.
I get the sense that CI + Maven is a like wrestling with a slinky. Is this
problem endemic to s2? What do other open source projects do to alleviate
this?
> My #1 issue is that it's *too difficult and time-consuming to create a
> release* on the 2.1 trunk. If releases are difficult and dependent on a
> few key individuals then momentum slows and the project inevitably stalls.
>
> I've been independently tinkering with release process to try to automate
> all assembly within a CI system so a formal release is an administrative
> process only, but it's not much fun.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
dusty wrote:
>
> How do we tackle all this? Do we have a meeting? Do we create a Chief who
> can make decisions for better or for worse? Clearly decisions need to be
> made. Do we start StrutsCon 2009 and lock everyone in a room until the
> decisions are made? I started to also write apps in Rails and I promised
> myself I would learn Grails to stay current, but judging from Phillip's
> session at JavaOne and the traffic on the mailing list there is still A LOT
> of interest in S2. Ideas? Volunteers? Beueller?
>
I share similar sentiment. Whenever I take a critical look as to whether
to use struts2 I keep coming back to the conclusion that it's
fundamentally sound as far as java frameworks go.
I'd categorize the problem as not enough generals. Most of us can make
incremental improvements or start new plugins but few have the courage
to to drive through fundamental changes or remove features. I'd join
some kind of coordinated hack-a-thon to break through the inertia.
My #1 issue is that it's *too difficult and time-consuming to create a
release* on the 2.1 trunk. If releases are difficult and dependent on a
few key individuals then momentum slows and the project inevitably stalls.
I've been independently tinkering with release process to try to
automate all assembly within a CI system so a formal release is an
administrative process only, but it's not much fun.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Concerned Strutszien: A Manifesto
Posted by Brian Pontarelli <br...@pontarelli.com>.
> * OGNL - Is is staying? Is it going? Can it be secure? Is it fast
> enough?
I say drop it completely. No more evaluation in the JSPs or FTL files
at all and use MVEL for the parameters interceptor. FTL has a good
enough language and you have Java in JSPs if you need it. OGNL in
there is just confusing clutter that isn't necessary. I'd also make
all the taglibs type safe and well validated. You should have to pass
in a Map to the taglib for it work, rather than an expression that
evaluates to the Map.
> * Convention - Buzz factor to me, but buzz none the less. I type
> pretty
> fast.
Convention is a must. Drop a lot of the annotations because all they
do is move configuration into code. Simplify in convention and leave
XML if you need to tweak.
> * REST - Great way to organize web based applications
Definitely finish this off in a manner that completely integrates with
convention. Handle REST parameters and all the REST conventions such
as URI notation and such.
> * Lower Level Customization Documentation - ActionMapper,
> Configuration
> Manager, Plugin Patterns -- How to get the most out of Struts2 by
> understanding not only how it works but how customize it to meet
> your needs.
If you use Guice, abstract out all creation, interface everything
really well and provide good ways to override, you'll be in a much
better place. I'd also rip out a lot of the extra cruft around and
just inject everything linearly, no circular injection and drop the
multiple configuration files. I'd also drop a lot of the plugin stuff
and stream-line plugins via interface injection.
> * Model and Service Layer - We know Struts2 is a web framework and
> its good
> at it. So there is Appfuse and that is something I have worked on.
> Stripping down Appfuse and hopefully making some kind of Groovy-
> based Model,
> Service, Action, View generator. More on that here:
> http://www.nabble.com/RE%3A-Getting-ready-for-Struts-2.1.1-td17446803s2369.html#a17461105
> .
> I think the plan is good, but I haven't done as much as I need to yet
I'd skip this. If you want a better platform, use something that is a
platform like Spring with their MVC. This was one of the big driving
factors behind JCatpault and our shift from Struts to our own MVC.
> * AJAX - Never been a fan of the Dojo tags -- DWR? Prototype/
> Scriptaculous?
> JQuery? I used proto and scriptac for a while but I have moved to
> JQuery
> recently.
I'd remove this completely as well. Folks should be able to add in
their own templates and make their own AJAX integration. This would
also mean simplifying the mess that is the current theme templates.
Templates should also not support inheritance, just makes it worse.
The template files need to be simple to create and replace. There
shouldn't be complex logic in the template files. JCatapult uses
template files and they are generally pretty simple and easy to tweak.
> * Stable and public API to keep backward compatibility
Yeah, this is a must. Things are moving targets in the API. If it has
the word public in it, it just can't change, period. I'd also drop
XWork completely. Move the XWork code into Struts, clean it up and
make it web centric, and drop all unnecessary extras. Struts is only
for the web and everything should act that way. Generic code just
makes it harder to work with.
> * Portlets are still first class citizens?
No opinion.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org