james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Review/Help for Phoenix trunk upgrade (Noel?)
Date Tue, 03 Jan 2006 18:23:22 GMT
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message