The main Struts web site includes documentation for the latest "General Availability" release in each major release series. The development section of the site inclues draft documentation for upcoming releases. If you are just getting started, focus on the latest General Availability release, Documentation for past releases is also available.
Apache Struts uses a "milestone build" system to create releases. First, we create a build with a milestone version number, like Struts 2.0.42, and post the distribution in the development area. The development group tests the distribution, and then we decide whether or not to release it. The distribution includes everything that would be released, including the documentation and the release notes for this version.
If we find a significant problem with the distribution, we may decide not to release it, and just leave the distribution as a "test build". The testing may take several days, and in the meantime, we want to keep the project moving, and so we just go onto the next version number. Using our example, the next distribution would be labeled 2.0.43, even if version 2.0.42 was never officially released.
Often. we will first grade a release as a "beta", and invite other users to test it too. If this second round of beta testing goes well, then we may mark the release "General Availability". Usually, that designation would also make it the new "Best Available" release. In this case, we don't create another distribution, but simply adjust the status of the same set of bits that people have been testing all along.
In practice, the milestone build system is fast and efficient and creates the fewest number of "candidate builds" between releases.
It's a reference to "struts" in the architectural sense, a reminder of the nearly invisible pieces that hold up buildings, houses, and bridges.
All Apache Struts products are copyrighted software available under the Apache License, a "free-to-use, business-friendly license".
Yes. The only requirements you must meet are those listed in the Apache License.
You need to credit Apache Struts if you redistribute your own framework based on our products for other people to use. (See the Apache License for details.) But you do not need to credit Apache Struts just because your web application utilizes one of our products. It's the same situation as using the Apache HTTPD server or Tomcat. Not required if its just running your web site. Required if you've used the source code to create your own server that you are redistributing to other people.
For a listing of some Java and Struts ISPs, visit the Struts Community Resources area on SourceForge.
The frameworks should work well with any development environment that you would like to use, as well as with any programmers editor. The members of the Apache Struts development group each use their own tools such as Emacs, IDEA, Eclipse, and NetBeans.
For more, see the IDE discussion page in the Struts 1 wiki.
Each release of Struts comes with a User Guide or set of Tutorials to introduce people to the framework and its underlying technologies. Various components also have their own in-depth Developers Guide, to cover more advanced topics. Comprehensive Javadocs are provided for each release, along with the full source code.
The Struts user mailing list is also very active, and welcomes posts from new users. Before posting a new question, be sure to consult the MAILING LIST ARCHIVE and the very excellent How To Ask Questions The Smart Way by Eric Raymond. Please do be sure to turn off HTML in your email client before posting.
The Apache Software Foundation does not provide commercial support for any of our software products, including Apache Struts. However, third parties may offer different degrees of support.
First, it's important to remember that Apache Struts is an all-volunteer project. We don't charge anyone anything to use Apache Struts products. Committers and other developers work on Apache Struts products because they need to use it with their own applications. If others can use it too, that's "icing on the cake". If you submit a patch for a feature that a Committer finds useful, then that Committer may choose to volunteer his or her time to apply the patch. If you just submit an idea without a patch, it is much less likely to be added (since first someone else has to volunteer their time to write the patch).
We are grateful for any patches, and we welcome new ideas, but the best way to see that something gets added to the framework is to do as much of the work as you can, rather than rely on the "kindness of strangers". Worst case, you can apply the patch to your copy of the framework and still use the feature in your own application. (Which is what open source is ~really~ all about.)
Except for our announcements page, there is not a formal press or media kit for Apache Struts. Queries from the press (and ONLY queries from the press, NOT support questions or anything else!) should go to our media relations address: [press (at) apache (dot) org].
If you believe you've found a security vulnerability in Apache Struts, please contact our security address - any emails not relating to security vulnerabilities will be ignored without a reply (all security related information will be kept confidential unless otherwise indicated): [security (at) struts (dot) apache (dot) org].
If you are subscribed to the digest, you can also post to the list. Just be sure to send your post to the user list rather than trying to reply to the digest.
Not a usenet group, but the Apache Struts User list can be accessed with your favorite newsgroup reader from the GMane News Site. Subscribe to groups gmane.comp.jakarta.struts.user for the user list.
No. Each major version has it's own JIRA project, but we share the mailing lists.
To get the best response to an inquiry, please specify which version of Struts is being used, including the milestone ("Struts 1.2.9", for example). You can also include the label [s1] or [s2] in the subject line of your post.
If you are receiving the digest, you must send a blank email to < email@example.com > instead.