maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Stolwijk <nick.stolw...@gmail.com>
Subject Re: <resources> versus <assembly>
Date Fri, 01 May 2009 00:41:33 GMT
> EJC - woah - so if you have to deploy this web app to say, 20 or 30
> different servers across multiple environments, you pack all that
> configuration in this war?  Say your war is 150 mb, you really want to
> rebuild it each time someone corrects a setting?  We don't here, but
> that's another story.

No, the war file stays the same, the configuration files we need for
the different environments (OTAP) are inside the tar.gz file. I hope I
can get it a bit clear by example.

Our tar.gz looks like:

- deploy
    - app.war
- config
  - dev
     - config-file.properties
    - log4j.properties
  - test
     - config-file.properties
    - log4j.properties
  - acceptance
    ... you get the idea...
- documentation
   - deployment-document
- static
   - static.resources.tar.gz (to be deployed on the apache server)

So, the war deployed to each environment is the same, the property
files differ, but are still in our version system and delivered for
each environment.

> EJC - we're already on divergent paths - we have a bunch of
> configuration inside the web.xml.  Also, I'm not about to unpack
> something just to change a few things and then repack an archive during deployment.

I guess we have a bit of misunderstanding. We don't unpack the war
file, we pack the war file with a bunch of other files we have to
deliver to the administrators. The war file stays the same for all
environments.

> Why duplicate the resource copying in the assembly descriptor?
We don't duplicate resource copying, they are different resources.

Nick Stolwijk
~Java Developer~

Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl



On Thu, Apr 30, 2009 at 8:55 PM, EJ Ciramella <eciramella@upromise.com> wrote:
>
> Resources are included in your jar/war file, while an assembly creates a
> zip or tar.gz file
>
> EJC - yep - I got that, but both the resources stanza and the assembly
> descriptor(s) can filter files.  We have a process where we want the
> build to generate a war file, but hand that off to another custom,
> in-house plugin to generate an ear file.
>
> for example we create a tar.gz with our final war file
>
> EJC - we're already on divergent paths - we have a bunch of
> configuration inside the web.xml.  Also, I'm not about to unpack
> something just to change a few things and then repack an archive during
> deployment.
>
> , the configuration files for the different environments
>
> EJC - woah - so if you have to deploy this web app to say, 20 or 30
> different servers across multiple environments, you pack all that
> configuration in this war?  Say your war is 150 mb, you really want to
> rebuild it each time someone corrects a setting?  We don't here, but
> that's another story.
>
> , some static resources which are deployed somewhere else
>
> EJC - like web tier items?  This is getting off the subject a bit.
>
> and the deployment documents.
>
> EJC - our apps are all internally consumed (live site), we have our site
> output generating the deployment notes in a separate mvn build
> structure.
>
>  So the administrators have all the files they need to deploy our
> application. Filtering is used inside the war file, to display the
> current version on a status page. Two different things.
>
>
> EJC - So this leaves my question still open and unanswered.  Why have a
> target/scripts directory when you can have a
> target/appName-version-dev/scripts where the appName-version-dev
> directory matches 100% what your deployed app looks like?  Why duplicate
> the resource copying in the assembly descriptor?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message