Noel:
The sources for excalibur thread 1.1.1 and excalibur pool 1.2 remain in the respective /src directories and irrespective of anything going on will not dissapear suddenly. Once I've got everything validated I'll tag the /src content and remove it from CVS head assuming there is consensus to do so. But that's a subject for later.
The immediate subject of the api, impl, and instrumented package separations (which introduce the history disconnect) deal with the following problems:
1. the practice of including optional classes in a package
definition which plays havoc with automated resource
loading - addressed through separation of the api from
implementation, and secondly, through separation of
different implementation variants based on dependencies 2. cleaning up of the codebase to bring it into a
maintainable state while maintaining the current 1.X
codebase - involving the establishment of a 2.X major
version increment and removal of deprecated contentYes - CVS history is an issue however its a issue that has to be considered against the benefits of actually getting a clean api/impl separation in place and validated, enabling the assessment of the real ramifications of updated apis throughout the codebase. So far the ramifications arising from the excalibur and cornerstone updates involve the following:
* replacement of deprecated org.apache.avalon.excalibur.thread
with org org.apache.excalibur.thread for ThreadControl, ThreadPool
and Executable* usage of DefaultPool/getSize replaced by DefaultPool/size
* users of instrumented pools and thread pools migrating to the
instrumented package and instrumented implementations. * clients dependent on the connection handler factory implementations
in cornerstone connection will need to include the impl jar into
the classpathAs far as the impact on James is concerned - according to the result of building james against the updated content:
SimpleConnectionManager, removal of the placeholder operation that adapts between the deprecated and non-deprecated ThreadPool.
AbstractJamesService, removal of the casting to the deprecated ThreadPool interface.
A couple of minor code updates relating to context references that I don't completely understand just at the moment but relate to the addition of native avalon descriptors in the cornerstone blocks.
Aside from that I have james running against the candidate excalibur content, the candidate cornerstone blocks, and a very slightly modified james head. I can send you a diff if you like.
Stephen.
Noel J. Bergman wrote:
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]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
