John Casey wrote:
So, I propose the following: we should do a very tightly focused 2.2.0
release next, and forget 2.1.1.
+1
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail
Hi Brett,
Brett Porter wrote at Mittwoch, 29. April 2009 01:24:
[snip]
> We don't have many ITs for the CLI options themselves, and I know that
> CLI upgrades have not been all that smooth in the past, so I'm a bit
> overly cautious :)
In fact 1.2 is more compatible to 1.0 than 1.1 ever was ;-)
It'd be nice if we could just use a different component repository or
something that was sensitive to a properties file. This custom component
repository (an actual thing in plexus right now, but with only one impl)
might use the properties file to read which role-hint to use as the
'default'
Sorry. I'm learning the git-svn workflow. I'll revise.
On Tue, Apr 28, 2009 at 7:24 PM, Brett Porter wrote:
>
> On 29/04/2009, at 8:17 AM, jdca...@apache.org wrote:
>
>>
>> Modified: maven/components/branches/maven-2.2.x/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/maven/components/branches/ma
On 29/04/2009, at 9:25 AM, Brian Fox wrote:
Besides inertial friction to a change, is there a specific reason
not to consolidate on a single http provider? We already know that
people may use the dav wagon simply to handle larger artifacts and
such, it seems like reducing our surface area
Besides inertial friction to a change, is there a specific reason not to
consolidate on a single http provider? We already know that people may
use the dav wagon simply to handle larger artifacts and such, it seems
like reducing our surface area here would help
I wouldn't be opposed to allowin
On 29/04/2009, at 8:17 AM, jdca...@apache.org wrote:
Modified: maven/components/branches/maven-2.2.x/pom.xml
URL:
http://svn.apache.org/viewvc/maven/components/branches/maven-2.2.x/pom.xml?rev=769567&r1=769566&r2=769567&view=diff
=
=
=
=
=
=
=
=
===
On 29/04/2009, at 4:15 AM, Brett Porter wrote:
On 29/04/2009, at 1:37 AM, John Casey wrote:
I'll file the issue, but we've come across a problem where long
passwords cause Sun's Base64 implementation to line-wrap the
Authorization HTTP header.
I've done extensive testing on this in our i
On 29/04/2009, at 7:32 AM, John Casey wrote:
My original message was to give people a chance to discuss whether
there was any reservation in just going to 2.2 as the next release
version. I know it was mentioned in the other thread, but IIRC
nobody really commented on it much.
I don't mi
My original message was to give people a chance to discuss whether there
was any reservation in just going to 2.2 as the next release version. I
know it was mentioned in the other thread, but IIRC nobody really
commented on it much.
Brian Fox wrote:
We already decided to move to 1.5 in 2.1 but
We already decided to move to 1.5 in 2.1 but never did. For me it's a
given in 2.2, why even bother debating it?
John Casey wrote:
Read MNG-4140. We had a solution much like you mention (it used string
searches, not DOM searches, but amounts to the same thine...the
element is context-sensitiv
On Tue, Apr 28, 2009 at 11:02 PM, John Casey wrote:
> So, what is an adequate reason in your eyes for moving to 1.5?
The thread you mentioned contained a few. ;-)
--
Don't trust a government that doesn't trust you.
-
To unsu
Read MNG-4140. We had a solution much like you mention (it used string
searches, not DOM searches, but amounts to the same thine...the
element is context-sensitive).
So, what is an adequate reason in your eyes for moving to 1.5?
Jochen Wiedmann wrote:
On Tue, Apr 28, 2009 at 10:24 PM, John C
I didn't said I'd like 1.5 for a 2.2 release, to show the runtime
prerequisite change
2009/4/28 nicolas de loof
> You've got my +1 for 1.5 upgrade.
> I spent too much time on old JEE appservers with XML parser issues and
> other frustrating runtime constraints, I don't wan to see Maven handle bu
On Tue, Apr 28, 2009 at 10:24 PM, John Casey wrote:
> 1. MNG-4140: even working around the NoClassDefFoundError for XPath* in JDK
> 1.4, this means that version expressions won't be interpolated on
> install/deploy unless JDK 1.5+ is used. This was something we talked about
> in [1].
If I unders
You've got my +1 for 1.5 upgrade.
I spent too much time on old JEE appservers with XML parser issues and other
frustrating runtime constraints, I don't wan to see Maven handle bugs with
complex workarounds just because some up-to-date dependencies cannot be
used. So fiew projects are still 1.4 comp
The problem is, the two http wagons share the same plexus role-hint.
This means one will always obscure the other inside the Maven runtime.
In any case, MNG-4147 is only the second reason for changing the Maven
release version from 2.1.1 to 2.2:
1. MNG-4140: even working around the NoClassDefF
On Tue, Apr 28, 2009 at 9:33 PM, John Casey wrote:
> However, there is another issue that I feel is important to address:
> MNG-4147.
I have to admit that I find the problem of a "very long password" fairly exotic.
Apart from that, there should be a possible workaround by explicitly choosing
the
Hi everyone,
We've spent a little time talking about whether the next release should
be 2.1.1 or 2.2. This has mainly played out around the issue of MNG-4140
and whether or not to require JDK 1.5 for the next release. We had
settled on a solution for 2.1.1 that allowed Maven to continue operat
On 29/04/2009, at 1:37 AM, John Casey wrote:
I'll file the issue, but we've come across a problem where long
passwords cause Sun's Base64 implementation to line-wrap the
Authorization HTTP header.
I've done extensive testing on this in our internal code, and found
that httpclient works pe
Lukas Theussl wrote:
>
>
> Benjamin Bentmann wrote:
>>> Author: bentmann
>>> Date: Fri Apr 10 22:42:19 2009
>>> New Revision: 764090
>>>
>>> URL: http://svn.apache.org/viewvc?rev=764090&view=rev
>>> Log:
>>> [MSITE-400] Make repository id for stage-deploy configurable
>>>
>>> Modified:
>>>
>>
I'll file the issue, but we've come across a problem where long
passwords cause Sun's Base64 implementation to line-wrap the
Authorization HTTP header.
I've done extensive testing on this in our internal code, and found that
httpclient works perfectly on the same cases.
-john
Brett Porter w
On 29/04/2009, at 12:09 AM, jdca...@apache.org wrote:
URL: http://svn.apache.org/viewvc?rev=769417&view=rev
Log:
update to use http wagon instead of lightweight http wagon, since
httpclient is already present for use in the webdav wagon.
I'm not sure about this - couldn't this have some oth
This vote now has sufficient votes to pass. However some concerns were
raised on legal-discuss (apparently a month ago and not mentioned here)
that may require some tweaks to the release profile. I'll hold on
promoting these poms until I better understand what we might be able to
improve.
HUY
Benjamin Bentmann wrote:
Author: bentmann
Date: Fri Apr 10 22:42:19 2009
New Revision: 764090
URL: http://svn.apache.org/viewvc?rev=764090&view=rev
Log:
[MSITE-400] Make repository id for stage-deploy configurable
Modified:
maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/m
Hi All,
I see that the changelog plugin 2.2 has only 3 issues which all are closed:
http://jira.codehaus.org/browse/MCHANGELOG/fixforversion/13634
Any chance of releasing it in the near future?
http://jira.codehaus.org/browse/MCHANGELOG-92 is of an interest here because
it should fix SVN under Ma
26 matches
Mail list logo
