On 30/06/2009, at 12:54 PM, Brian Fox wrote:
Yeah get rid of it. Is there really demand for the fixed in 2.0.11? I
feel like it's EOL now.
There's a couple of useful things in there, and given that they've
already been merged up there it seems like a nice way to wrap up the
series.
I a
Yeah get rid of it. Is there really demand for the fixed in 2.0.11? I
feel like it's EOL now.
On Mon, Jun 29, 2009 at 7:33 PM, Brett Porter wrote:
> Just a matter of clarity. If its not there, there will be no question about
> whether to merge to it or not.
>
> - Brett
>
> On 30/06/2009, at 4:12 A
+1, the issues I had with pre-emptive auth in the last one are fixed.
On Sun, Jun 28, 2009 at 1:01 PM, Benjamin
Bentmann wrote:
> John Casey wrote:
>
>> We've solved 28 issues for this release:
>>
>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=Html&version=15103
>
Hi everyone,
I'm a little behind on these releases; I'm just working on the updates
to the maven site docs that include the release notes (teased out
critical issues from others), and the downloads links. In any case, I
don't think I'm going to get this finished tonight.
I just wanted to let
On 30/06/2009, at 10:42 AM, John Casey wrote:
Well, in any case, see my changes to that document if you
want...I've removed references to deprecated configuration, and
termed it more of a general-case configuration option instead.
Looks good to me - thanks!
- Brett
-
Well, in any case, see my changes to that document if you want...I've
removed references to deprecated configuration, and termed it more of a
general-case configuration option instead.
Brett Porter wrote:
On 30/06/2009, at 10:16 AM, John Casey wrote:
Brett Porter wrote:
+ It's important
On 30/06/2009, at 10:16 AM, John Casey wrote:
Brett Porter wrote:
+ It's important to understand that the above method didn't allow
you to turn off the default HTTP headers; nor
+ did it allow you to specify headers on a per-method basis.
That's not quite true, since the only default hea
Brett Porter wrote:
+ It's important to understand that the above method didn't allow you
to turn off the default HTTP headers; nor
+ did it allow you to specify headers on a per-method basis.
That's not quite true, since the only default headers were the caching
ones, which could be disa
Okay, I'll correct the doc. I guess I'll need to look into the
User-Agent behavior more carefully to determine what's going on there.
-john
Brett Porter wrote:
On 30/06/2009, at 1:32 AM, John Casey wrote:
I'm guessing User-Agent needs to be documented as an exception, since
we setup User-
Just a matter of clarity. If its not there, there will be no question
about whether to merge to it or not.
- Brett
On 30/06/2009, at 4:12 AM, Paul Benedict wrote:
Hmm...
- declare 2.0.x EOL after that release and delete the branch
What harm is there in keeping it around? Even if you neve
On 30/06/2009, at 1:32 AM, John Casey wrote:
I'm guessing User-Agent needs to be documented as an exception,
since we setup User-Agent through the DefaultWagonManager (IIRC, you
and I worked on that for 2.1.0). I'm sure the logic in
DefaultWagonManager overrides what you setup above.
O
On 30/06/2009, at 5:45 AM, Benjamin Bentmann wrote:
Hi Brett,
Unfortunately this broke the build on my machine (maybe because of a
difference in working copy version?).
Hm, can you provide some more details on the failure? I only tested
with WinXP and Ubuntu and don't have a Mac at hand,
On 30/06/2009, at 5:02 AM, Benjamin Bentmann wrote:
John Casey wrote:
So, would you say it'd be better to reopen 3057 and assign it to
3.x, or open a new issue that references 3057 and 4167, and assign
that to 3.x?
That's actually the question that I couldn't answer for myself and
the
+4
Brett Porter wrote:
With the 2.2.0 release coming up, I've started to find the amount of
merging (and consistency of it) is becoming harder, and I think it might
be inevitable that there'll be confusion from users about what release
is the right one to use.
I'd like to suggest the followi
Okay, that's done. MNG-4223 is the new issue if you're interested.
Benjamin Bentmann wrote:
John Casey wrote:
So, would you say it'd be better to reopen 3057 and assign it to 3.x,
or open a new issue that references 3057 and 4167, and assign that to
3.x?
That's actually the question that I
Hi Brett,
Unfortunately this broke the build on my machine (maybe because of a
difference in working copy version?).
Hm, can you provide some more details on the failure? I only tested with
WinXP and Ubuntu and don't have a Mac at hand, so can't reproduce
easily. No idea whether I just misco
Myself, I prefer to create a branch only when I need it.
If one day we need to work on 2.0.x, we'll start a new branch copied
from the last tag. We have already in SVN many branches for which we
don't know if they are useful or not.
Cheers,
Arnaud
# Arnaud Héritier
# http://blog.aheritier.net
+4 also
Cheers,
Arnaud
# Arnaud Héritier
# http://blog.aheritier.net
On Mon, Jun 29, 2009 at 7:21 PM, Benjamin Bentmann <
benjamin.bentm...@udo.edu> wrote:
> Brett Porter wrote:
>
> - remove the 2.1.1 version from JIRA and remove the 2.1.x SVN branch -
>>
>
> +1
>
> - promote the 2.2.0 as th
John Casey wrote:
So, would you say it'd be better to reopen 3057 and
assign it to 3.x, or open a new issue that references 3057 and 4167, and
assign that to 3.x?
That's actually the question that I couldn't answer for myself and the
only other opinion so far was an "Agreed" by Brett on an "
That's a fair point. So, would you say it'd be better to reopen 3057 and
assign it to 3.x, or open a new issue that references 3057 and 4167, and
assign that to 3.x?
I lost track of the original reason 4167 was opened, which has indeed
been resolved. Apologies for not paying attention to the p
Hmm...
>> - declare 2.0.x EOL after that release and delete the branch
What harm is there in keeping it around? Even if you never return to
it, it doesn't cost you anything to keep it.
Paul
-
To unsubscribe, e-mail: dev-unsubsc
John Casey wrote:
I've backed out all version-expression transformation, including the
code that was added in 2.1.0-*.
Yup, got that.
So, 4167 isn't fixed to my knowledge.
I basically don't follow your comment on MNG-3538:
> This issue duplicates the reports in MNG-3057 and MNG-4167
To re
Brett Porter wrote:
- remove the 2.1.1 version from JIRA and remove the 2.1.x SVN branch -
+1
- promote the 2.2.0 as the stable release on the site and push all
bugfix work towards 2.2.x
+1
- a 2.0.11 release to get those sticking to 2.0.x the 37 fixes already
committed there.
+1
- d
I've backed out all version-expression transformation, including the
code that was added in 2.1.0-*. The reason for this is that
version-expression transformation causes critical problems with GPG,
etc. that are blockers for doing releases and such. After exploring this
issue thoroughly to addr
Brett Porter wrote:
On 23/06/2009, at 8:56 AM, jdca...@apache.org wrote:
Author: jdcasey
Date: Mon Jun 22 22:56:25 2009
New Revision: 787433
URL: http://svn.apache.org/viewvc?rev=787433&view=rev
Log:
Adding documentation for (proposed) new httpclient-based wagon
configuration.
Added:
ma
The Maven team is pleased to announce the release of the Maven PDF Plugin, version
1.0.
This plug-in allows you to generate a PDF version of your project's
documentation.
http://maven.apache.org/plugins/maven-pdf-plugin/
You should specify the version in your project's plugin configuration
+1Nicolas
2009/6/29 Lukas Theussl
>
> +1
>
> -Lukas
>
> John Casey wrote:
>
>> Hi,
>>
>> I've resolved the issue with plexus-interpolation, reverified the ITs, and
>> restaged the release. The URLs below have been updated. Let's see if we can
>> get through this vote without further interruption
+1
-Lukas
John Casey wrote:
Hi,
I've resolved the issue with plexus-interpolation, reverified the ITs,
and restaged the release. The URLs below have been updated. Let's see if
we can get through this vote without further interruption, I guess.
See also the documentation improvements listi
+1
-Lukas
John Casey wrote:
Hi,
I'd like to call a vote for the release of Maven Wagon 1.0-beta-6. I've
opted not to shoot for a 1.0 release here, since there are still
something like four outstanding issues of various intricacy open for the
1.0 release, and I wanted to get several importa
On Mon, Jun 29, 2009 at 4:28 AM, Paul Benedict wrote:
> Will the release notes contain any general justification for an
> upgrade? For example, can it highlight the major improvements between
> 2.1 and 2.2? or 2.0 and 2.2?
>
+1
Totally agree. It starts to be very difficult for user to follow/u
30 matches
Mail list logo
