>>> 2. removed deprecated ThreadControl and ThreadPool >> it sounds as if we just broke >> org.apache.james.util.thread.DefaultThreadPool.
> Nothing is broken. Oh? > James is not dependent on the updates I have made. Are the updates going into a release that James should be using? Did you look at the code in James that I referenced? > If James is dependent on deprecated interfaces then in order > to migrate from a 1.X to a 2.X James code would need to be updated. Deprecation is not removal. There is a reason why Sun has left the deprecated interaces in J2SE, rather than remove them. But this is a minor point compared to the one that really has me going. > > Unfortunately, with all of the shuffling of file locations, we've > > effectively lost all of the CVS history, so when I look at > > something like > > http://cvs.apache.org/viewcvs.cgi/avalon-xcalibur/thread/impl/src/java/org/a pache/avalon/excalibur/thread/impl/ResourceLimitingThreadPool.java, there > > is no history *at all* to see. > None of the current codebase has been touched. You have full CVS > history under the src directory. So then what is in http://cvs.apache.org/viewcvs.cgi/avalon-xcalibur/thread/impl/src/java/org/a pache/avalon/excalibur/thread/impl? Is that a throwaway, or the new location? If it isn't clear, that is rhetorical. The old code is replaced by the new refactoring, and the history has been lost from the perspective of the code. I cannot find the history without chasing down which file is the current one for where, and where that file came from before, and mentally link together the history. History should not be distributed and disconnected from the code. > If someone wants to help on things like getting CVS history updated - great. CVS doesn't work that way. You are running into one of those areas where CVS is a disaster, and SVN shines. With SVN, we could do: svn cp MyClass MyClassInterface svn mv MyClass MyClassImpl and commit changes so that one is the interface, one is the implementation, and no history is lost. We could sort of do that in CVS, but it would require copying the actual ",v" files, is not accessible to most, and has other bad consequences. > THE LOGS ARE NOT GONE. Yes they are. Maybe not from the current location, until someone says "Oh, we don't need those anymore, since they've been refactored", but from a practical perspective, they are gone: the code is no longer attached its history. > I'm interested in getting some of the excalibur content into a > maintainable state - and that means getting rid of the > deprecated content. There are two issues. One is that you are changing interfaces. The other is that as you are doing it, you are separating the code from its history. I am far more concerned and annoyed about the latter, although I don't believe that you are taking stability of interfaces seriously enough as a platform provider. I'll accept that some interface change is necessary to get the code to a more stable place. The disconnecting of code from history is a more serious issue. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
