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 <[email protected]> > 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 compatible ! I myself updated the GWT > plugin to 1.5 by claiming GWT uses this API level itslef :p > > As a side effect, with migration to 1.5 we could use generics for API > collections, and avoid newbee (and other) developpers to search by hand what > project.getArtifacts() returns as type ;) > > Nicolas > > 2009/4/28 John Casey <[email protected]> > > 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 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]. >> >> While catching NoClassDefFoundError seemed like a solution, it will >> actually regress the behavior for JDK 1.4 users...version-expression >> interpolation won't happen at all for them. >> >> >> 2. MNG-4147: the aforementioned case where long passwords cause line >> wrapping in the Authorization header value. This may not be compelling by >> itself, but leaving both this and the interpolation changes above out makes >> Maven 2.1.1 a whole lot less attractive IMO. >> >> >> -john >> >> [1] http://tinyurl.com/cqcrlp >> >> >> Jochen Wiedmann wrote: >> >>> On Tue, Apr 28, 2009 at 9:33 PM, John Casey <[email protected]> >>> 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 httpclient-based wagon implementation. (This workaround isn't >>> mentioned >>> in the issue. Shouldn't it?) >>> >>> In summary, I think this is no reason for heavy changes like switching >>> to 1.5, or >>> replacing the default Wagon implementation. >>> >>> >>> Jochen >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
