Coding Clarity

I have been looking into using WebDAV as the core of a new solution I am working on. I needed centralized, content management style, read and write access to documents from multiple servers. WebDAV interested me because users could easily access these documents using external tools.

The application I am working on is written in Java so I went searching for an open-source WebDAV server and client library. There were a number of options for WebDAV servers:

1) Slide – http://jakarta.apache.org/slide/
This project was one of the primary WebDAV implementations in Java but has been retired as of Nov 3, 2007.
2) JackRabbit – http://jackrabbit.apache.org/
JackRabbit is a JSR170 Java Content Repository. It also provides access to its content through WebDAV.
3) Tomcat – http://tomcat.apache.org/
Tomcat has a WebDAV servlet that can be used to read and write web application content.

Options for a WebDAV client were a little bit more limited. Jakarta Slide had been the primary WebDAV client which was used in may other open source projects. Since it had been retired, I was looking for alternatives. Here is a message posted on the slide mailing list that mentions JackRabbit as the most suitable alternative.

The Apache Jakarta PMC is sorry to announce the retirementof the

Jakarta Slide subproject. After it's last release inDecember 2004,

development activity was significantly reducedand came to a total

standstill this year. Without a minimumdeveloper community that

can release security fixes, we haveno choice but to retire Slide.

We'll keep at least one ofthe mailing lists open for a transition

period, so users candiscuss alternatives and migration away from

Slide. Furtheruse of the Slide codebase is discouraged.

One alternative to Slide is provided by the Apache Jackrabbit

project. Jackrabbit has a healthy, active developer communityand

provides, among others things:- a server-side content repository-

a WebDAV server component for access to the repository- a WebDAV

client componentPlease visit http://jackrabbit.apache.org/ for

more information.

We apologize for the inconveniences.

Roland Weber

The problem is that JackRabbit does not currently have a WebDAV client component. JackRabbit focuses on the Java Content Repository specification and provides WebDAV as a server option. The following post from the mailing list explains.

Re: Webdav Client Examples?

 

by Angela Schreiber Nov 20, 2007; 04:45am

Jukka Zitting wrote:
> Hi,
>
> On Nov 14, 2007 11:26 AM, ossi petz <ossipetz@…> wrote:
>> Has anyone made some examples on how to use HttpClient with the
>> Jackrabbit Webdav Client?

there is an example in the sandbox/spi/spi2dav project.

> Not really. The WebDAV support in Jackrabbit is more focused on
> server-side implementations than clients.

> The best there is for clients is a collection of WebDAV method classes
> in the jackrabbit-webdav component.

… which are only waiting for somebody having time to put them
together to a complete dav client .

regards
angela

http://www.nabble.com/Webdav-Client-Examples--tf4803755.html#a13852979

When Apache retired the Slide project, they unknowingly retired the primary Java WebDAV client implementation. The folks in Apache must not have communicated with the JackRabbit team to ensure that it would be able to fill the hole that slide left. I continued my quest to find alternative WebDAV clients in Java.

Eclipse used to have a WebDAV client that was used for Team support. This was an extension available for Eclipse 3.2 and earlier called “WebDAV and FTP Support“. This project is no longer being maintained since 3.3 because of the new Eclipse FileSystem. The EFS (Eclipse FileSystem) was a new API for interacting with different file systems. The EFS implementation for WebDAV has not yet been completed. I stumbled upon a new project with Google’s Summer of Code to create an WebDAV EFS implementation. This is a note from that page.

Eclipse’s webdav client hasn’t been worked on for 2 years and has many shortcomings. The Jakarta Slide Webdav client (http://jakarta.apache.org/slide/webdav-client.html) is an actively maintained project.

I found it quite entertaining how Eclipse chose to use Slide as the client implementation because it was “actively maintained”. In reality the slide project had not been updated in years. It may be better than the old eclipse implementation, but it was far from actively maintained. I wonder what will happen with this project once they find out that Slide is no longer being developed.

I also found a few other projects that provide WebDAV access. These also use the slide client to provide their WebDAV functionality.

Maven Wagon – http://maven.apache.org/wagon/wagon-providers/wagon-webdav/
Apache Commons VFS – http://commons.apache.org/vfs/filesystems.html

After all of my investigation, it seems that Slide is still the best (or only) option for open source WebDAV clients even though the project is no longer being maintained.

I hope that the old slide client will eventually become an Apache Commons WebDAV client or maybe be incorporated into the HTTPClient project.

I have been using Groovy for a little while now and am researching the possibility of using Grails for an upcoming project. At the time, I did not no much about Grails but I had dabbled with Rails a bit and got a feel for how it works.

The .NET community created a project called nant, the .NET port of ant. I’m also familiar with all of the various XUnit variants like JUnit for Java, NUnit for .NET, etc… I just figured Grails was a the Rails application for Ruby ported over to Groovy.

This was not the case at all. Both Rails and Grails are “coding by convention” web frameworks for the Ruby and Groovy languages respectively but they have very different design points. I was familiar with how ActiveRecord works in the Rails world and figured Grails would work the same. ActiveRecord takes a database schema and builds the Object model from the database. In Grails, Object Relational Mapping (GORM) instead using hibernate under the hood.

This article gives a really good summary of the differences in the design approach between Rails and Grails:

Ruby on Rails: RoR uses the bottom up approach where you define your model at the database schema level and RoR builds the model to match using naming conventions. You don’t even have to add the properties to your domain classes as RoR will add them based on the naming conventions of the db schema.

Grails: Grails uses the model-down approach where you define your model and it (or Hibernate technically) builds the schema for you. As I mentioned I don’t like this as a matter of taste since I don’t have as much control over the underlying model. To Grails’ credit, you can fine grain control the database schema by using Hibernate’s mapping, but what a pain.

http://thebull.macsimumweb.com/comparing-ruby-on-rails-to-grails

I read a great article today on the future of software development. It gives a great summary of what is wrong with the waterfall method of development and how agile methodologies try solve this problem.

The problem was that the Waterfall Model was arrogant. The arrogance came from the fact that we believed that we could always engineer the perfect system on the first try. The second problem with it was that in nature, dynamic systems are not engineered, they evolve. It is the evolutionary idea that lead to the development of agile methods. (article)

Management is often slow to learn of new trends in software development. The fact that agile has been around since the nineties and many institutions still have not heard of it proves this point. I believe the best way to bring agile methodologies into an existing organization that uses the waterfall or another approach is to bring them in slowly. This is what we have done in my organization and it has been very successful. Here are some good starting points for change.

1. Change how requirements are viewed. If you are handed a set of requirements for an entire product release, plan for them to change no matter how “final” you are told they are.
2. Split the development cycle into iterations. At the end of each iteration reprioritize your tasks for the next iteration. 3-4 weeks is a good length for an iteration. Create a full release of your product at this point whether someone will actually use it or not. Hopefully you will have a QA team to test it at this point but it is important to create a fully working version of the product anyway.
3. Leave the design of system components to the iteration they will be developed in.
4. …

Pretty soon you will find that your Waterfall approach is a lot more agile than it used to be. I encourage you to keep changing your approach as you find what works best for your organization.