eyeWiki
This is a bastardized branch from the JSPWiki code base. I branched off circa 2.1.<mumble> and kept backporting code up until 2.2.6 or so.
Why yet another Wiki?
Well, it wasn't my idea... :-) In fact, it was my idea. For a customer project, I considered using a Wiki as the UI using a plugin based architecture to access the business logic and functionality while keeping the GUI design inside a Wiki. While the idea was enthusiastically greeted by the customer, the final project was sacked by the management and I was left with a (payed for :-) ) prototype. And the permission to publish the code changes (as this is GPL code, the customer got full source code without any restrictions. However, I'm pretty sure that this CD rots somewhere in a desk and will never see the light again).
Changes vs. JSPWiki
- Reworked the build process to use maven, giving us the eyeWiki Site
for free.
- Using Subversion.
- All dependencies are now resolved against the ibiblio repository reducing the size of the code base
- Introduced some jakarta-commons libraries thus removing some of the util code which wasn't very good to begin with
- Factored out some common code, removed a lot of cruft.
- Reworked the directory structure to work with Maven and also the Eclipse Lomboz plugin
- Made all tests runnable in the maven test harness thus reporting code coverage and also test failures.
- Fixed most of the problems and bugs reported by Findbugs and PMD. (Update: Newer Version of Findbugs Plugin finds new bugs)
- Changed the custom component architecture to use PicoContainer (A tree of containers to be exact).
- Changed plugin architecture to use PicoContainer.
- Reworked the Variable evaluators to make Variable definition and evaluation pluggable through (guess what) PicoContainer.
- Did lots of changes to the CSS skinning (unfortunately overshooting by a wide margin, making the CSS even harder than with the hard coded JSP Wiki stuff. :-( )
- Factored out some magic numbers and constants, making the code better readable
- Lots and lots and lots of small fixes, some performance fixes (e.g. String handling)
The resulting code base does not really resemble JSPWiki any longer, that's why I renamed it to eyeWiki (I don't want people to go to the JSP Wiki lists and ask questions about my code base. Janne and friends are already busy enough).
I hope that some of my code will be back ported to the main JSP Wiki trunk. I consider the Pico based architecture much more stable than the code that Janne uses (which has a lot of duplications and assumptions that will probably break one day. Moving to a XML based, pluggable architecture makes the Wiki much easier to handle).
Is this code still in active development?
Well, that depends. I use it ("Sie baden gerade ihre Hände darin"), but for me, it has still a big number of issues, many of these not
solvable without major rewrites
- Uses self rolled Wiki Render Engine. This is a matter of taste.
- UTF-8. While one should think that with a language like Java which has Unicode at its core, UTF-8 shouldn't be a big deal; with code derived froM JSPWiki it is. There are a lot of special cases for ISO vs. Unicode selection where I fail to see the point. All of this code should be ripped out and replaced with a UTF-8 at the heart engine. If you insist on rendering your pages in ISO or some other coding system, let a small layer between the TranslatorWriter and the servlet output stream do it. Probably a major rewrite, though.
- Uses JSPs. This is also a matter of taste, however I simply don't see the point of having literally dozens of tags just to use JSP technology when you could do the same thing with a Velocity
template.
- The authentication and autorization system is as bad as JSP Wiki 2.1. This seems to have improved with 2.2 and beyond, however I was lazy and haven't looked into this lately.
- The bad auth system is actually not a big deal for me because I use eyeWiki for a "I can edit, you can read" web site type (Poor mans' CMS). It might be a big deal for you, though.
- Some parts of the code are not good, e.g. the providers. Having a search engine (Lucene) running inside a provider and using something else to do actual page searching is not exactly a terrific idea.
- Some code structures seem to have run against a wall. Look at the code duplications in WikiEngine and WikiContext or the usage of context and page.
- The code is still not fully skinnable. There are lots of assumptions and hard-coded CSS tags and classes inside the Java code.
- (Killer). (L)GPL. Using (L)GPL code puts all customer projects in constant danger of being dragged into the GPL realm. Especially with Java code where the position of the FSF is (deliberately?) not clear.
- Docs. Yeah, I know, I've ranted about bad docs. However, most of the JSPWiki userlevel docs still apply, for everything else (especially the XML definitions of plugins, variables and components), I refer you to the Picocontainer
web site and the eyeWiki source code . Sorry.
If you want to take code from JSPWiki, backport or forward-port it to JSP Wiki (or something else): Be my guest. If you have a bug fix or an enhancement: Send it to me, I will put it in. If you use eyeWiki and like it: Cool. However, I will only do active development if either I will use it inside a project or someone forces me to.
| Go to top |
|
More info...
|
|
|
This page last changed on 15-Aug-2005 13:52:40 CEST by HenningSchmiedehausen.
|
|