On Mar 7, 2006, at 9:44 AM, Rick McGuire wrote:
Dain Sundstrom wrote:
On Mar 7, 2006, at 6:47 AM, Rick McGuire wrote:
I'm currently working on adding NNTP Store support to the
Geronimo javamail code, which is built on top of the code that
was integrated last week that added NNTP Transport support. I've
ran into a little gotcha on this. The Store and Transport
providers are defined in the javamail.default.providers file, and
all providers must be unique (e.g., smtp, pop3, etc.). For NNTP,
we're going to have both a Store and a Transport, and only one
can have the nntp name. The Sun impl doesn't have nntp, so
there's no guidance from that corner.
GNU classpath has an NNTP implementation, and that version uses
"nntp" for the Store, and "nntp-post" for the Transport. The
Geronimo code is currently using "nntp" for the Transport, but
it's easy enough to change that as I doubt this code is widely
used after less than one week. Should we copy what GNU did or
use something else (perhaps "nntp" and "news")?
I think we should follow the convention of GNU classpath
Also, the vendor information in the javamaildefault.providers
file includes version numbers. Should we be incrementing at
least the smtp version number since this has changed considerably
since the last Geronimo release, or should we change these to
line up with Geronimo release versions. Thus new providers would
not be 1.0 even though they are new in this release.
Can we make the vendor version number match the module version
number in Maven?
Fairly easily done, but it is a manual process at the moment.
Nothing a little velocity can't fix :)
I just wasn't certain we wanted to increment all of the version
numbers for the providers even if nothing changed in the code.
I definitely think the numbers should match. If we want this module
to move at a different rate and pace then the main server, we move
the code to be next to the geronimo tree (a.k.a. a sub project).
-dain
