Andrew Williams wrote on Saturday, April 28, 2007 7:06 PM: > On 26 Apr 2007, at 13:20, Jörg Schaible wrote: > >> Hi Jason, >> >> Therefore the slots. The project itself can introduce them, if two >> major versions can be used at same time. Think about a hypothetical >> commons-logging 2.0 (it is discussed) that might have a different >> API. I am quite sure Jakarta folks will ensure that 2.x and 1.x >> series can be used at the same time - simply because even in the >> Maven repo itself ~ 2000 artifacts depend on it. Without something >> like the slots, you will never be able to create a new Maven-based >> project using JCL 2.x ... > > Well kick me if I am wrong, but is this not where well managed > projects use deprecation and wrappers around the new code to work > from the old API? I know plexus and classworlds are trying to for > backwards compatibility. > > What rule states that commons-logging 2.0 cannot contain the > api from > commons-logging 1.0 with deprecated marks? I doubt that everytime > someone wants to change their API they would much rather do > that than > make a mutually exclusive, thusly cohabitable, API for the > new version.
This is a decision of the project and not of Maven. Maven should be able to handle the situation though. Additionally your assumption is not valid, since a lot of projects maintain a y.x branch (e.g. to provide JDK 1.3 compatibility) and (y+1).x head with a cleaned up API and JDK 5 support only. That does not mean that the JDK 1.3 branch is obsolete or deprecated nor does it mean that no further maintenance releases will be available. Therefore I consider it even a bad idea to bundle both versions in the same jar. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
