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
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
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
Jim Crossley wrote:
Apologies if this is too off-topic, but...
On Tue, 2006-12-05 at 17:28 +, 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
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
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
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
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
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
Apologies if this is too off-topic, but...
On Tue, 2006-12-05 at 17:28 +, 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
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 +, 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
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
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
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 [EMAIL PROTECTED] wrote:
Hi all,
I've developed a couple of plugin (one performs XML patches, the other
builds a certain site structure). They both should
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
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 [EMAIL PROTECTED] wrote:
This sounds similar to my requirement of splitting the package phase
into pre-package and package.
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
Mark Struberg wrote:
--- Brett Porter [EMAIL PROTECTED] 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
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
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
--- Brett Porter [EMAIL PROTECTED] 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
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
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
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,
On 12/1/06, Simone Gianni [EMAIL PROTECTED] 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 -
Isn't that what war:war does?
On 02/12/2006, at 2:01 AM, Michael Horwitz wrote:
On 12/1/06, Simone Gianni [EMAIL PROTECTED] 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
26 matches
Mail list logo
