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 chi
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 per
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 ima
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 alw
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 wou
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
'assemb
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
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
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 i
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
> an
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 pe
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 someh
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 wa
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 u
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 pha
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) th
> 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 u
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. Pre-pac
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 ht
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
--- 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
wit
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
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
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, th
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/
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 (w
26 matches
Mail list logo
