You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2006/03/07 15:47:30 UTC
A couple of javamail questions
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")?
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.
Rick
Re: A couple of javamail questions
Posted by Dain Sundstrom <da...@iq80.com>.
On Mar 7, 2006, at 10:42 AM, Rick McGuire wrote:
> Dain Sundstrom wrote:
>> 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).
> I was talking more about the individual providers within the module
> (smtp, nntp, pop3, etc.). smtp was introduced first, while the
> others are just getting introduced. If we use the Geronimo version
> number, then the first releases of nntp and pop3 will be 1.2, and
> the smtp version number will skip from 1.0 to 1.2.
I think the rule should be the vendor version number in the file is
the same as the maven module version number. I'm fine with
independently versioning these, which would require us to create
separate svn versioned trees (${name}/trunk/ ${name}/tbranches/ $
{name}/ttags/)for each plugin.
-dain
Re: A couple of javamail questions
Posted by Rick McGuire <ri...@gmail.com>.
Dain Sundstrom wrote:
> 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).
I was talking more about the individual providers within the module
(smtp, nntp, pop3, etc.). smtp was introduced first, while the others
are just getting introduced. If we use the Geronimo version number,
then the first releases of nntp and pop3 will be 1.2, and the smtp
version number will skip from 1.0 to 1.2.
>
> -dain
>
>
Re: A couple of javamail questions
Posted by Dain Sundstrom <da...@iq80.com>.
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
Re: A couple of javamail questions
Posted by Rick McGuire <ri...@gmail.com>.
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. I just
wasn't certain we wanted to increment all of the version numbers for the
providers even if nothing changed in the code.
>
> -dain
>
Re: A couple of javamail questions
Posted by Dain Sundstrom <da...@iq80.com>.
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?
-dain