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
On 03/12/06, Jason van Zyl [EMAIL PROTECTED] wrote:
What else would use it. I'm generally fine with things changing
provided you have the magic three. And can you think of any adverse
affects or conflicts with other phases. I can't think of any off the
top of my head but adding a new lifecycle
On 03/12/06, Brett Porter [EMAIL PROTECTED] wrote:
Pretty sure the issue already exists... should just be done IMO.
Ah-ha, found it.. :)
http://jira.codehaus.org/browse/MNG-2097
Mark
-
To unsubscribe, e-mail: [EMAIL
Hi,
As a side note it strikes me that the primary problem is that the war:war
goal does a little too much in a single go during the packaging phase. Could
the issue be solved by spreading the work of the war:war goal through the
existing phases?
Mike Horwitz
On 12/4/06, Mark Hobson [EMAIL
Actually, before we jump into this, let's consider the use case at
hand. While easily solved by pre-package at this point, we may find
other needs.
Currently, *-resources handles class path resources, which are
required to be treated separately to the package because in many
cases, such
On 04/12/06, Brett Porter [EMAIL PROTECTED] wrote:
Actually, before we jump into this, let's consider the use case at
hand. While easily solved by pre-package at this point, we may find
other needs.
Currently, *-resources handles class path resources, which are
required to be treated separately
On 04/12/2006, at 10:24 PM, Mark Hobson wrote:
Sounds good; although in the case of a war, would executing up to the
process-package-resources phase produce the fully exploded war? Or
would the package resources only contain the web resources, omitting
WEB-INF/**?
My use-case would require
On 04/12/06, Brett Porter [EMAIL PROTECTED] wrote:
Well, it would be like other archives. By default, it would pull them
from the various added sources straight into the archive - src/main/
webapp, target/generated-package-resources, for example. However, it
would be sensible for the war plugin
Brett Porter wrote:
Actually, before we jump into this, let's consider the use case at hand.
While easily solved by pre-package at this point, we may find other needs.
To take these suggestions even further, perhaps the idea of a fixed set
of phases is too limiting. An alternative would be to
Pretty sure we've shouted it down with reasons before, hopefully the
archives will be of some assistance :)
- Brett
On 05/12/2006, at 12:08 AM, Richard van der Hoff wrote:
Brett Porter wrote:
Actually, before we jump into this, let's consider the use case at
hand. While easily solved by
On 4 Dec 2006, at 14:08, Richard van der Hoff wrote:
Brett Porter wrote:
Actually, before we jump into this, let's consider the use case at
hand. While easily solved by pre-package at this point, we may
find other needs.
To take these suggestions even further, perhaps the idea of a fixed
Richard,
I love this idea and hate it at the same time. The idea of using
numbers, as I'm sure has been pointed out before, just seems awful. But
I understand what you are driving at. If there was a way to register
named phases with the numbers that would be better.
OTOH, wouldn't it be
On 4 Dec 06, at 9:59 AM 4 Dec 06, Ralph Goers wrote:
Richard,
I love this idea and hate it at the same time. The idea of using
numbers, as I'm sure has been pointed out before, just seems awful.
But I understand what you are driving at. If there was a way to
register named phases with
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
Richard van der Hoff [EMAIL PROTECTED] schrieb am 04.12.2006
14:08:37:
Actually, before we jump into this, let's consider the use case at
hand.
While easily solved by pre-package at this point, we may find other
needs.
To take these suggestions even further, perhaps the idea of a fixed
On 4 Dec 2006, at 16:51, Jason van Zyl wrote:
On 4 Dec 06, at 9:59 AM 4 Dec 06, Ralph Goers wrote:
Richard,
I love this idea and hate it at the same time. The idea of using
numbers, as I'm sure has been pointed out before, just seems
awful. But I understand what you are driving at. If
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
Jason van Zyl [EMAIL PROTECTED] schrieb am 04.12.2006 16:51:30:
You can always make your own lifecycle, which is not that hard if you
really need it.[...]To
allow free form to accommodate the ever shrinking number of cases we
can't handle is just not worth it. The standard lifecycle then
On 4 Dec 06, at 11:14 AM 4 Dec 06, [EMAIL PROTECTED] wrote:
Richard van der Hoff [EMAIL PROTECTED] schrieb am 04.12.2006
14:08:37:
Actually, before we jump into this, let's consider the use case at
hand.
While easily solved by pre-package at this point, we may find other
needs.
To take
Hi guys,
The Maven Embedder schema writer does not generate the pom.xml with the
schema definitions, so I went out for the maven-model and generated the
sources and I haven't found a way to add the schema defiition without
changing the generated sources (something that is truly evil).
The
Hi Guys,
What's left to do before the M1 release can go out? We need to get
the Maven 1.x repository usage off Ibiblio.
Jason.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
According to the roadmap [1], there's 25 issues left. Mostly plugin upgrades
which could come quite quickly and at least 1755 and 1789. The problem is
that we're trying to release RC1 and it makes not much sense if we have
still open issues scheduled for 1.1
Cheers,
Stéphane
[1]
what I see is that there's always issues that anyone wants to get
fixed and that makes the releases take forever. If things are not
critical imho is more important to release often and move issues to
1.1.1
On 12/4/06, Stephane Nicoll [EMAIL PROTECTED] wrote:
Hi,
According to the roadmap [1],
On 12/5/06, Carlos Sanchez [EMAIL PROTECTED] wrote:
what I see is that there's always issues that anyone wants to get
fixed and that makes the releases take forever. If things are not
critical imho is more important to release often and move issues to
1.1.1
Then we should at least fix 1755 and
Exactly... Trying to quantify the stability of a release before it
goes out the door is just impossible/not practical for os.
Release early often. ;)
On 12/4/06, Carlos Sanchez [EMAIL PROTECTED] wrote:
what I see is that there's always issues that anyone wants to get
fixed and that makes the
The only real condition for Maven 1.1 is making sure backwards compat
is intact, or at least documented where broken intentionally.
- Brett
On 05/12/2006, at 1:47 PM, Jesse Kuhnert wrote:
Exactly... Trying to quantify the stability of a release before it
goes out the door is just
30 matches
Mail list logo
