In this interview with Artima, Bill Roth, BEA vice president and unit executive of the company's Workshop division, discusses ways to manage dependencies of artifacts in a Web application:

http://www.artima.com/lejava/articles/javaone_2007_bill_roth.html

What strategies do you follow to manage dependencies in your applications?

A comprehensive suite of automated web tests takes care of most dependency related issues and other bugs. They're also very cheap to generate. Check out Selenium and the test recorder plug-in. You'll have a good suite of tests in no time.

Execute them against your deployable from a continuous integration engine with Cargo, and the testing takes care of itself.


cheers,
Sakke Wiik

> A comprehensive suite of automated web tests takes care of
> most dependency related issues and other bugs. They're
> also very cheap to generate. Check out Selenium and the
> test recorder plug-in. You'll have a good suite of tests
> in no time.

While testing is definitely a Good Thing, having something like design-time or compile-time checking is better still. I shouldn't have to package, deploy and start up my web app, and then run an integration testing suite, just to find out that I typed foo.getFar() in my template, when Foo only has a getBar() method. Unfortunately, precious few templating languages for Java offer the ability to detect these sorts of problems during development.

I fully agree. I take it for granted that an IDE highlights broken dependencies.
I'm still not fully comfortable with that. Testing against the deliverable proves that the build builds the package the same way your project in the IDE is configured.

Good point - IDE highlighting of problems adds efficiency, but is no substitute for testing. That said, dependencies that can be enforced through the compilation process which is used to produce the deliverable do provide a real element of safety. This is a big reason I've never been able to tolerate JSP - it postpones way too many errors until runtime.

Precompiling JSP pages with JSPC can be attached to the build. It will check the syntax at least.

> While testing is definitely a Good Thing, having something
> like design-time or compile-time checking is better still.
> I shouldn't have to package, deploy and start up my web
> b app, and then run an integration testing suite, just to
> find out that I typed foo.getFar() in my
> template, when Foo only has a getBar()
> method.

Depends on the cost. How much extra declarations do you need to add to get the checks, how often are these in the way of legitimate changes, and what programming methods do you lose by the forced mapping to known methods?

Of course, if checking for this is free, then it is of course better to get it at compile or design time. If the cost is higher than 0, then it is a trade off. (For instance, in Java I find that these checks come at a cost of 70%+ increase in code size compared to dropping all declarations and testing runtime, like Ruby does.)

> Precompiling JSP pages with JSPC can be attached to the
> build. It will check the syntax at least.

True. Unfortunately, JSP goes out of its way to create an illusion of loose coupling where there is none. A JSP page may (effectively) require that it be passed two variables, that one of them be labeled "customer" and be of type Customer, and that the other be labeled "order" and be of type "Order". Unfortunately, none of this is checked prior to runtime. I believe this was a fundamentally poor design choice on Sun's part, no doubt due in part to the rush to quickly come up with an answer to ASP.