The main problem for the XWork releases needed for the last Struts2 GA
versions was not that we had no patches in place for XWork specific
issues and enhancements, but to have an official release built and
pushed out. Since the opensymphony infrastucture clearly divides between
a developer and a release manager role, the problems arise when the few
release managers are hooked up by their day jobs and RL issues, which of
course always has to have priority over the volunteer work.
I think we are now seeing improvement on that issue in a first step with
the plan to grant more developers working on both projects the release
manager role on opensymphony, and that will help a lot for future
release cycles.
For a possible move of XWork to Apache, one of the pros would be that we
would not face such a problem any more, since the Apache infrastruture
enables any project commiter to do a release process. On the other hand,
I don't expect the commits to reach new peaks just by having XWork moved
over, and the incubation process is a time consuming business, as I
recall it from the WW incubation.
If we would come now into calmer waters when the Struts 2.0.14 build
will be pushed out today and hopefully proves to provide the stability
and production readiness we are all waiting for, the next big step would
be to regain momentum on the 2.1 release, and I personally plan to help
out on that topic on both the Stuts and XWork side.
- Rene
Rainer Hermanns schrieb:
It is not true, that there are no releases of XWork.
True is, that the releases are not that frequent as required.
Currently only Musachy and me are working on XWork and applying patches.
Both of us are Struts2 core developers and PMC members, so you can be sure
that there will be XWork releases as required.
But please keep in mind, that we are all working on XWork and Struts2 in
our spare time free of charge.
There will be soon new release managers for XWork, so that one can step in
as required and releases should come out more regular.
However, this still requires time of the developers after, before or
beside their daytime jobs.
It would be of great help, if more users would test the nightly and
alpha/beta builds of S2/XWork and give their vivid feedback on the dev or
user list or even in Jira. I am pretty sure your mentioned problem with
websphere would have been solved before a release.
We need your feedback to make XWork and Struts2 better and to meet your
needs. Patches are also very welcome and maybe you are interested in
getting involved.
I wouldn't have a problem to move over XWork to the ASF and I am pretty
sure some other XWork developers would vote +1 for this step, but just
bringing over a project to the ASF without new volunteer developers
wouldn't solve the mentioned issue.
So, if I could see a better future for XWork at Apache, I'd love to go
this way, but this is not a task for two or three developers, but for a
larger community. If some developers would like to participate either at
OpenSymphony or in/after an incubation to ASF let me and others know, you
are welcome and your help would be much appreciated.
cheers,
Rainer
I count not help myself not to ask the queston and still wonder why it was
decided to build struts 2 on XWork instead of directing the effort to come
up with struts 2 using something home grown technologies like Command
chains ( that is currently used in struts 1.3 +). It makes u wonder what
happens if XWORK for some reason or other goes out of commission and there
are no releases. I do not see how struts 2 and xwork can be considered a
merge to create a new framework (struts 2) while xwork is an independant
and fully functional framework (when there is a merge, the merge results
in 1 new entity with merging old entities are gone)
I have been an avid user of struts 1 for past few years and have switched
to struts 2 to keep up with struts hype but I have not been able to run
any project in my case on Websphere (except 2.0.11) with any struts 2
release. Struts 1 used to run like charm.
regards,
----- Original Message ----
From: Rene Gielen <[EMAIL PROTECTED]>
To: Struts Developers List <dev@struts.apache.org>
Sent: Saturday, November 15, 2008 4:22:01 AM
Subject: Re: Struts2 and production apps
I totally agree that this is currently a very bad situation. Jeromy's tip
for static resources is a working fix for the 2.0.12 issue, as well as an
uprgade to 2.0.13 testing version would be (this was no GA release).
Please note that we fixed the static resource bug immediately when it was
reported, and triggered the 2.0.13 build - but since there is still the
conversion message issue, it will not become GA.
For the needed 2.0.14, we are simply waiting on XWork to be released,
because the said conversion error problem is not a Struts issue. The bug
was fixed in XWork code immediately after reporting, but XWork has it's
own release cycle. That's why it is not in our hand to get out a Struts
2.0.14 release candidate, which technically will be nothing more than a
2.0.13 with a current XWork build.
I really hope that we will be getting a XWork release this weekend, and as
soon as it is published, be sure that a 2.0.14 build will pushed out right
away. And to all those out there using production apps, please feel
invited to participate on the QA review and voting process for new
releases with reporting integration test results, because that helps us to
hunt down the real world issues before we consider a build GA.
- René
Jeromy Evans schrieb:
Koen Serry wrote:
* 2.0.12: yes great GA, ah no it doesn't do static resources, so all
client
side validations won't work....
Just a tip, if you're releasing a production app, you shouldn't be
serving static resources from the struts2 dispatcher. Extract them and
the problem is avoided.
http://struts.apache.org/2.0.12/docs/performance-tuning.html
http://cwiki.apache.org/S2WIKI/creating-a-custom-dojo-profile-for-struts-20x.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]