OverDrive is being proposed as Apache Struts subproject. The source is currently the Struts "sandboard" repository, under Subversion. OverDrive is not an official Struts subproject, merely a whiteboard proposal in its early development stages. For more, see the Subversion Readme and VStudio Readme.
Issues are being tracked via our JIRA project.
OverDrive is a public project, and everyone is invited to help. We only ask that you please be kind to all our users and volunteers
A good place to start is by commenting on any part of the documentation that is unclear. We also welcome additions to the documentation. If you sign up for an account here, you can add new pages and edit existing pages.
Before making any contributions, please note that the project is run by Apache Struts rules, and the Struts PMC makes the final say over documentation and code.
Write access to the repository is restricted to Struts committers, but patches are welcome. You can submit patches to the issue tracker. There's suppose to be an ticket for every API member. So before opening a new ticket, see if there is an existing one you can reopen instead.
OverDrive is a volunteer development project. The software we develop is made available under the Apache License to the general public at no charge. While we value input from the public, our core community is the volunteers who create and maintain the code.
We invite everyone to bring up any other questions and concerns in our Forum area. If you see a chance to jump in with a helpful comment, please do. The Forum is intended to serve everyone, user-to-user, user-to-volunteer, and volunteer-to-volunteer.
Comments regarding developing – rather than using – Nexus and the OverDrive applications, can be added to the peritent ticket in the issue tracker, or to the pending Work Log ticket.
To paraphrase Commander Data, "OverDrive is the project name, Overdrive is not."
More seriously, product names often use idiosyncratic punctuation so as to establish a service mark. And, camel-case speaks to the project being a joinder of two entities, applications and frameworks. But, mostly because because it looks cooler this way.
The project is a container for both the applications and the MVC framework. (With applications being the senior partner.) At the same time, the project tries to take application frameworks to the next level. The term "OverDrive" embodies both precepts.
Right now, Nexus has nothing to do with page flow, or any of that. We keep saying that Struts is a Bring Your Own Model (BYOM) framework. Think of Nexus as a Model who likes to date.
But, seriously, after the presentation framework collects the values, and decides it's time to invoke some business logic, the presentation framework can do that through a Nexus Helper object. In ASP.NET or JSF, we do this from the code-behind or a backing bean. In Struts Classic or Struts Ti, we would do it from an Action.
A business framework like Nexus encourages people to test and develop the data access and business rules outside of the presentation framework. Right now, most people don't have a business framework, and the business logic slip-slides into the presentation layer.
Where it gets a little murky is that Nexus is a business application framework that is aware a presentation layer exists, it just doesn't care which one. Could be a command-line interfaces. Could be a GUI. Could be a web app. Could be Ti. Could be Shale. Could be Classic.
When the presentation layer is untrusted, Nexus provides a Criteria context that can be used to pass strings back and forth to the internal Nexus commands. Nexus can then convert the input, run the commands, and format the output strings. The presentation layer can then focus on wrapping output in markup, flowing to pages, and all that gunk.
When the presentation layer is trusted, as it might be with certain unit tests, then input can also be injected in the Context directly and run against the Commands, allowing for separation of concerns within Nexus itself.
Think about it: Does authorization or localization or even text formating really have anything to do with the presentation layer mechanics. Or at least with the mechanics of any particular presentation layer? Since tasks like these need to be done for any and all presentation layers, DRY tells us they must be done on a separate layer, so that the work can be done once and shared by all the presentation layers.
Meanwhile, Separation of Concerns tell us that the presentation layer should focus on collecting input and marking up output (which is plenty), and leave whatever else it can to another layer. Like, say, the Nexus layer.