A news for 2009, will be about how Orizon will be deployed to our users.
As the codebase and the project goals grows, the choice of a single Jar file as distribution package sound so limiting. Consider a so called web2.0 company who wants to deploy a fresh code review web application using Orizon as underlying engine. Does the UI stuff make sense for those people? Let me consider also the following scenario. Security check library will be a very dynamic package with a lot of per month improvement. Do you really want to download the whole package each time?
The answer is No. Even for the first user, that is me.
So the obviously first action in this direction is to split the engine in four different jar files:
- engine: here goes the Jericho and the Mirage engines, the crawler and the reporting subsytem (whose still lacks the nickname) and the org.owasp.orizon.core package content. This will be the main jar file and the only to be necessary for executing Owasp Orizon. The web2.0 company in our first example will have to use this jar content in their code (and the library of course)
- tools: this is a new entry for 2009. A shell like UI executable code will be deployed for security specialist to interact with Orizon in a more close manner. With a shell, experienced reviewers can schedule Orizon jobs in a cron-like way (Unix is definitely the basis for all). I called this subsystem “tools” instead of “shell” because all stuff we can develop in the future can be included in this package
- ui: this is the main UI jar for people who wants to execute Orizon in a fancy way with a graphical UI that needs to be completely rewritten in the following months
- library: this is the second necessary jar file. The one containing the XML based library and the org.owasp.orizon.library package code needed to handle the checks.
All those jar archives will have a common major.minor version number but a different revision number that follows per package evolution within the specific version.