You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Simone Gianni <si...@apache.org> on 2006/12/01 15:35:17 UTC
Manipulating the WAR directory before the WAR file gets built
Hi all,
I've developed a couple of plugin (one performs XML patches, the other
builds a certain site structure). They both should work on the WAR
directory structure, but before the WAR file is currently built.
Apart from my specific needs, it could be quite common to need to
perform some tasks (with an antrun for example) on the WAR directory
structure before zipping it in the WAR file.
Is there a way to hook these plugins (or any plugins) in between of the
WAR plugin? In case, could it be a good idea to split the WAR plugin in
two different goals so that it's possible to prepare the WAR directory
structure and zip it in two different phases?
Another option could be to use the WAR plugin to produce the directory
structure (copying all the dependencies jars in place, doing war overlay
etc..) and then use the assembly plugin (or antrun with a jar task :) )
to produce the final WAR file. Is this possible?
Thanks,
Simone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Steve Loughran <st...@apache.org>.
Ralph Goers wrote:
>
>
> Steve Loughran wrote:
>> Ralph Goers wrote:
>>>
>>>
>>> Steve Loughran wrote:
>>>> Simone Gianni wrote:
>>>>
>>>> The thing to remember about WAR files is that they are a packaging
>>>> format that is intended to make it easy to deploy web apps. Not
>>>> distribute, but deploy. The old WAR/EAR use cases always had the
>>>> 'assembler' who would be some person who would somehow assemble WARs
>>>> and EJB beans to make a working app, presumably through some GUI
>>>> that required the same work to be repeated every release.
>>>>
>>>> If you are doing lots of late binding tuning to the WAR file, then
>>>> perhaps build time is the wrong place to do it; it should really be
>>>> done as part of the deployment process, where per machine
>>>> optimisations can go in. In this world what you want from the outset
>>>> is the exploded WAR, which is then taken with server-specific
>>>> options to create the target WAR for the target system.
>>> Pardon me for saying so, but this is just nuts.
>>
>> :)
>>
>>
>>> In my environment our CM folks do the build and then make it
>>> available for operations. Noone after CM is allowed to modify the
>>> parts. Any modifiable configuration has to be placed outside the
>>> webapp. Furthermore, CM prefers that no exploded webapps be used,
>>> since it is much easier to distrubute wars.
>>
>> ok. So where do the per-system modifications go in? do your war files
>> have hard coded assumptions about LDAP bindings, JDBC URLS or rely on
>> the app server to set up the JNDI bindings for all the info kept in
>> your dir server?
> We have a system property that specifies the location of an XML file
> containing all these kinds of properties. Typically, it will go in the
> JBoss server's conf directory. We also have a more extensive
> configuration repository that is shared across servers and the XML
> config file has the information to connect to it.
Ok. So you do have central configs, its just outside the WAR. What I try
and do at work is bring up everything coherently, so the DB gets created
with the same username and password as the app server code is expecting.
When we bring up the system we have to put stuff into JBoss too, like
the mysql driver. I do that with a bit of the deployment that fetches
the library from the m2 cache and then copies it into the destination
directory
InstallDrivers extends Compound {
destDir TBD;
repo extends Maven2Library {
}
jdbcJAR extends JarArtifact {
project "mysql";
artifact "mysql-connector-java";
version "5.0.4";
sha1 "ce259b62d08cce86a68a8f17f5f9c8218371b235";
//link to the parent repository
library LAZY PARENT:repo;
}
copyJdbcDriver extends CopyFile {
source LAZY jdbcJAR ;
destination LAZY destDir ;
copyOnDeploy false;
overwrite false;
}
That thing only deploys if destDir is set to point to the relevant
configuration lib dir, before jboss comes up.
>>
>> Next question: how do ops automate the 'provisioning' of the app
>> server? Do they have a piece of paper telling them what bits of the
>> system you need 'Redhat EL with Java 1.5.06 and the patches need to
>> /etc/profile to get it set up, or what services need to be running? Do
>> you find that they decide to try 1.5.09 without telling you? Or that
>> they forget to do something essential like bringing up the DNS server
>> before the database and app servers come up.
> Ops never changes an OS version or Java version without it having been
> verified in our QA area first. Everyone is informed before that
> happens.
that's good. I wish I had worked with an ops team like that in this
project. And they probably wish they didnt have troublemakers like me.
http://people.apache.org/~stevel/slides/when_web_services_go_bad.pdf
> I must admit I've never had to tell our ops folks that DNS and
> the database must be up before starting the app server.
Its not so much telling ops what to do, but telling the system what to
do. the big nightmare problem was the hard reset, where some unexpected
power event would reboot everything simultaneously. In an NT domain, if
the PDC doesnt come up first, the other boxes dont authenticate and you
are left wondering why pages that hit the database fail. As for DNS, if
it starts failing with java.io.noRouteToHostException, do ops know its a
DNS problem, or do they stop at the word 'java' and phone the deve team.
>>
>> Because that's the kind of thing we can automate and lock down under
>> SCM. That lets us create a blank VMWare or Xen disk image, have it run
>> a PXE preboot to get the base image, then after it comes up we can
>> bring the system up to the state where the WAR file deploys.
>>
>> In that world, you dont really need an opts team to deploy. You just
>> have a server that manages the build and deploy of the latest bit of
>> the SCM tree tagged as ready to go into production. It sticks it out
>> every night, and as server load increases, it brings up new machines.
>> The ops team take on a different role: managing the Xen/VMWare server
>> farm, monitoring the health of the (much larger) VM cluster, setting
>> up the approved system configurations. This is the stuff that Amazon
>> EC2 presumably does behind the scenes -an outsourced ops team.
> That would probably never happen in my environment.
As long as your ops team is in control, all is well. My metric for this
is simple : are you scared of the phone ringing at weekends? We used to
have this story of the "developer relocation program" where developers
would get a new identity so they could avoud being paged. Sadly, it
doesnt exist.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Ralph Goers <Ra...@dslextreme.com>.
Steve Loughran wrote:
> Ralph Goers wrote:
>>
>>
>> Steve Loughran wrote:
>>> Simone Gianni wrote:
>>>
>>> The thing to remember about WAR files is that they are a packaging
>>> format that is intended to make it easy to deploy web apps. Not
>>> distribute, but deploy. The old WAR/EAR use cases always had the
>>> 'assembler' who would be some person who would somehow assemble WARs
>>> and EJB beans to make a working app, presumably through some GUI
>>> that required the same work to be repeated every release.
>>>
>>> If you are doing lots of late binding tuning to the WAR file, then
>>> perhaps build time is the wrong place to do it; it should really be
>>> done as part of the deployment process, where per machine
>>> optimisations can go in. In this world what you want from the outset
>>> is the exploded WAR, which is then taken with server-specific
>>> options to create the target WAR for the target system.
>> Pardon me for saying so, but this is just nuts.
>
> :)
>
>
>> In my environment our CM folks do the build and then make it
>> available for operations. Noone after CM is allowed to modify the
>> parts. Any modifiable configuration has to be placed outside the
>> webapp. Furthermore, CM prefers that no exploded webapps be used,
>> since it is much easier to distrubute wars.
>
> ok. So where do the per-system modifications go in? do your war files
> have hard coded assumptions about LDAP bindings, JDBC URLS or rely on
> the app server to set up the JNDI bindings for all the info kept in
> your dir server?
We have a system property that specifies the location of an XML file
containing all these kinds of properties. Typically, it will go in the
JBoss server's conf directory. We also have a more extensive
configuration repository that is shared across servers and the XML
config file has the information to connect to it.
>
> Next question: how do ops automate the 'provisioning' of the app
> server? Do they have a piece of paper telling them what bits of the
> system you need 'Redhat EL with Java 1.5.06 and the patches need to
> /etc/profile to get it set up, or what services need to be running? Do
> you find that they decide to try 1.5.09 without telling you? Or that
> they forget to do something essential like bringing up the DNS server
> before the database and app servers come up.
Ops never changes an OS version or Java version without it having been
verified in our QA area first. Everyone is informed before that
happens. I must admit I've never had to tell our ops folks that DNS and
the database must be up before starting the app server.
>
> Because that's the kind of thing we can automate and lock down under
> SCM. That lets us create a blank VMWare or Xen disk image, have it run
> a PXE preboot to get the base image, then after it comes up we can
> bring the system up to the state where the WAR file deploys.
>
> In that world, you dont really need an opts team to deploy. You just
> have a server that manages the build and deploy of the latest bit of
> the SCM tree tagged as ready to go into production. It sticks it out
> every night, and as server load increases, it brings up new machines.
> The ops team take on a different role: managing the Xen/VMWare server
> farm, monitoring the health of the (much larger) VM cluster, setting
> up the approved system configurations. This is the stuff that Amazon
> EC2 presumably does behind the scenes -an outsourced ops team.
That would probably never happen in my environment.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Steve Loughran <st...@apache.org>.
Jim Crossley wrote:
> Apologies if this is too off-topic, but...
>
> On Tue, 2006-12-05 at 17:28 +0000, Steve Loughran wrote:
>
>> Because that's the kind of thing we can automate and lock down under
>> SCM. That lets us create a blank VMWare or Xen disk image, have it run a
>> PXE preboot to get the base image, then after it comes up we can bring
>> the system up to the state where the WAR file deploys.
>
> This is a beautiful idea. Could you please cite any articles, books, or
> blogs that describe this "world" in more detail?
>
Well, I work on smartfrog, http://smartfrog.org/ which is a distributed
deployment framework. It has ant tasks, but not yet any m2 support,
because nobody has sat down to do them yet.
It can do the setup from the VMWare image down to setting the mime types
of your servlet.
An overview is :
http://people.apache.org/~stevel/slides/oscon.pdf
And a more recent one on using it for testing is:
http://smartfrog.org/presentations/distributed_testing_with_smartfrog_slides.pdf
with the video
http://smartfrog.org/autolinks/googleLTAC06.htm
This covers how you can treat a distributed test run as just another
part of your deployment, so run things like junit tests on eight
different machines, all against the same server. If you can start
selenium on those machines, you even get to test your site on the many
different browsers.
In none of these talks, do I discuss dynamic VM configuration, though we
are thinking of doing a talk on the topic at Apachecon europe, something
like "hosting fun on Xen and EC2", where we'd show how load monitoring
lets you deploy new virtual servers on demand on the Amazon EC2
infrastructure, surviving ./ at the cost of your visa bill. (actually,
thats a better title. "Using Amazon EC2 to survive slashdot attacks".
In the forthcoming "Ant in Action" book there is a chapter on
smartfrog, though again, no VM coverage. Its a bit too advanced for a
single chapter.
To get into VM stuff, there are a couple of things that are useful on
sourceforge
SmartDomains, from Cern, at http://smartdomains.sourceforge.net/ . These
are smartfrog components to manage Xen images, creating them on demand,
stopping them when needed. You deploy a manager on one real/virtual host
in the server farm, have it manage the rest.
LinuxCoe: http://linuxcoe.sourceforge.net/
This is how we create our virtual images, either by hand or by machine.
It is the code to host a server which provides a way to create kickstart
ISO images with custom linux boot parameters (network config, login
info). You set the VMWare/Xen box up to boot off the ISO file, and it
will bring up the OS.
To actually try it, go to http://www.instalinux.com/ . This gives you a
dialog where you choose your OS image, and all the packages that it
offers. Go through the forms, create the iso image, and bring it up in
VMWare player. For Xen you need different kernel builds, but the idea is
the same. You can also create a 'profile', which is a reusable custom
config.
Now, if you can demand create a bootable ISO image by hand, you can have
a machine do it. All you need is a file describing which packages to
install, what the network settings are, etc, and a program to talk to
the linuxcoe server or an equivalent over XML. You get the URL to the
ISO file back, download it to the shared FS of the VM cluster, and use
SmartDomains to bring up the new machine.
PXE preboot envs are a bit trickier. You need to deploy something that
handles the requests, preferably on the virtual network as otherwise you
can end up accidentally installing the OS on other people's real
machines. Its probably how the many-server companies like google, amazon
and MS work, as you can stick a blank box in the rack, switch it on, and
after a while its live.
So, my recommendations are
1. play with instalinux and vmware/xen
2. play with smartfrog
3. play with Amazon EC2
4. Get a 4-way CPU system with the virtualization op codes and as much
RAM as the mainboard will take. You'll need it. And lots of IDE storage
for backed up images.
Although dynamic VM creation is something that a lot of ops teams are
still nervy about, they need to recognise the control they get. They are
in charge in the images, they can lay down the profiles. And they can
give the developers virtual machines that match exactly what the devs
will get in production, so everyone can have a private (virtual) 3-tier
cluster to test their app on. More to the point, if you don't have the
VM creation under control, you've just created a maintenance nightmare.
Every month-old XP image is an unpatched host.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Brett Porter <br...@apache.org>.
I think this got lost in the thread (I'm just rereading the whole
thing).
Anyway, my opinion is that if we need extension points in mojos, the
mojos should be turned into smaller tasks - they are doing too much
work.
- Brett
On 06/12/2006, at 8:04 AM, John Casey wrote:
> Just going to chip in my $0.02 here...I think this might be an
> excellent
> point to start talking about "extension points" for maven plugins.
> These
> would simply be custom phases for the plugin to execute while it's
> doing the
> standard steps of a particular operation.
>
> I've thought about this sort of thing before in the context of the
> assembly
> plugin, where you might want to provide support for custom
> assembler phases.
> Also, I believe Jason and I talked about this before in the past.
>
> To me, the only thing that stands in the way of publishing an
> extension
> mechanism for a particular plugin is how best to form that extension
> contract. Is it enough to simply document the class that needs to be
> extended/implemented? What about plexus role-hints, and what about
> ordering/intermingling of standard and custom execution steps?
>
> I guess I'm beginning to think that a purely lifecycle-oriented
> solution to
> these sorts of problems won't scale...We'll either get caught up with
> allowing Nth-degree customization of bindings within a single
> phase; or,
> we'll wind up with a TON of potentially active phases; or, we'll
> have many
> cases like this one that simply can't be addressed easily.
>
> -john
>
> On 12/5/06, Jason van Zyl <ja...@maven.org> wrote:
>>
>>
>> On 5 Dec 06, at 1:42 PM 5 Dec 06, Jim Crossley wrote:
>>
>> > Apologies if this is too off-topic, but...
>> >
>> > On Tue, 2006-12-05 at 17:28 +0000, Steve Loughran wrote:
>> >
>> >> Because that's the kind of thing we can automate and lock down
>> under
>> >> SCM. That lets us create a blank VMWare or Xen disk image, have it
>> >> run a
>> >> PXE preboot to get the base image, then after it comes up we can
>> >> bring
>> >> the system up to the state where the WAR file deploys.
>> >
>> > This is a beautiful idea. Could you please cite any articles,
>> > books, or
>> > blogs that describe this "world" in more detail?
>> >
>>
>> http://idisk.maven.org/jvanzyl/Public/presos/Feynman.pdf
>>
>> > Thanks,
>> > Jim
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by John Casey <ca...@gmail.com>.
Just going to chip in my $0.02 here...I think this might be an excellent
point to start talking about "extension points" for maven plugins. These
would simply be custom phases for the plugin to execute while it's doing the
standard steps of a particular operation.
I've thought about this sort of thing before in the context of the assembly
plugin, where you might want to provide support for custom assembler phases.
Also, I believe Jason and I talked about this before in the past.
To me, the only thing that stands in the way of publishing an extension
mechanism for a particular plugin is how best to form that extension
contract. Is it enough to simply document the class that needs to be
extended/implemented? What about plexus role-hints, and what about
ordering/intermingling of standard and custom execution steps?
I guess I'm beginning to think that a purely lifecycle-oriented solution to
these sorts of problems won't scale...We'll either get caught up with
allowing Nth-degree customization of bindings within a single phase; or,
we'll wind up with a TON of potentially active phases; or, we'll have many
cases like this one that simply can't be addressed easily.
-john
On 12/5/06, Jason van Zyl <ja...@maven.org> wrote:
>
>
> On 5 Dec 06, at 1:42 PM 5 Dec 06, Jim Crossley wrote:
>
> > Apologies if this is too off-topic, but...
> >
> > On Tue, 2006-12-05 at 17:28 +0000, Steve Loughran wrote:
> >
> >> Because that's the kind of thing we can automate and lock down under
> >> SCM. That lets us create a blank VMWare or Xen disk image, have it
> >> run a
> >> PXE preboot to get the base image, then after it comes up we can
> >> bring
> >> the system up to the state where the WAR file deploys.
> >
> > This is a beautiful idea. Could you please cite any articles,
> > books, or
> > blogs that describe this "world" in more detail?
> >
>
> http://idisk.maven.org/jvanzyl/Public/presos/Feynman.pdf
>
> > Thanks,
> > Jim
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Jason van Zyl <ja...@maven.org>.
On 5 Dec 06, at 1:42 PM 5 Dec 06, Jim Crossley wrote:
> Apologies if this is too off-topic, but...
>
> On Tue, 2006-12-05 at 17:28 +0000, Steve Loughran wrote:
>
>> Because that's the kind of thing we can automate and lock down under
>> SCM. That lets us create a blank VMWare or Xen disk image, have it
>> run a
>> PXE preboot to get the base image, then after it comes up we can
>> bring
>> the system up to the state where the WAR file deploys.
>
> This is a beautiful idea. Could you please cite any articles,
> books, or
> blogs that describe this "world" in more detail?
>
http://idisk.maven.org/jvanzyl/Public/presos/Feynman.pdf
> Thanks,
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Jim Crossley <jc...@tandbergtv.com>.
Apologies if this is too off-topic, but...
On Tue, 2006-12-05 at 17:28 +0000, Steve Loughran wrote:
> Because that's the kind of thing we can automate and lock down under
> SCM. That lets us create a blank VMWare or Xen disk image, have it run a
> PXE preboot to get the base image, then after it comes up we can bring
> the system up to the state where the WAR file deploys.
This is a beautiful idea. Could you please cite any articles, books, or
blogs that describe this "world" in more detail?
Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Steve Loughran <st...@apache.org>.
Ralph Goers wrote:
>
>
> Steve Loughran wrote:
>> Simone Gianni wrote:
>>
>> The thing to remember about WAR files is that they are a packaging
>> format that is intended to make it easy to deploy web apps. Not
>> distribute, but deploy. The old WAR/EAR use cases always had the
>> 'assembler' who would be some person who would somehow assemble WARs
>> and EJB beans to make a working app, presumably through some GUI that
>> required the same work to be repeated every release.
>>
>> If you are doing lots of late binding tuning to the WAR file, then
>> perhaps build time is the wrong place to do it; it should really be
>> done as part of the deployment process, where per machine
>> optimisations can go in. In this world what you want from the outset
>> is the exploded WAR, which is then taken with server-specific options
>> to create the target WAR for the target system.
> Pardon me for saying so, but this is just nuts.
:)
> In my environment our
> CM folks do the build and then make it available for operations. Noone
> after CM is allowed to modify the parts. Any modifiable configuration
> has to be placed outside the webapp. Furthermore, CM prefers that no
> exploded webapps be used, since it is much easier to distrubute wars.
ok. So where do the per-system modifications go in? do your war files
have hard coded assumptions about LDAP bindings, JDBC URLS or rely on
the app server to set up the JNDI bindings for all the info kept in your
dir server?
Next question: how do ops automate the 'provisioning' of the app server?
Do they have a piece of paper telling them what bits of the system you
need 'Redhat EL with Java 1.5.06 and the patches need to /etc/profile to
get it set up, or what services need to be running? Do you find that
they decide to try 1.5.09 without telling you? Or that they forget to do
something essential like bringing up the DNS server before the database
and app servers come up.
Because that's the kind of thing we can automate and lock down under
SCM. That lets us create a blank VMWare or Xen disk image, have it run a
PXE preboot to get the base image, then after it comes up we can bring
the system up to the state where the WAR file deploys.
In that world, you dont really need an opts team to deploy. You just
have a server that manages the build and deploy of the latest bit of the
SCM tree tagged as ready to go into production. It sticks it out every
night, and as server load increases, it brings up new machines. The ops
team take on a different role: managing the Xen/VMWare server farm,
monitoring the health of the (much larger) VM cluster, setting up the
approved system configurations. This is the stuff that Amazon EC2
presumably does behind the scenes -an outsourced ops team.
Like I said, I work on fairly advanced deployment problems. Tuning WAR
files is a detail.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Ralph Goers <Ra...@dslextreme.com>.
Steve Loughran wrote:
> Simone Gianni wrote:
>
> The thing to remember about WAR files is that they are a packaging
> format that is intended to make it easy to deploy web apps. Not
> distribute, but deploy. The old WAR/EAR use cases always had the
> 'assembler' who would be some person who would somehow assemble WARs
> and EJB beans to make a working app, presumably through some GUI that
> required the same work to be repeated every release.
>
> If you are doing lots of late binding tuning to the WAR file, then
> perhaps build time is the wrong place to do it; it should really be
> done as part of the deployment process, where per machine
> optimisations can go in. In this world what you want from the outset
> is the exploded WAR, which is then taken with server-specific options
> to create the target WAR for the target system.
Pardon me for saying so, but this is just nuts. In my environment our
CM folks do the build and then make it available for operations. Noone
after CM is allowed to modify the parts. Any modifiable configuration
has to be placed outside the webapp. Furthermore, CM prefers that no
exploded webapps be used, since it is much easier to distrubute wars.
>
>
> FWIW, at work we've moved to a post-war mechanism where I bring up
> Jetty and do late binding configuration/deployment. Admittedly , I do
> work on the smartfrog deployment framework where such tuning is
> possible, but I got fed up with trying to add different servlets and
> log4j options to different systems. On my desk, I want log4j to go to
> the console, whereas in production log4j saves to rolling HTML files
> in a directory that is served up. There's no way to do that in WAR
> files without separate builds for each artifact.
We use our own logging framework that doesn't have this problem.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Steve Loughran <st...@apache.org>.
Fabian Christ wrote:
> Simone Gianni schrieb:
>> Steve Loughran wrote:
>>> The thing to remember about WAR files is that they are a packaging
>>> format that is intended to make it easy to deploy web apps. Not
>>> distribute, but deploy. The old WAR/EAR use cases always had the
>>> 'assembler' who would be some person who would somehow assemble WARs
>>> and EJB beans to make a working app, presumably through some GUI that
>>> required the same work to be repeated every release.
>>>
>>> If you are doing lots of late binding tuning to the WAR file, then
>>> perhaps build time is the wrong place to do it; it should really be
>>> done as part of the deployment process, where per machine
>>> optimisations can go in. In this world what you want from the outset
>>> is the exploded WAR, which is then taken with server-specific options
>>> to create the target WAR for the target system.
>> It's not late binding tuning with custom parameters. For example the
>> cocoon plugin was ment to unpack and write some configuration files in
>> the WAR, configuration files which are not bindings to external servers,
>> but settings for the internal servlets. In that case, it is a build
>> problem, and not a configuration one. Also, the web.xml often contains
>> directives which are "configuration" in the strict sense (like various
>> init parameters), but also contains all the assembly informations of a
>> web application, being unable to write plugins that can manipulate these
>> file in the build phase is, IMMO, a problem.
>>
>
> Hi together,
>
> I followed with interest your discussion about manipulating a WAR structure
> before building the WAR file. Here are some of my thoughts at this topic:
>
> First, the problem is not WAR specific as others here mentioned before. A WAR is
> nothing more than a zipped file structure. Now the problems described here arise
> when you try to modularize your web application. This is what Cocoon does with
> their blocks. Each block consists of Code and of WebApp-Resources. During the
> build process the code and the resources are repackaged as a WAR.
>
> A new pre-package phase in Maven might solve some problems that these people
> have when modularizing such a WAR. Now there is a concrete phase where such a
> job can be done. But I think the problem is more complex.
>
> I had the same problem some time ago and was thinking about something like a WAF
> (a Web Archive Fragment). A WAF describes a fragment of a WAR similar to Cocoon
> blocks. A WAF contains of a) Code and b) Resources. Now a WAR can depend on
> several WAFs that are integrated during the build. Here you get again problems,
> e.g.: How do you specify the order in which the WAFs are integrated? How do you
> handle conflicts when files from different WAFs are overwritten (patching)? How
> can you depend on code from a WAF (same problem with WARs today)?
>
> I came to the idea that at first you have to split code and resources in a WAF.
> This means that a WAF can produce two artifacts: a JAR and a file structure. So
> Maven must have support for defining projects that can have more than one
> artifact as result.
>
> As I said this problems are not WAR specific - other archive structures have the
> same problem. I think a general solution can be found here. Such a solution
> might look like:
>
> - allow multiple artifacts from one project (code JAR and resources ZIP)
> - allow configurable overlay of file structures (resources) with configurable
> orders, includes and excludes
> - allow file patching during the overlay as different modules might modify the
> same file and not overwrite each others changes
>
> By this you don't need something like a WAR plugin in the end as each project
> can define itself how the resulting archive is constructed from code and
> resources by an overlay mechanism. This is an important use case I think as you
> get independent for future archive formats. I know that those ideas are beyond
> the current discussion and break the philosophy of Maven in some points but
> perhaps someone is interested.
>
> - Fabian
>
I'm really enjoying this discussion too, because it shows up interesting
deployment use cases.
composite JARs/WARs/EARs are not that unusual. EAR files are the worst
in class, especially if you have to edit the manifest.mf /classpath to
provide relative references to other JARS. I think tools need to address
this problem.
In maven, you'd probably want to split each sub-piece into its own
build, and have a meta-project to pull them all together. Which of
course may mean restructuring your build.
In ant, well, you can create the stuff and use <ear> or <war> to stick
things together, but even those two tools punt on the problems of
getting the application.xml set up right (I normally hand code mine and
use Ivy to retrieve the dependencies without any -version tags), or of
doing manifest fixup (which i think is utterly wrong, BTW).
Its because of those target specific xml files that you do need specific
code in the plugins...
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Fabian Christ <fc...@gmx.de>.
Simone Gianni schrieb:
> Steve Loughran wrote:
>> The thing to remember about WAR files is that they are a packaging
>> format that is intended to make it easy to deploy web apps. Not
>> distribute, but deploy. The old WAR/EAR use cases always had the
>> 'assembler' who would be some person who would somehow assemble WARs
>> and EJB beans to make a working app, presumably through some GUI that
>> required the same work to be repeated every release.
>>
>> If you are doing lots of late binding tuning to the WAR file, then
>> perhaps build time is the wrong place to do it; it should really be
>> done as part of the deployment process, where per machine
>> optimisations can go in. In this world what you want from the outset
>> is the exploded WAR, which is then taken with server-specific options
>> to create the target WAR for the target system.
> It's not late binding tuning with custom parameters. For example the
> cocoon plugin was ment to unpack and write some configuration files in
> the WAR, configuration files which are not bindings to external servers,
> but settings for the internal servlets. In that case, it is a build
> problem, and not a configuration one. Also, the web.xml often contains
> directives which are "configuration" in the strict sense (like various
> init parameters), but also contains all the assembly informations of a
> web application, being unable to write plugins that can manipulate these
> file in the build phase is, IMMO, a problem.
>
Hi together,
I followed with interest your discussion about manipulating a WAR structure
before building the WAR file. Here are some of my thoughts at this topic:
First, the problem is not WAR specific as others here mentioned before. A WAR is
nothing more than a zipped file structure. Now the problems described here arise
when you try to modularize your web application. This is what Cocoon does with
their blocks. Each block consists of Code and of WebApp-Resources. During the
build process the code and the resources are repackaged as a WAR.
A new pre-package phase in Maven might solve some problems that these people
have when modularizing such a WAR. Now there is a concrete phase where such a
job can be done. But I think the problem is more complex.
I had the same problem some time ago and was thinking about something like a WAF
(a Web Archive Fragment). A WAF describes a fragment of a WAR similar to Cocoon
blocks. A WAF contains of a) Code and b) Resources. Now a WAR can depend on
several WAFs that are integrated during the build. Here you get again problems,
e.g.: How do you specify the order in which the WAFs are integrated? How do you
handle conflicts when files from different WAFs are overwritten (patching)? How
can you depend on code from a WAF (same problem with WARs today)?
I came to the idea that at first you have to split code and resources in a WAF.
This means that a WAF can produce two artifacts: a JAR and a file structure. So
Maven must have support for defining projects that can have more than one
artifact as result.
As I said this problems are not WAR specific - other archive structures have the
same problem. I think a general solution can be found here. Such a solution
might look like:
- allow multiple artifacts from one project (code JAR and resources ZIP)
- allow configurable overlay of file structures (resources) with configurable
orders, includes and excludes
- allow file patching during the overlay as different modules might modify the
same file and not overwrite each others changes
By this you don't need something like a WAR plugin in the end as each project
can define itself how the resulting archive is constructed from code and
resources by an overlay mechanism. This is an important use case I think as you
get independent for future archive formats. I know that those ideas are beyond
the current discussion and break the philosophy of Maven in some points but
perhaps someone is interested.
- Fabian
> Simone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Simone Gianni <si...@apache.org>.
Steve Loughran wrote:
> The thing to remember about WAR files is that they are a packaging
> format that is intended to make it easy to deploy web apps. Not
> distribute, but deploy. The old WAR/EAR use cases always had the
> 'assembler' who would be some person who would somehow assemble WARs
> and EJB beans to make a working app, presumably through some GUI that
> required the same work to be repeated every release.
>
> If you are doing lots of late binding tuning to the WAR file, then
> perhaps build time is the wrong place to do it; it should really be
> done as part of the deployment process, where per machine
> optimisations can go in. In this world what you want from the outset
> is the exploded WAR, which is then taken with server-specific options
> to create the target WAR for the target system.
It's not late binding tuning with custom parameters. For example the
cocoon plugin was ment to unpack and write some configuration files in
the WAR, configuration files which are not bindings to external servers,
but settings for the internal servlets. In that case, it is a build
problem, and not a configuration one. Also, the web.xml often contains
directives which are "configuration" in the strict sense (like various
init parameters), but also contains all the assembly informations of a
web application, being unable to write plugins that can manipulate these
file in the build phase is, IMMO, a problem.
Simone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Steve Loughran <st...@apache.org>.
Simone Gianni wrote:
> Stephane Nicoll wrote:
>> Yes, I've seen this thread as well. Sounds good to me even if we need
>> strong
>> use cases to create a new standard phase.
>>
> Basic use cases I've seen so far, applied to the WAR problem :
> - Cocoon team developed a plugin that deploys its blocks inside a war.
> This way, the user only have to specify which blocks their application
> depend on, and then the plugin will take them, unpack some certain files
> from a standard block jar structure inside some folders in the war, and
> do some other stuff on the web.xml and similar files. Right now this
> plugin has been developed as extending the AbstractWarMojo.
> Unfortunately this worked fine up to a certain version, but now fails
> with an NPE cause of what's written here
> http://www.mail-archive.com/dev@maven.apache.org/msg60770.html and here
> http://issues.apache.org/jira/browse/COCOON-1961 .
> - I've developed a plugin that applies XML patches to mostly every
> target directory structure, but if not subclassing the war mojo (and
> having the errors), or using other techniques (like running war exploded
> and then using the assembly plugin etc..), or using my patch
> (http://jira.codehaus.org/browse/MWAR-86 ) I have no way to see it work
> on a war directory structure before it gets packed.
> - For a project I'm doing and that I'll post on apache labs ASAP, I
> developed a plugin that taken a certain source folder structure creates
> a working cocoon application, generating sitemaps etc.. Same as above,
> no way to have it work to build a WAR out of it.
> - A friend of mine needed to run a legacy ant task on some files before
> packing the WAR, he wanted to use antrun but again... He ended up using
> war exploded and then appending to it's ant run a task to build the war.
>
> Adding a phase is, IMHHHO, not a lightweight change. Also, adding a
> "pre-package" phase sounds a bit like going back to maven1 pregoals, but
> a way to work between the prepare and the package phase of a packaging
> mojo is absolutely needed.
>
The thing to remember about WAR files is that they are a packaging
format that is intended to make it easy to deploy web apps. Not
distribute, but deploy. The old WAR/EAR use cases always had the
'assembler' who would be some person who would somehow assemble WARs and
EJB beans to make a working app, presumably through some GUI that
required the same work to be repeated every release.
If you are doing lots of late binding tuning to the WAR file, then
perhaps build time is the wrong place to do it; it should really be done
as part of the deployment process, where per machine optimisations can
go in. In this world what you want from the outset is the exploded WAR,
which is then taken with server-specific options to create the target
WAR for the target system.
FWIW, at work we've moved to a post-war mechanism where I bring up Jetty
and do late binding configuration/deployment. Admittedly , I do work on
the smartfrog deployment framework where such tuning is possible, but I
got fed up with trying to add different servlets and log4j options to
different systems. On my desk, I want log4j to go to the console,
whereas in production log4j saves to rolling HTML files in a directory
that is served up. There's no way to do that in WAR files without
separate builds for each artifact.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Simone Gianni <si...@apache.org>.
Stephane Nicoll wrote:
> Yes, I've seen this thread as well. Sounds good to me even if we need
> strong
> use cases to create a new standard phase.
>
Basic use cases I've seen so far, applied to the WAR problem :
- Cocoon team developed a plugin that deploys its blocks inside a war.
This way, the user only have to specify which blocks their application
depend on, and then the plugin will take them, unpack some certain files
from a standard block jar structure inside some folders in the war, and
do some other stuff on the web.xml and similar files. Right now this
plugin has been developed as extending the AbstractWarMojo.
Unfortunately this worked fine up to a certain version, but now fails
with an NPE cause of what's written here
http://www.mail-archive.com/dev@maven.apache.org/msg60770.html and here
http://issues.apache.org/jira/browse/COCOON-1961 .
- I've developed a plugin that applies XML patches to mostly every
target directory structure, but if not subclassing the war mojo (and
having the errors), or using other techniques (like running war exploded
and then using the assembly plugin etc..), or using my patch
(http://jira.codehaus.org/browse/MWAR-86 ) I have no way to see it work
on a war directory structure before it gets packed.
- For a project I'm doing and that I'll post on apache labs ASAP, I
developed a plugin that taken a certain source folder structure creates
a working cocoon application, generating sitemaps etc.. Same as above,
no way to have it work to build a WAR out of it.
- A friend of mine needed to run a legacy ant task on some files before
packing the WAR, he wanted to use antrun but again... He ended up using
war exploded and then appending to it's ant run a task to build the war.
Adding a phase is, IMHHHO, not a lightweight change. Also, adding a
"pre-package" phase sounds a bit like going back to maven1 pregoals, but
a way to work between the prepare and the package phase of a packaging
mojo is absolutely needed.
Simone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Antwort: Re: Manipulating the WAR directory before the WAR file gets built
Posted by Aa...@Globus.ch.
> Yes, I've seen this thread as well. Sounds good to me even if we need
> strong use cases to create a new standard phase.
How about adding support for custom phases to the POM?
That would allow developers and users to experiment with new phases and to
build some experience with which ones are useful and which only look good
but don't really work.
Incidentially, I'd like to see a tool which can show me what phases there
are and which plugin binds to which phase (in order to debug
execution/dependency problems like
https://jira.codehaus.org/browse/MSOURCES-11).
Regards,
--
Aaron Digulla
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Stephane Nicoll <st...@gmail.com>.
Yes, I've seen this thread as well. Sounds good to me even if we need strong
use cases to create a new standard phase.
Cheers,
Stéphane
On 12/4/06, Mark Hobson <ma...@gmail.com> wrote:
>
> This sounds similar to my requirement of splitting the package phase
> into pre-package and package. Pre-package would assemble the exploded
> archive, whereas package would perform the archiving itself. This
> would allow other mojos to contribute to the archive assembly phase as
> you require.
>
> See http://www.mail-archive.com/dev@maven.apache.org/msg62286.html
>
> Mark
>
> On 04/12/06, Stephane Nicoll <st...@gmail.com> wrote:
> > That's interesting. Could you please fill something in JIRA with your
> use
> > case and a sample?
> >
> > Thanks,
> >
> > Stéphane
> >
> > On 12/1/06, Simone Gianni <si...@apache.org> wrote:
> > >
> > > Hi all,
> > > I've developed a couple of plugin (one performs XML patches, the other
> > > builds a certain site structure). They both should work on the WAR
> > > directory structure, but before the WAR file is currently built.
> > >
> > > Apart from my specific needs, it could be quite common to need to
> > > perform some tasks (with an antrun for example) on the WAR directory
> > > structure before zipping it in the WAR file.
> > >
> > > Is there a way to hook these plugins (or any plugins) in between of
> the
> > > WAR plugin? In case, could it be a good idea to split the WAR plugin
> in
> > > two different goals so that it's possible to prepare the WAR directory
> > > structure and zip it in two different phases?
> > >
> > > Another option could be to use the WAR plugin to produce the directory
> > > structure (copying all the dependencies jars in place, doing war
> overlay
> > > etc..) and then use the assembly plugin (or antrun with a jar task :)
> )
> > > to produce the final WAR file. Is this possible?
> > >
> > > Thanks,
> > > Simone
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Simone Gianni <si...@apache.org>.
Mark Hobson wrote:
> This sounds similar to my requirement of splitting the package phase
> into pre-package and package. Pre-package would assemble the exploded
> archive, whereas package would perform the archiving itself. This
> would allow other mojos to contribute to the archive assembly phase as
> you require.
>
> See http://www.mail-archive.com/dev@maven.apache.org/msg62286.html
Absolutely. A pre-package would be the right hook to place the war
exploded goal so that it explodes the war structure, overlays and so on,
while on the package phase it will only package it.
Then other plugins could simply hook to the pre-package phase if they
need to work on the stuff that will end up in the war/jar/whatever else.
So, a big non-binding +1 for your proposal :)
Simone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Mark Hobson <ma...@gmail.com>.
This sounds similar to my requirement of splitting the package phase
into pre-package and package. Pre-package would assemble the exploded
archive, whereas package would perform the archiving itself. This
would allow other mojos to contribute to the archive assembly phase as
you require.
See http://www.mail-archive.com/dev@maven.apache.org/msg62286.html
Mark
On 04/12/06, Stephane Nicoll <st...@gmail.com> wrote:
> That's interesting. Could you please fill something in JIRA with your use
> case and a sample?
>
> Thanks,
>
> Stéphane
>
> On 12/1/06, Simone Gianni <si...@apache.org> wrote:
> >
> > Hi all,
> > I've developed a couple of plugin (one performs XML patches, the other
> > builds a certain site structure). They both should work on the WAR
> > directory structure, but before the WAR file is currently built.
> >
> > Apart from my specific needs, it could be quite common to need to
> > perform some tasks (with an antrun for example) on the WAR directory
> > structure before zipping it in the WAR file.
> >
> > Is there a way to hook these plugins (or any plugins) in between of the
> > WAR plugin? In case, could it be a good idea to split the WAR plugin in
> > two different goals so that it's possible to prepare the WAR directory
> > structure and zip it in two different phases?
> >
> > Another option could be to use the WAR plugin to produce the directory
> > structure (copying all the dependencies jars in place, doing war overlay
> > etc..) and then use the assembly plugin (or antrun with a jar task :) )
> > to produce the final WAR file. Is this possible?
> >
> > Thanks,
> > Simone
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Stephane Nicoll <st...@gmail.com>.
That's interesting. Could you please fill something in JIRA with your use
case and a sample?
Thanks,
Stéphane
On 12/1/06, Simone Gianni <si...@apache.org> wrote:
>
> Hi all,
> I've developed a couple of plugin (one performs XML patches, the other
> builds a certain site structure). They both should work on the WAR
> directory structure, but before the WAR file is currently built.
>
> Apart from my specific needs, it could be quite common to need to
> perform some tasks (with an antrun for example) on the WAR directory
> structure before zipping it in the WAR file.
>
> Is there a way to hook these plugins (or any plugins) in between of the
> WAR plugin? In case, could it be a good idea to split the WAR plugin in
> two different goals so that it's possible to prepare the WAR directory
> structure and zip it in two different phases?
>
> Another option could be to use the WAR plugin to produce the directory
> structure (copying all the dependencies jars in place, doing war overlay
> etc..) and then use the assembly plugin (or antrun with a jar task :) )
> to produce the final WAR file. Is this possible?
>
> Thanks,
> Simone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Brett Porter <br...@apache.org>.
Isn't that what war:war does?
On 02/12/2006, at 2:01 AM, Michael Horwitz wrote:
> On 12/1/06, Simone Gianni <si...@apache.org> wrote:
>>
>> Michael Horwitz wrote:
>> > Hi Simone,
>> >
>> > You could try the following:
>> >
>> > 1) Run the war:inplace goal.
>> > 2) Do the work on the exploded file.
>> > 3) Run the normal war goal.
>> >
>> > There is a danger that step 3 will undo some of the changes you
>> have
>> > made -
>> > it largely depends on what they are.
>> Yep, that's it, it redoes some parts of it :)
>>
>> Wasn't there a war:something that only does the "zip the war" part?
>
>
> Unfortunately not!
>
> Mike.
>
> Simone
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Simone Gianni <si...@apache.org>.
Mark Struberg wrote:
> --- Brett Porter <br...@apache.org> schrieb:
>
>> Isn't that what war:war does?
>>
> In theory (documentation) i would say yes:
>
>> This goal simply package the directory created by
>>
> war:webapp goal.
>
> But unfortunately (for what i see in the code) the
> buildExplodedWebapp is not seperated, but called from
> within the WarMojo, and it seems to me that the
> changes done manually may be overwritten.
>
> I haven't tested this though, so it's only a guess and
> you should give this a try.
>
Yep, exactly. I opened the issue
http://jira.codehaus.org/browse/MWAR-86, attached a patch, and commented
a typical use case (a plugin that patches some files in the war, before
"warring" it :) ).
With the patch there is a snippet of how successfully managed to obtain
create war structure -> work on it -> package the war file.
Simone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Mark Struberg <st...@yahoo.de>.
--- Brett Porter <br...@apache.org> schrieb:
> Isn't that what war:war does?
In theory (documentation) i would say yes:
>This goal simply package the directory created by
war:webapp goal.
But unfortunately (for what i see in the code) the
buildExplodedWebapp is not seperated, but called from
within the WarMojo, and it seems to me that the
changes done manually may be overwritten.
I haven't tested this though, so it's only a guess and
you should give this a try.
On the other hand, you may try to use the assembly
plugin to manually 'zip' your inplace war after your
changes.
But then you are really leaving the standard maven
path to build a war, whch may cause other troubles.
lg,
strub
--- Michael Horwitz <mi...@gmail.com> schrieb:
> On 12/1/06, Simone Gianni <si...@apache.org>
> wrote:
> >
> > Michael Horwitz wrote:
> > > Hi Simone,
> > >
> > > You could try the following:
> > >
> > > 1) Run the war:inplace goal.
> > > 2) Do the work on the exploded file.
> > > 3) Run the normal war goal.
> > >
> > > There is a danger that step 3 will undo some of
> the changes you have
> > > made -
> > > it largely depends on what they are.
> > Yep, that's it, it redoes some parts of it :)
> >
> > Wasn't there a war:something that only does the
> "zip the war" part?
>
>
> Unfortunately not!
>
> Mike.
>
> Simone
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail:
> dev-help@maven.apache.org
> >
> >
>
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Michael Horwitz <mi...@gmail.com>.
On 12/1/06, Simone Gianni <si...@apache.org> wrote:
>
> Michael Horwitz wrote:
> > Hi Simone,
> >
> > You could try the following:
> >
> > 1) Run the war:inplace goal.
> > 2) Do the work on the exploded file.
> > 3) Run the normal war goal.
> >
> > There is a danger that step 3 will undo some of the changes you have
> > made -
> > it largely depends on what they are.
> Yep, that's it, it redoes some parts of it :)
>
> Wasn't there a war:something that only does the "zip the war" part?
Unfortunately not!
Mike.
Simone
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Simone Gianni <si...@apache.org>.
Michael Horwitz wrote:
> Hi Simone,
>
> You could try the following:
>
> 1) Run the war:inplace goal.
> 2) Do the work on the exploded file.
> 3) Run the normal war goal.
>
> There is a danger that step 3 will undo some of the changes you have
> made -
> it largely depends on what they are.
Yep, that's it, it redoes some parts of it :)
Wasn't there a war:something that only does the "zip the war" part?
Simone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Manipulating the WAR directory before the WAR file gets built
Posted by Michael Horwitz <mi...@gmail.com>.
Hi Simone,
You could try the following:
1) Run the war:inplace goal.
2) Do the work on the exploded file.
3) Run the normal war goal.
There is a danger that step 3 will undo some of the changes you have made -
it largely depends on what they are.
Hope that helps!
Regards
Mike Howitz
On 12/1/06, Simone Gianni <si...@apache.org> wrote:
>
> Hi all,
> I've developed a couple of plugin (one performs XML patches, the other
> builds a certain site structure). They both should work on the WAR
> directory structure, but before the WAR file is currently built.
>
> Apart from my specific needs, it could be quite common to need to
> perform some tasks (with an antrun for example) on the WAR directory
> structure before zipping it in the WAR file.
>
> Is there a way to hook these plugins (or any plugins) in between of the
> WAR plugin? In case, could it be a good idea to split the WAR plugin in
> two different goals so that it's possible to prepare the WAR directory
> structure and zip it in two different phases?
>
> Another option could be to use the WAR plugin to produce the directory
> structure (copying all the dependencies jars in place, doing war overlay
> etc..) and then use the assembly plugin (or antrun with a jar task :) )
> to produce the final WAR file. Is this possible?
>
> Thanks,
> Simone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>