Another popular term for something like this is "extras". So, there might be a Struts 1 Spring Extras JAR and maybe a Struts 1 JasperReports Extras JARs.
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!". 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. -Ted. On 4/21/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
I am proposing a new module for Struts 1.x called "modules" which would contain integration classes into popular open source libraries. For starters, it would contain a new command to let Spring wire up the CRP using a command. Paul
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
