On 4/21/07, Ted Husted <[EMAIL PROTECTED]> wrote:
A key problem with an omnibus JAR isn't so much the other classes (that the JVM wouldn't load) or the dependencies (that Maven wouldn't import), but just handling the logging statements. In practice, the optional code might want to try and initialize itself if the dependency is present, or not if the dependency is absent. Either way, we'd probably want to log whether it found the dependency and loaded or not, otherwise a lot of people will be wondering why an extra doesn't work. But, if there is more than one extra in a JAR, then not loading might be a normal occurrence, so we end up with half-hearted statements like "The Spring Extra didn't initialize, but that might be OK if you're not using Spring!".
Alright. Having an "extras" project per integration technology is fine. I agree with you and Martin. That sounds very good tome. We tried the optional route with Struts 2 and ultimately went to a
full-blown plugin system, because of issues like these. We might want to think about framing this initiative as a strategy that third-parties could also follow, as we did with the Struts 2 plugins.
We already have a plug-in system in 1.x. I don't think I want to develop plugins -- but I do want to provide a standard community library for integration classes. Paul
