Stefano, > I just finished re-upgrading my local copy to the phoenix in this branch > https://svn.apache.org/repos/asf/avalon/cvs-migration-snapshot/avalon-phoeni x/
I think that Peter Royal has a good basic point about keeping our own copy. If we use his, or just the code from Avalon, we can maintain it under james source control, although as a separate, entirely internal, project. In your case, that would mean something like: svn mkdir https://svn.apache.org/repos/asf/james/avalon-platform svn mkdir https://svn.apache.org/repos/asf/james/avalon-platform/phoenix svn cp \ https://svn.apache.org/repos/asf/avalon/cvs-migration-snapshot/avalon-phoe nix/ https://svn.apache.org/repos/asf/james/avalon-platform/phoenix/trunk Similar for any other Avalon components that we want to use that need to be properly tagged for our releases. According to Peter, "What I had sent was an older CVS checkout, the code in the svn url above is a bit newer, but very similar." Can you check to see what differences exist between the code you are now using, and Peter's? If the consensus is that we should use what's in SVN, the above approach should be OK. > I'm ready to commit build.xml changes and phoenix-bin but as many > libraries are changed maybe someone would like to test it before I > change the whole phoenix-bin folder. > Should I commit anyway and eventually we will revert the commit Sure. > this upgrade would allow me to fix the last issue I planned to fix > before the first alpha/beta of James 2.3.0 (classloader issues). If > we upgrade to phoenix-trunk I can remove all the specific code in our > Loader and leave this task to the container. OK > Can you update us on you plans? I've been tracking your changes, and figured that the short time it was taking to get them into source control was well spent. > This upgrade and the last 2 patches (CopyOnWriteProxy for mimemessages > and POP3handler using getRawInputStream instead if getInputStream) are > "critical" Yes, the copy-on-write behavior is the one that I am most concerned about from the perspective of performance and memory footprint. I haven't looked, but it is an interesting question whether or not the Message-ID should be changed, too. But that really depends upon the nature of a change, and is entirely application semantic dependent. The recent change to SMTP and POP3 may also fix an older and relatively boring issue that a totally empty message, i.e., DATA<CR><LF>.<CR><LF> would not be supported. We'll have to test it. > I thought about moving these issues to 3.0 but IMHO they are > too critical to release 2.3.0 without them. And this is part of why I keep thinking that we should call this release 3.0. > About "tests" I felt free to commit the good starting work from Bernd Given the volume of work we're getting from Bernd, I'd like to ask if he would please submit a CLA. :-) And perhaps work towards Committer status. :-) > We will discuss how to handle the ristretto/junit jar later! > (IIRC latest news from Apache said that we can ship MPL jars > if there is full consensus by committers). We can run this by Cliff. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
