On 4 Dec 06, at 10:06 PM 4 Dec 06, Brett Porter wrote:
The only real condition for Maven 1.1 is making sure backwards
compat is intact, or at least documented where broken intentionally.
+1
Change the default central repo and throw the baby out the window.
Someone will catch it.
Jason.
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 impossible/
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 th
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 an
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],
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]
http://ji
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 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 co
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
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 t
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
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
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
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
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 t
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 bet
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
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 pr
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
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
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 th
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 separatel
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 a
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 PRO
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 PROTEC
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
> 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
31 matches
Mail list logo