You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by EJ Ciramella <ec...@upromise.com> on 2009/04/29 22:06:37 UTC
versus
Hello list - quick quesiton (I think) -
When should one choose to process resources versus using an assembly
descriptor (with filtering on or off - depending on what you want)?
RE: versus
Posted by EJ Ciramella <ec...@upromise.com>.
No, the war file stays the same, the configuration files we need for the
different environments (OTAP) are inside the tar.gz file.
EJC >> This is where I'm getting hung up - if you have MANY
environments, and your tar.gz takes as long as 1 hour to build, why
bundle something as small as configuration inside this particular zip?
Why not keep it external? Also, if you're talking about property files
used by your application, why not just have a property file with tokens
in them, replaced during deployment?
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 >> Sure, but if there are configuration changes that need to happen
within the web.xml, what then?
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.
EJC >> You don't, but we'd have to. Depending on env we deploy to,
different servlets are either active or not.
We don't duplicate resource copying, they are different resources.
EJC >> Correct, you probably don't, but you could and instead of having
various things in your target directory (like your classes, a scripts
directory, etc) you could have a directory that represents the final
gzip file - all pulled together via assembly:directory (which would
process your files accordingly).
Anyone else have any suggestions as to when/why use <resources> versus
an assembly descriptor?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: versus
Posted by Nick Stolwijk <ni...@gmail.com>.
> 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 <ec...@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
RE: versus
Posted by EJ Ciramella <ec...@upromise.com>.
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
RE: versus
Posted by EJ Ciramella <ec...@upromise.com>.
Well - if you're building an ear or war - what if there are stack
specific property files that live inside the war AND property files that
live OUTSIDE the war (say in a "config" directory that is a peer of the
main server/deploy directory structure)? What if there is another
process that has to run against your war artifact (which results in a
different type of artifact)? Something, say, post package phase.
Why use resources when you can get the same thing from the assembly
process? Also, why wouldn't you want the dev runtime env to look as
close as possible to an actual deployment?
-----Original Message-----
From: Nick Stolwijk [mailto:nick.stolwijk@gmail.com]
Sent: Wednesday, April 29, 2009 4:12 PM
To: Maven Users List
Subject: Re: <resources> versus <assembly>
Resources are included in your jar/war file, while an assembly creates a
zip or tar.gz file, for example we create a tar.gz with our final war
file, the configuration files for the different environments, some
static resources which are deployed somewhere else and the deployment
documents. 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.
With regards,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Wed, Apr 29, 2009 at 10:06 PM, EJ Ciramella <ec...@upromise.com>
wrote:
> Hello list - quick quesiton (I think) -
>
> When should one choose to process resources versus using an assembly
> descriptor (with filtering on or off - depending on what you want)?
>
>
>
---------------------------------------------------------------------
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
Re: versus
Posted by Nick Stolwijk <ni...@gmail.com>.
Resources are included in your jar/war file, while an assembly creates
a zip or tar.gz file, for example we create a tar.gz with our final
war file, the configuration files for the different environments, some
static resources which are deployed somewhere else and the deployment
documents. 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.
With regards,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Wed, Apr 29, 2009 at 10:06 PM, EJ Ciramella <ec...@upromise.com> wrote:
> Hello list - quick quesiton (I think) -
>
> When should one choose to process resources versus using an assembly
> descriptor (with filtering on or off - depending on what you want)?
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org