« Return to Thread: Fragility vis war generation

Re: Fragility vis war generation

by astachel :: Rate this Message:

Reply to Author | View in Thread

+1

Additionally, I've had a bear of a time integrating a Grails application into an existing continuous build environment that is based primarily on a lot of Ant scripts.  The scripts also manage constructing dependencies (not based on Ivy or Maven), and I have not yet seen a good way to integrate this process with Grails yet, as the the $GRAILS_HOME/lib JARs are hardcoded into War.groovy.  I'd love it if I could construct my own set of libs for war generation, and have the script use that.


This issue has an impact on end users, too, if they intend to use grails.war.dependencies to keep specific jars outside of the war. (I raised this JIRA last week that grails.war.dependencies is undocumented and I don't know how to find the list of .jar files that Grails requires: http://jira.codehaus.org/browse/GRAILS-2847) Perhaps the command line should be extended so that the list of dependencies can be displayed.

Brad

Marc Palmer Local wrote:
Hi all,

I'm just trying to track down an unrelated obscure war-generation  
issue and saw this in War.groovy:

DEFAULT_DEPS = [
     "ant.jar",
     "ant-launcher.jar",
     "hibernate3.jar",
     "jdbc2_0-stdext.jar",
     "jta.jar",
     "groovy-all-*.jar",
     "springmodules-sandbox.jar",
     "standard-${servletVersion}.jar",
     "jstl-${servletVersion}.jar",
     "antlr-*.jar",
     "cglib-*.jar",
     "dom4j-*.jar",
     "ehcache-*.jar",
// it goes on
]

This list worries me. It sets us up for hard to test failures in WAR  
generation in the future, when depenencies are added to /lib but then  
not updated in War.groovy. To test these would require WAR generation  
and full bootstrapping and a comprehensive functional test of an  
application WAR.

Is there some other approach smarter we can take to this? As somebody  
already suffering an obscure "can't build a production war" problem I  
can see how painful this problem is. These things typically show up on  
the verge of deployment when everything is GO GO GO and nobody is  
around to fix/debug.

For example perhaps we need multiple jar directories. lib/core/  
(needed in war), lib/runtime/ (needed only to run grails not to deploy  
wars) and lib/java5. This approach would be "coding by convention" as  
you just put the jar in the right place, and no code to update.

Thanks,
Marc



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


 « Return to Thread: Fragility vis war generation