Fragility vis war generation

[Marc Palmer Local]

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

[Scott Davis]

+1

-s
Scott Davis
scott@...



On Apr 15, 2008, at 12:54 PM, Marc Palmer 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
>
>

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

    http://xircles.codehaus.org/manage_email

[Helmut Denk ()]

hallo marc,

i think ivy offers a quite nice solution for
that. you might want to read the ivy-docs
and learn what ivy-configurations are.
this is a quite complex subject however.

lib/ would be resolved and grouped after
public and internal configurations by ivy.

to stay independent from public artefact-repositorys
products can deliver/serve a small repository with all their
thirdparty-dependencys/artefacts. this is nothing
but an additional directory called /librep or so.

a build-target 'resolve' can use ivy to build up the lib/
from /librep. same artifact can belong to multiple
configurations (=subdirs of /lib).

lib/ is not under version-control any more but
librep/ is. this is dry from a build's perspective ...

have a nice time  

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

[Brad Whitaker]

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

[astachel]

+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

[Peter Ledbrook-2]

On 21/04/2008, astachel <adam@...> wrote:

>
>  +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.

Provide the following setting in Config.groovy:

  grails.war.dependencies = [ ... ]

This allows you to customise which libraries go into the war file.

Cheers,

Peter

--
Software Engineer
G2One, Inc.
http://www.g2one.com/

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

    http://xircles.codehaus.org/manage_email

[astachel]

I think my understanding was that these libraries would still be relative to $GRAILS_HOME/lib, however I stumbled across a JIRA item that mentioned that this value can be a closure that contains a fileset.  I'll try that option.

Peter Ledbrook-2 wrote:

On 21/04/2008, astachel <[e-mail]> wrote:
>
>  +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.

Provide the following setting in Config.groovy:

  grails.war.dependencies = [ ... ]

This allows you to customise which libraries go into the war file.

Cheers,

Peter

--
Software Engineer
G2One, Inc.
http://www.g2one.com/

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

    http://xircles.codehaus.org/manage_email