You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Alex Blewitt <Al...@ioshq.com> on 2003/08/17 11:01:13 UTC
[PATCH] [JavaMail] Created resources directory and copied META-INF contents
Here's the JavaMail resources directory (Jar contains
specs/javamail/src/resources/META-INF/javamail.default.*)
Should also be removed from the specs/javamail/src/java/META-INF
directory, but I can't figure out how to generate that as a patch,
sorry. :-/
Re: [PATCH] [JavaMail] Created resources directory and copied META-INF contents
Posted by Alex Blewitt <Al...@ioshq.com>.
Jeremy,
On Monday, Aug 18, 2003, at 18:34 Europe/London, Jeremy Boynes wrote:
> Applied - but I have questions on the reference to
> org.apache.commons.mail
>
> Is this correct? Should this instead be in that implementation?
They should be moved to the org.apache.?.mail implementation as and
when it becomes available, yes. I wanted to put it in the API initially
(and then delete it later) so that (a) the documented format/place of
the file was available, and (b) if I get trucked tomorrow then someone
else can pick up on it later :-)
When I have the skeletal Apache implementation, the resources will move
in their entirety to that package.
Alex.
Re: [JavaMail] concerns
Posted by Stephen McConnell <mc...@apache.org>.
Richard Monson-Haefel wrote:
>The critique of Alex's contribution is certainly well intended, but its also
>kind of odd. Why should the critic complain that there is not enough
>planning and then go on to say that Alex's impl cannot be differentiated
>from the Sun impl? If it cannot be differentiated, then what prior planning
>is necessary?
>
IMO the critique does not say this. It states that the final result
should not be differentiatable from Sun's implementation, and that the
achivement of that objective represents a sizable effort in delivery and
maintenance. The critique raises some valid questions concerning that
criteria and its implications on this project.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
Re: [JavaMail] concerns
Posted by Stephen McConnell <mc...@apache.org>.
James Strachan wrote:
> Danny, I took a quick look at the JavaMail licence and its pretty huge
> and I"m not too hot at reading big complex licences full of legal
> speak. Could we redistribute Sun's JavaMail API in binary form as part
> of the Geronimo project? If so could we also put the jar in the Maven
> repository to avoid painful user-intervention to get Geronimo to
> build? (i.e. so that the build process of Geronimo could auto-download
> Sun's JavaMail API?).
At the moment - no.
But there are discussion in process.
Stephen.
>
>
> If we can do the above then I agree creating a clone of the JavaMail
> API with the various required implementation code to conform to the
> API might not be a good idea - we might as well just use Sun's API
> distro. I guess it depends on how we're allowed to reuse Sun's API
> distro.
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
Re: [JavaMail] concerns - it's a legal issue, not a project issue
Posted by Serge Knystautas <se...@lokitech.com>.
Alex Blewitt wrote:
> Indeed, this is the only reason why creating a JavaMail API is
> necessary. At least this way, we have permission to use it; however,
> that's not to say that we can't use the JavaMail (mailapi.jar) binary
> for redistribution purposes.
Unofficially, you can distribute Sun BCL libraries (javamail.jar and
activation.jar) as part of a distribution, but it cannot be downloaded
independently from Apache.
http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
Re: [JavaMail] concerns - it's a legal issue, not a project issue
Posted by Danny Angus <da...@apache.org>.
Alex,
Nicely summarised, I don't take issue with anything you said. :-)
d.
Re: [JavaMail] concerns - it's a legal issue, not a project issue
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 19, 2003, at 12:38 Europe/London, James Strachan wrote:
> Danny, I took a quick look at the JavaMail licence and its pretty huge
> and I"m not too hot at reading big complex licences full of legal
> speak. Could we redistribute Sun's JavaMail API in binary form as part
> of the Geronimo project? If so could we also put the jar in the Maven
> repository to avoid painful user-intervention to get Geronimo to
> build? (i.e. so that the build process of Geronimo could auto-download
> Sun's JavaMail API?).
>
> If we can do the above then I agree creating a clone of the JavaMail
> API with the various required implementation code to conform to the
> API might not be a good idea - we might as well just use Sun's API
> distro. I guess it depends on how we're allowed to reuse Sun's API
> distro.
Indeed, this is the only reason why creating a JavaMail API is
necessary. At least this way, we have permission to use it; however,
that's not to say that we can't use the JavaMail (mailapi.jar) binary
for redistribution purposes.
Ideally, we need a lawyer who can find out if the license is valid.
In particular:
2. License to Distribute Software. Subject to the terms and conditions
of
this Agreement, including, but not limited to Section 3 (Java (TM)
Technology Restrictions) of these Supplemental Terms, Sun grants you a
non-exclusive, non-transferable, limited license to reproduce and
distribute
the Software in binary code form only.
If this is a non-transferrable license, then the developers can
distribute JavaMail, but people who build on top of that product
cannot. So we could not give away Geronimo to someone to build an
embedded web server, because we would then be (in effect) transferring
the JavaMail license to that new developer.
These are the kind of clauses I am worried about in the JavaMail
license.
I think that the conclusions we can draw from this elongated discussion
are:
o An implementation of the various stores/transports is highly
desirable/necessary for Geronimo (and perhaps other projects)
o A reimplementation of the API would serve little benefit other than
to offer the same code under a new license
o No-one really knows (for sure/legally) what the redistribution of
JavaMail allows and does not allow.
I don't believe that anyone disagrees with these points. However, I
personally feel that a re-implementation of JavaMail nicely works
around these issues, whereas Danny feels that the extra maintenance
overhead of replicating the API is more time-consuming than working out
the legal issues of JavaMail, and where appropriate, lobbying Sun to
allow for any legal changes to occur.
I believe the Geronimo PMC/Apache legal should look into the licensing
issues regarding the (re)distribution of the mailapi.jar file from the
JavaMail license
http://java.sun.com/products/javamail/JavaMail-1_2-spec-license.html
http://java.sun.com/products/javamail/
(click on 'Continue' button for more information on the license for
redistribution)
So I believe that further discussion on this thread is unlikely to
bring any new information without expert legal advice.
For more information, see
http://maven.apache.org/sun-licensing-journey.html
which attempts to note Apache's efforts to get Sun to work with the
licensing. Note that it says that at present that Maven's use of
JavaMail (which is even less than Geronimo will use it; the former will
be for interacting with projects for Maven's own use, whereas Geronimo
is explicitly providing JavaMail for other developers use; there is the
concept of transferring a license there)
"... Maven's use is in the spirit of the license though not technically
allowed."
IMHO this isn't a PMC decision, it's a legal one. Once the legalities
have been investigated, the PMC can then make the correct decision as
to which is the preferred way forward.
I am fully aware that should the redistribution of mailapi.jar be
allowed then this will be the preferable choice. But in the absence of
this allowance, there is no choice but to re-implement, and that is (as
I see it) the current position.
Alex.
Re: [JavaMail] concerns
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> However we're not allowed to put it in CVS, and in fact thats pretty much
> the case for all 3rd party jars, because it is difficult (read impossible)
> to ensure that people can't download them without first agreeing to their
> licence conditions.
> I understand that this is because "viewcvs" provides access to the jar
> without compelling people to also download any other files, never mind
> actually read the licence.
>
> Someone, who deserves more credit than my forgetting who it was, produced
> ant tasks for james which allow james' build to include a step which
> automatically retrieves JavaMail, Activation and JUnit jars from their
> respective homes, and compels the user to agree to accept the licence.
>
> This is AFAIK allowable (or acceptable to Sun) under the licence.
Right, you can bundle javamail.jar (and other BCL libraries) as part of
a complete distribution (like the James server), but you couldn't have
it in CVS for exactly that reason.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
RE: [JavaMail] concerns
Posted by Jeremy Boynes <je...@coredevelopers.net>.
> From: Danny Angus [mailto:danny@apache.org]
> James,
>
> We've had this issue in James, it is part of the wider and longer running
> "jars in cvs" debate so familiar to jakarta participants, and the
> conclusion
> of our investigation of JavaMail was that it is acceptable to
> distribute it
> as part of a binary, which we do. If we couldn't I expect James would also
> be looking to create an ASFL-friendly JavaMail alternative.
>
This is the issue. Tomcat (and Geronimo, JBoss and others) solved this by
problem for other APIs by making a clean-room, ASF licensed version of the
API classes available. For things like the Servlet or EJB API this is easy
because there is little concrete code.
Alex is doing the same with JavaMail and this would avoid the issue with
external downloads that you described for James. Unfortunately, this is a
bigger task given the amount of concrete code in the API itself.
>
> As both James and Geronimo use JavaMail as it is intended and for the
> purpose it was written I don't see why our (Geronimo's) use of it
> should be
> restricted by the licence, in exactly the same manner as Tomcat's "normal"
> use of the Servlet API is not restricted by it's licence.
>
Tomcat does not use Sun's servlet binary; they have their own source
version.
--
Jeremy
Re: [JavaMail] concerns
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 19, 2003, at 01:21 pm, Danny Angus wrote:
> James,
>
>> Danny, I took a quick look at the JavaMail licence and its pretty huge
>> and I"m not too hot at reading big complex licences full of legal
>> speak. Could we redistribute Sun's JavaMail API in binary form as part
>> of the Geronimo project? If so could we also put the jar in the Maven
>> repository to avoid painful user-intervention to get Geronimo to
>> build?
>> (i.e. so that the build process of Geronimo could auto-download Sun's
>> JavaMail API?).
>>
>> If we can do the above then I agree creating a clone of the JavaMail
>> API with the various required implementation code to conform to the
>> API
>> might not be a good idea - we might as well just use Sun's API distro.
>> I guess it depends on how we're allowed to reuse Sun's API distro.
>
> We've had this issue in James, it is part of the wider and longer
> running
> "jars in cvs" debate so familiar to jakarta participants, and the
> conclusion
> of our investigation of JavaMail was that it is acceptable to
> distribute it
> as part of a binary, which we do. If we couldn't I expect James would
> also
> be looking to create an ASFL-friendly JavaMail alternative.
>
> However we're not allowed to put it in CVS, and in fact thats pretty
> much
> the case for all 3rd party jars, because it is difficult (read
> impossible)
> to ensure that people can't download them without first agreeing to
> their
> licence conditions.
> I understand that this is because "viewcvs" provides access to the jar
> without compelling people to also download any other files, never mind
> actually read the licence.
>
> Someone, who deserves more credit than my forgetting who it was,
> produced
> ant tasks for james which allow james' build to include a step which
> automatically retrieves JavaMail, Activation and JUnit jars from their
> respective homes, and compels the user to agree to accept the licence.
>
> This is AFAIK allowable (or acceptable to Sun) under the licence.
>
> The result is that the first time you build James you have to accept
> these
> licences, and the jars are downloaded for you.
> Thereafter the build is indistinguishable from the process having the
> jars
> available from cvs, and the built binaries are distributable.
>
> As both James and Geronimo use JavaMail as it is intended and for the
> purpose it was written I don't see why our (Geronimo's) use of it
> should be
> restricted by the licence, in exactly the same manner as Tomcat's
> "normal"
> use of the Servlet API is not restricted by it's licence.
Do we have confirmation from Sun that this is acceptable yet? If so we
can use the Maven plugin for this...
http://maven.apache.org/sun-licensing-journey.html
James
-------
http://radio.weblogs.com/0112098/
RE: [JavaMail] concerns
Posted by Danny Angus <da...@apache.org>.
James,
> Danny, I took a quick look at the JavaMail licence and its pretty huge
> and I"m not too hot at reading big complex licences full of legal
> speak. Could we redistribute Sun's JavaMail API in binary form as part
> of the Geronimo project? If so could we also put the jar in the Maven
> repository to avoid painful user-intervention to get Geronimo to build?
> (i.e. so that the build process of Geronimo could auto-download Sun's
> JavaMail API?).
>
> If we can do the above then I agree creating a clone of the JavaMail
> API with the various required implementation code to conform to the API
> might not be a good idea - we might as well just use Sun's API distro.
> I guess it depends on how we're allowed to reuse Sun's API distro.
We've had this issue in James, it is part of the wider and longer running
"jars in cvs" debate so familiar to jakarta participants, and the conclusion
of our investigation of JavaMail was that it is acceptable to distribute it
as part of a binary, which we do. If we couldn't I expect James would also
be looking to create an ASFL-friendly JavaMail alternative.
However we're not allowed to put it in CVS, and in fact thats pretty much
the case for all 3rd party jars, because it is difficult (read impossible)
to ensure that people can't download them without first agreeing to their
licence conditions.
I understand that this is because "viewcvs" provides access to the jar
without compelling people to also download any other files, never mind
actually read the licence.
Someone, who deserves more credit than my forgetting who it was, produced
ant tasks for james which allow james' build to include a step which
automatically retrieves JavaMail, Activation and JUnit jars from their
respective homes, and compels the user to agree to accept the licence.
This is AFAIK allowable (or acceptable to Sun) under the licence.
The result is that the first time you build James you have to accept these
licences, and the jars are downloaded for you.
Thereafter the build is indistinguishable from the process having the jars
available from cvs, and the built binaries are distributable.
As both James and Geronimo use JavaMail as it is intended and for the
purpose it was written I don't see why our (Geronimo's) use of it should be
restricted by the licence, in exactly the same manner as Tomcat's "normal"
use of the Servlet API is not restricted by it's licence.
d.
Re: [JavaMail] concerns
Posted by James Strachan <ja...@yahoo.co.uk>.
Danny, I took a quick look at the JavaMail licence and its pretty huge
and I"m not too hot at reading big complex licences full of legal
speak. Could we redistribute Sun's JavaMail API in binary form as part
of the Geronimo project? If so could we also put the jar in the Maven
repository to avoid painful user-intervention to get Geronimo to build?
(i.e. so that the build process of Geronimo could auto-download Sun's
JavaMail API?).
If we can do the above then I agree creating a clone of the JavaMail
API with the various required implementation code to conform to the API
might not be a good idea - we might as well just use Sun's API distro.
I guess it depends on how we're allowed to reuse Sun's API distro.
James
-------
http://radio.weblogs.com/0112098/
RE: [JavaMail] concerns
Posted by Danny Angus <da...@apache.org>.
Alex,
> I think that these comments are starting to get me down. I am at part 1
> of a 3-part development cycle:
Jeez I'm sorry about that :-( but the fact remains that I'm going to keep on
about it until people take an interest and we can get a decsion.
As it stands you and I disagree, and no-one else is interested, I'd like to
hear what others think about it.
> 1) Make the API available with complete signatures, so that developers
> can compile against it for their mail code
> 2) Fully implement the API
> 3) Write transports/stores
>
> It's on the published ToDo list, it's updated with where I am, and in
> the release of the initial code-base I said that I was working towards
> goal 3, but doing so via goals 1 and 2 first.
I'm not disputing this, at all.
> Personally, I'm now starting to wish that I hadn't released any code
> until I'd got to 3), which is essentially the one Danny is wanting.
I believe it is the one which is within the scope of the project.
I believe that there are important issues surrounding 2 which need to be
considered before this becomes part of geronimo and which from what I can
see have not been.
> However, in the spirit of release-early, release-often I thought it
> would be a good idea to release part of the code as it made sense to do
> so, in my published work plan and wiki documented to-do list.
Yes fine, but this is not a one man show, it is a community project, I'm not
stopping you from doing this just raising my concerns.
That is how Apache works.
> Further, now that the API is there, someone else (such as Danny :-) can
> start writing the transport/stores if he wants, because the foundations
> are now there for that to happen. However, if not, then it is something
> that I am working towards.
I can already write an implementation of javaMail without requiring an
Apache owned copy.
And my main point it that if this is so, why do we need a copy.
> The majority of the methods in the API are, in fact, complete. There
> are (give or take) about 800 methods, of which there are only 100 or so
> left; just under 12% to go to reach 2).
Right OK, fine, I'm not trying to stop you, just questioning the value of
this.
Do these 100 or so methods all represent the same amount of work as the 800
already written?
> I'm also curious as to why you keep using javaMail when the trademark
> is in fact JavaMail?
I know that, but I keep mistyping it.
d.
Re: [JavaMail] concerns
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 19, 2003, at 11:05 Europe/London, Danny Angus wrote:
> I think perhaps you need to look at what is being done.
>
> Alex is creating a copy of the API, he's *NOT* implementing it.
> If he implements the API thats fine, thats what we're here for.
I think that these comments are starting to get me down. I am at part 1
of a 3-part development cycle:
1) Make the API available with complete signatures, so that developers
can compile against it for their mail code
2) Fully implement the API
3) Write transports/stores
It's on the published ToDo list, it's updated with where I am, and in
the release of the initial code-base I said that I was working towards
goal 3, but doing so via goals 1 and 2 first.
Personally, I'm now starting to wish that I hadn't released any code
until I'd got to 3), which is essentially the one Danny is wanting.
However, in the spirit of release-early, release-often I thought it
would be a good idea to release part of the code as it made sense to do
so, in my published work plan and wiki documented to-do list.
Further, now that the API is there, someone else (such as Danny :-) can
start writing the transport/stores if he wants, because the foundations
are now there for that to happen. However, if not, then it is something
that I am working towards.
> Bearing in mind that this is not a case of simply typing in interface
> method
> signatures from the javadocs, why would creating and maintaining a
> copy of
> the javaMail API be a worthwhile goal of this project, should we not be
> focused on creating a world class implementation of it?
The majority of the methods in the API are, in fact, complete. There
are (give or take) about 800 methods, of which there are only 100 or so
left; just under 12% to go to reach 2).
I'm also curious as to why you keep using javaMail when the trademark
is in fact JavaMail?
http://java.sun.com/products/javamail/
Alex.
RE: [JavaMail] concerns
Posted by Danny Angus <da...@apache.org>.
Richard,
> The critique of Alex's contribution is certainly well intended,
> but its also
> kind of odd. Why should the critic
I'm "the critic" my name is Danny Angus, I'm a comitter and PMC member of
the Apache James mailserver project.
I have a ton of experience with javaMail, much of it bad, yet I firmly
believe that it may be a mistake for Geronimo to try to replace it when we
should really be trying to implement it.
> complain that there is not enough
> planning and then go on to say that Alex's impl cannot be differentiated
> from the Sun impl? If it cannot be differentiated, then what
> prior planning
> is necessary?
A decision as to whether or not the geronimo community require this, want
it, and are prepeared to maintain it ad-infinitum.
We are *NOT* discussing an implementation of the API. I am *HAPPY* to see an
implementation, and have offered to be part of that effort.
What I want to know is whether or not Geronimo really wants to be burdened
with the creation and maintenance od code which *replaces* the published
API?
Just because Alex is prepared to do the work is surely not alone reason
enough to incorporate it and the risk it brings, the risk that the wider
project will not be able to progress to release, or some such, for want of
work on the Apache version of the javaMail API. Work which would not be
necessary if we simply used Suns' public API.
Please everyone note that I'm not talking about implementations, I'm talking
about the API itself.
>
> I've spoken to some people who have attempted to use JavaMail in a high
> volume production environment and abandoned it because it was too slow ...
> IMO, if Alex can improve on that, than more power to him.
What was too slow? the API or the Refrence implementation?
Again, theres no clear distinction made by you, yet you would quite clearly
distinguish between Tomcat (the servlet/jsp RI) and the API it implements.
> I also believe that it behooves Geronimo to have its own implementation
> because it gives us the option of going beyond the spec to impl
> value-add-ons.
As I said before, an implementation allows this, an alternative version of
the API does not, not if it is correctly done.
>
> Anyway, the critique appears to have been offered in sincerity, but it
> doesn't make much sense to me.
I think perhaps you need to look at what is being done.
Alex is creating a copy of the API, he's *NOT* implementing it.
If he implements the API thats fine, thats what we're here for.
Bearing in mind that this is not a case of simply typing in interface method
signatures from the javadocs, why would creating and maintaining a copy of
the javaMail API be a worthwhile goal of this project, should we not be
focused on creating a world class implementation of it?
d.
RE: [JavaMail] concerns
Posted by Danny Angus <da...@apache.org>.
Alex, Richard, everybody..
> I believe that Danny's main point was that he doesn't see recreating
> the API as an important part,
Actually I see it as being a risk, and an unecessary one, there is a lot of
work involved to conform to RFC's.
Sun has done a lot of this work and it form part of the API.
Why would geronimo releases risk being blocked by this when it doesn't
really need to be done at all?
_Why_would replicating javaMail be within the scope of Geronimo?
> as opposed to creating the mail providers.
> However, this is on my to-do list (see the ApacheJ2EE/TO-DO
> in which I list the stages of the JavaMail development) as the final
> stage of JavaMail implementation.
IMO this is the *ONLY* part which turly represents implementation of the
API, as compared to creating an alternative version of the API.
> I suspect that Danny sees this as
> more important (and especially if Sun provide an implementation of
> JavaMail, whether binary or source) for use in Apache (though at this
> time, the conversation with Sun is still ongoing and appears to only
> cover binary use).
Clearly this would not be a case of Sun providing the API, merely the
refrence implementation.
I stress I am fully in favour of seeing an implementation created.
I am opposed to the work involved in the creation and maintenance of an
alternative version of the API unless the whole community reaches some form
of understanding of the issues and some agreement. Is this not the Apache
way?
> I also believe that Danny has some unsatisfied concerns regarding the
> difficulty of implementing the JavaMail APIs. He is concerned that a
> number of RFCs exist which control mail, and that he is concerned that
> not all of these will be implemented to the standards that the JavaMail
> Sun RI gives.
Wrong, I am *NOT* talking about the RI.
I am addressing the API, which itself provides conformance with a number of
RFC's.
My concern is that as this work has been done and forms part of the API, it
is *NOT* part of the RI it *IS* part of the API, the geronimo project is
unnecessarily opening itself up to a whole lot of other specifications which
must be complied with.
My basic questions are; Will someone tell me why we should consider doing
this, what is the benefit?
Is it simply the ASFL?
Is this therfore worthwhile?
> Actually, there isn't so much to be concerned about, since mostly the
> RI classes force specific types of RFC down your throat anyway, such as
> the MimeBodyPart class.
MimeBodyPart is an API class.
Any implementation can leave RFC confomrance of this class to be the concern
of the API.
If, however, we insist upon creating an alternative version of the API that
concern becomes ours.
> Additionally, some of the other classes use Sun
> java.net classes to perform RFC validation of certain aspects. And
> lastly, looking at the documentation for classes like
> 'InternetHeaders', it actually places the burden on the caller of
> providing the information in the right format (i.e. US-ASCII) rather
> than the implementation itself.
Theres more to this than that, but I don't think this is the right place to
be discussing the detail and interpretation of mail RFC's.
> Also, there isn't /that/ much left unimplemented in the API yet.
> There's only about 100 methods to go (which equates to one method per
> class), and two of the packages in the API have been implemented fully
> already.
>
> He's right that the implementation of the providers/store hasn't been
> started yet, but since I'm working towards that he can rest easy :-)
I'm not conerned about that, there's plenty of time, I am much more
concerned that your current work is creating a white elephant.
d.
Re: [JavaMail] concerns
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 19, 2003, at 08:38 Europe/London, Danny Angus wrote:
> Richard,
>
>> I also believe that it behooves Geronimo to have its own
>> implementation
>> because it gives us the option of going beyond the spec to impl
>> value-add-ons.
>
> You seem to be falling into the same trap, it is possible to create an
> IMPLEMENTATION of the API, to replace Sun's RI, without re-creating
> the API
> itself.
>
> We can add value without re-creating the API, and in fact if we pursue
> the
> goal of recreating the API we can't add value through that process.
Some things that are worth bringing up here:
Classes in the javax.mail package represent the 'API' of JavaMail;
implementations live in other packages (e.g. org.apache.geronimo.mail)
separate from the API (aka mail providers).
I believe that Danny's main point was that he doesn't see recreating
the API as an important part, as opposed to creating the mail
providers. However, this is on my to-do list (see the ApacheJ2EE/TO-DO
in which I list the stages of the JavaMail development) as the final
stage of JavaMail implementation. I suspect that Danny sees this as
more important (and especially if Sun provide an implementation of
JavaMail, whether binary or source) for use in Apache (though at this
time, the conversation with Sun is still ongoing and appears to only
cover binary use).
I also believe that Danny has some unsatisfied concerns regarding the
difficulty of implementing the JavaMail APIs. He is concerned that a
number of RFCs exist which control mail, and that he is concerned that
not all of these will be implemented to the standards that the JavaMail
Sun RI gives.
Actually, there isn't so much to be concerned about, since mostly the
RI classes force specific types of RFC down your throat anyway, such as
the MimeBodyPart class. Additionally, some of the other classes use Sun
java.net classes to perform RFC validation of certain aspects. And
lastly, looking at the documentation for classes like
'InternetHeaders', it actually places the burden on the caller of
providing the information in the right format (i.e. US-ASCII) rather
than the implementation itself.
Also, there isn't /that/ much left unimplemented in the API yet.
There's only about 100 methods to go (which equates to one method per
class), and two of the packages in the API have been implemented fully
already.
He's right that the implementation of the providers/store hasn't been
started yet, but since I'm working towards that he can rest easy :-)
Alex.
RE: [JavaMail] concerns
Posted by Danny Angus <da...@apache.org>.
Richard,
> I also believe that it behooves Geronimo to have its own implementation
> because it gives us the option of going beyond the spec to impl
> value-add-ons.
You seem to be falling into the same trap, it is possible to create an
IMPLEMENTATION of the API, to replace Sun's RI, without re-creating the API
itself.
We can add value without re-creating the API, and in fact if we pursue the
goal of recreating the API we can't add value through that process.
d.
Re: [JavaMail] concerns
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
The critique of Alex's contribution is certainly well intended, but its also
kind of odd. Why should the critic complain that there is not enough
planning and then go on to say that Alex's impl cannot be differentiated
from the Sun impl? If it cannot be differentiated, then what prior planning
is necessary?
I've spoken to some people who have attempted to use JavaMail in a high
volume production environment and abandoned it because it was too slow ...
IMO, if Alex can improve on that, than more power to him.
I also believe that it behooves Geronimo to have its own implementation
because it gives us the option of going beyond the spec to impl
value-add-ons.
Anyway, the critique appears to have been offered in sincerity, but it
doesn't make much sense to me.
Richard
On 8/18/03 4:13 PM, in article
Pine.LNX.4.44.0308182345280.24104-100000@server.int.bandlem.com, "Alex
Blewitt" <Al...@ioshq.com> wrote:
> On Mon, 18 Aug 2003, Danny Angus wrote:
>
>> As an observer, and having admited my interest in JavaMail in geronimo I'm
>> slightly concerned that there seems to be very little oversight or direction
>> involved with the JavaMail effort.
>
>> From where, though? I had volunteered to do it, and worked away at
> providing the implementation. From a community PoV, the files haven't been
> in there very long but no doubt others will pick it up where it needs to
> be handled.
>
>> Alex is obviously working hard, but I'm concerned that what he's doing may
>> not be, through no fault of his, the best decision for the project.
>> I have a couple of reasons for saying this, none of which reflect badly on
>> Alex, and I want to emphasise that this is not intended to be criticism of
>> him in any way.
>
> Not taken as such, don't worry :-) I have a fairly thick skin (along with
> a fairly thick body and a fairly thick skull)
>
>> 1/ JavaMail differs from most of the other j2ee API's in that it is 80%+
>> implementation and >20% interfaces, so an ASFL clone is far from trivial,
>> and represnets a serious investment by the project, one which will have to
>> be updated and maintained.
>
> It's true that there's a lot more to the API than just the interfaces
> (unlike EJBs, for example, which is just pure interfaces). This is why it
> took me a week to generate the 100 odd classes in the JavaMail API in the
> first place.
>
> However, one of the reasons it took me a long time to do in the
> first place is that I didn't /just/ do the APIs -- I also implemented
> (where possible) the methods that go with it. Gut feeling is that I've got
> between 60% and 80% of the base implementation of the JavaMail API done.
> (Key things missing are the MimeMessage and Folder methods, though some
> are done).
>
> As an example, the javax.mail.search and javax.mail.event packages are
> 100% implemented (along with tests for the javax.mail.event package; I am
> developing a simple test-message and test-folder to write tests for the
> search package).
>
> For maintenance purposes, I am developing a set of JUnit tests which will
> hopefully avoid the need (or difficulty) of too much maintenance.
>
>> 2/ Without an active and enthusiastic community (c.f. a lone developer) to
>> support it it will never be a quality replacement for sun's packages, the
>> quantity of conformance with Sun's specs and with RFC's required to do the
>> job properly is significant and (IMO) large.
>
> To a greater extent (and certainly initially) this is true. But once the
> core bits are done, it will be easier to maintain. Some of the RFCs are
> implemented as Sun classes in 1.4 anyway (such as the URI class, which was
> helpfully pointed out to me :-) although some are still not yet
> implemented.
>
>> Given the above I haven't seen anything which indicates that re-writing
>> javaMail (compared to implementing those areas which are left as interfaces
>> with the specific intention of being implemented by 3rd parties) is a goal
>> of this project, or more importantly why it is considered to be a worthwhile
>> direction.
>
>> From a personal PoV, I've used JavaMail before and have had experience
> with using it. I thought it might be fun to work on as an initial task
> working with Geronimo. And it's better than writing up my thesis :-)
>
>> The fact is that this work will require considerable effort and, if it is
>> done correctly, only ever result in a product virtually indistinguishable
>> from Sun's original save for the licence.
>
> Yes, this is indeed the case. In fact, the only parts where we could
> differ would be in the implementation of the actual transport/stores
> anyway, since the API is firmly fixed in how its supposed to behave.
>
>> I'd like to know if this really is a goal of Geronimo or whether the
>> situation of javaMail could be given more attention before Alex expends too
>> much more effort on it.
>
> The J2EE 1.4 spec mandates a JavaMail implementation of some kind; whether
> this be based on the Sun RI or another open-source one is still open.
> (Additionally, queries have been given to the nature of (L)GPL code, which
> may rule out (L)GPL implementations of JavaMail)
>
> The goals I had when starting this were;
>
> o To provide JavaMail integration with Geronimo without dependency on
> Sun's JavaMail (Mainly for licensing reasons)
> o To provide an Apache implementation of the mail store/transport
> protocols
> o Subsequently to make the same version available as part of the
> jakarta-commons packages, for possible integration into other Apache
> products like JAMES
>
> I have heard that the ASF are in talks with Sun regarding licensing their
> JavaMail implementation through an open-source license. Should this come
> about, then clearly the work I will have done implementing the APIs will
> become obsolete and the correct decision will be to replace them with
> Sun's implementation. As yet, however, I don't know what stage this is at,
> so feel that it is worth gambling to make it available now and for the
> initial, if not subsequent, releases of Geronimo.
>
> It has also given me opportunity to work with ASF; something which I've
> not done before and it's been pretty enjoyable :-)
>
> And, as I've mentioned above, it's a lot more fun than writing up the
> thesis :-)
>
> Alex.
>
> /***************************************************************\
> |* Alex Blewitt * Hug, and the world hugs with you *|
> |* Alex.Blewitt@ioshq.com *
> *|
> |* Mobile: +44 7966 158 647 * Spread a little happiness *|
> \***************************************************************/
>
>
>
>
Re: [JavaMail] concerns
Posted by Serge Knystautas <se...@lokitech.com>.
Alex Blewitt wrote:
>> We've discussed creating a subproject in James to maintain
>> ASF-licensed JavaMail implementations, which historically has only
>> really meant stores and session (providers). If it can include the
>> core implementation as well, so be it.
>
>
> Would it not be better to try and evolve it into a commons- package,
> though? It looks like it will be desirable from both James and Geronimo,
> and IIRC Maven is also something that could stand to benefit from it ...
I agree many ASF projects could benefit from an ASF-licensed JavaMail
(any app in ASF that sends emails, so almost all of them). I would
favor either James or Geronimo hosting it. Geronimo because it is a
J2EE implementation and JavaMail is part of that, and James because
we've suffered through JavaMail more than anyone, and hopefully will
have related libraries (mbox stores, new transports, whatever).
> These are longer-term goals, though; my initial focus will be getting it
> set up in Geronimo, and then bounce ideas of where it should live when
> it's ready :-)
Agreed.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
Re: [JavaMail] concerns
Posted by Alex Blewitt <Al...@ioshq.com>.
On Tuesday, Aug 19, 2003, at 13:08 Europe/London, Serge Knystautas
wrote:
> Danny Angus wrote:
>>>> From where, though? I had volunteered to do it, and worked away at
>>> providing the implementation. From a community PoV, the files
>>> haven't been
>>> in there very long but no doubt others will pick it up where it
>>> needs to
>>> be handled.
>> This is not a given. Geronimo is a new project, there is great scope
>> for new
>> code ending up being orphaned if a community of interested people
>> doesn't
>> gel around it, there is no guarantee that this will happen.
>
> I agree there is that risk.
>
> That said, I believe the James community would be fertile ground to
> take over responsibility of the ASF-licensed implementation. I'm
> planning to push to adopt Alex's implementation into James once it's
> appropriate. In fact, I was wondering how the activation.jar
> implementation is coming. :)
>
> We've discussed creating a subproject in James to maintain
> ASF-licensed JavaMail implementations, which historically has only
> really meant stores and session (providers). If it can include the
> core implementation as well, so be it.
Would it not be better to try and evolve it into a commons- package,
though? It looks like it will be desirable from both James and
Geronimo, and IIRC Maven is also something that could stand to benefit
from it ...
These are longer-term goals, though; my initial focus will be getting
it set up in Geronimo, and then bounce ideas of where it should live
when it's ready :-)
Alex.
Re: [JavaMail] concerns
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
>>>>From where, though? I had volunteered to do it, and worked away at
>>providing the implementation. From a community PoV, the files haven't been
>>in there very long but no doubt others will pick it up where it needs to
>>be handled.
>
> This is not a given. Geronimo is a new project, there is great scope for new
> code ending up being orphaned if a community of interested people doesn't
> gel around it, there is no guarantee that this will happen.
I agree there is that risk.
That said, I believe the James community would be fertile ground to take
over responsibility of the ASF-licensed implementation. I'm planning to
push to adopt Alex's implementation into James once it's appropriate.
In fact, I was wondering how the activation.jar implementation is coming. :)
We've discussed creating a subproject in James to maintain ASF-licensed
JavaMail implementations, which historically has only really meant
stores and session (providers). If it can include the core
implementation as well, so be it.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. sergek@lokitech.com
RE: [JavaMail] concerns
Posted by Danny Angus <da...@apache.org>.
Alex wrote:
> >From where, though? I had volunteered to do it, and worked away at
> providing the implementation. From a community PoV, the files haven't been
> in there very long but no doubt others will pick it up where it needs to
> be handled.
This is not a given. Geronimo is a new project, there is great scope for new
code ending up being orphaned if a community of interested people doesn't
gel around it, there is no guarantee that this will happen.
I want to emphasise that this is not intended to be
> criticism of
> > him in any way.
>
> Not taken as such, don't worry :-) I have a fairly thick skin (along with
> a fairly thick body and a fairly thick skull)
Nice one. :-)
> However, one of the reasons it took me a long time to do in the
> first place is that I didn't /just/ do the APIs -- I also implemented
> (where possible) the methods that go with it.
I think its important to clarify something here, if the method is a real
method in Sun's API, not an interface method signature or an abstract
method, then you *must* implement it or you haven't cloned the API.
I'm sure you know this already, my "issue" is that there is a lot of this
needed, and just making a first pass isn't (no disrespect) going to
create anything that is worth having instead of Sun's API.
>Gut feeling is that I've got
> between 60% and 80% of the base implementation of the JavaMail API done.
> (Key things missing are the MimeMessage and Folder methods, though some
> are done).
I really suspect that once you start into MimeMessage et-al you'll discover
why Sun make this pert of the API and not simply an interface.
I believe it is because the job (of conforming to the Mime RFC's) is complex
and nasty and easily tested.
Now I have some reservations about Sun's version from the API, but I believe
that the way to solve that ought to be by Sun refactoring the implementation
out of the API and into the RI.
As it stands Sun's Mime parsers and related classes form part of the API,
they are not interchangeable components like the Transport and Store
mechanisms are.
> For maintenance purposes, I am developing a set of JUnit tests which will
> hopefully avoid the need (or difficulty) of too much maintenance.
What I meant was that as the specifications (RFC's and the API's) evolve
with time it will always be necessary for someone to be aware of these
changes and "copy" them into geronimo's JavaMail clone.
> To a greater extent (and certainly initially) this is true. But once the
> core bits are done, it will be easier to maintain. Some of the RFCs are
> implemented as Sun classes in 1.4 anyway
Yep, I know, and if you look at it that way many more RFC's are implemented
in the existing JavaMail API, not Sun's refrence implementation of the API,
but the API itself.
> >From a personal PoV, I've used JavaMail before and have had experience
> with using it. I thought it might be fun to work on as an initial task
> working with Geronimo. And it's better than writing up my thesis :-)
Which is a valid reson for you to do this, and I respect that.
What I am concerned with is that I haven't seen a valid reason to place this
burden on Geronimo, not one that also takes account of the particular
concerns I have.
If I was sure that a majority of the comiters were aware of the issues, and
hand taken a properly mandated decison to continue with this, then fine.
However I have a feeling that thay aren't aware and haven't actually
mandated this.
> Yes, this is indeed the case. In fact, the only parts where we could
> differ would be in the implementation of the actual transport/stores
> anyway, since the API is firmly fixed in how its supposed to behave.
Yes, this is again a point which I feel is being confused.
The Transports and Stores and other classes distributed in the "com.sun"
packages are Sun's "refrence implementation" of the API, these are fully
within the scope of this project and offer an opportunity to add value and
functionality within the specification of the API.
The rest of the classes, those in the "javax.mail" packages ARE The API,
they are not an implementation of the API they are it and it is them,
period.
> The J2EE 1.4 spec mandates a JavaMail implementation of some kind;
> whether this be based on the Sun RI or another open-source one is still
open.
Ok, I understand. But someone answer this..
An implementation of the API would depend upon the API code, and would
replcae the "com.sun" refrence implementation.
Anything which was capable of being used wholly in place of the API would be
an alternative API, not an implementation.
Are we not therfore creating an alternative when we should actually be
creating an implementation?
> o To provide JavaMail integration with Geronimo without dependency on
> Sun's JavaMail (Mainly for licensing reasons)
I understand this, but don't believe that this alone is worth the effort
needed to create and maintain this code.
> o To provide an Apache implementation of the mail store/transport
> protocols
This *IS* an implementation and I agree this *SHOULD* be the focus of the
javaMail effort.
> o Subsequently to make the same version available as part of the
> jakarta-commons packages, for possible integration into other Apache
> products like JAMES
This is only likely to happen if there is some demand for it, something
which I am not convinced of.
After all Sun's API is released under a licence open *enough* for James to
use it and not bother maintaining a duplicate of this functionality.
Think re-use.
>
> I have heard that the ASF are in talks with Sun regarding licensing their
> JavaMail implementation through an open-source license.
Whatever. Thats about the implementation, the "com.sun" things, not the API,
the "javax.mail" things.
> Should this come
> about, then clearly the work I will have done implementing the APIs will
> become obsolete and the correct decision will be to replace them with
> Sun's implementation.
Actually if that happens it will be _Apache's_ implementation, like Tomcat
is Apache's implementation of Servlet & JSP.
Apache doesn't maintain the servlet and jsp API's, nor AFAIK an ASFL clone
of these API's.
Yes, but what I have a probelm with is not your implementation, but the need
for creating a whole replacement API, and where the resources will come from
to maintain it once your enthusiasm wanes.
> As yet, however, I don't know what stage this is at,
> so feel that it is worth gambling to make it available now and for the
> initial, if not subsequent, releases of Geronimo.
Make the *implementation* availabe, yes thats a Good Thing, whatever
happens.
But to replicate the API for the sake of the licence alone is another matter
altogether.
> It has also given me opportunity to work with ASF; something which I've
> not done before and it's been pretty enjoyable :-)
Good, I'm glad about that, it's a good place to be, don't let my politiking
put you off. :-)
d.
Re: [JavaMail] concerns
Posted by Alex Blewitt <Al...@ioshq.com>.
On Mon, 18 Aug 2003, Danny Angus wrote:
> As an observer, and having admited my interest in JavaMail in geronimo I'm
> slightly concerned that there seems to be very little oversight or direction
> involved with the JavaMail effort.
>>From where, though? I had volunteered to do it, and worked away at
providing the implementation. From a community PoV, the files haven't been
in there very long but no doubt others will pick it up where it needs to
be handled.
> Alex is obviously working hard, but I'm concerned that what he's doing may
> not be, through no fault of his, the best decision for the project.
> I have a couple of reasons for saying this, none of which reflect badly on
> Alex, and I want to emphasise that this is not intended to be criticism of
> him in any way.
Not taken as such, don't worry :-) I have a fairly thick skin (along with
a fairly thick body and a fairly thick skull)
> 1/ JavaMail differs from most of the other j2ee API's in that it is 80%+
> implementation and >20% interfaces, so an ASFL clone is far from trivial,
> and represnets a serious investment by the project, one which will have to
> be updated and maintained.
It's true that there's a lot more to the API than just the interfaces
(unlike EJBs, for example, which is just pure interfaces). This is why it
took me a week to generate the 100 odd classes in the JavaMail API in the
first place.
However, one of the reasons it took me a long time to do in the
first place is that I didn't /just/ do the APIs -- I also implemented
(where possible) the methods that go with it. Gut feeling is that I've got
between 60% and 80% of the base implementation of the JavaMail API done.
(Key things missing are the MimeMessage and Folder methods, though some
are done).
As an example, the javax.mail.search and javax.mail.event packages are
100% implemented (along with tests for the javax.mail.event package; I am
developing a simple test-message and test-folder to write tests for the
search package).
For maintenance purposes, I am developing a set of JUnit tests which will
hopefully avoid the need (or difficulty) of too much maintenance.
> 2/ Without an active and enthusiastic community (c.f. a lone developer) to
> support it it will never be a quality replacement for sun's packages, the
> quantity of conformance with Sun's specs and with RFC's required to do the
> job properly is significant and (IMO) large.
To a greater extent (and certainly initially) this is true. But once the
core bits are done, it will be easier to maintain. Some of the RFCs are
implemented as Sun classes in 1.4 anyway (such as the URI class, which was
helpfully pointed out to me :-) although some are still not yet
implemented.
> Given the above I haven't seen anything which indicates that re-writing
> javaMail (compared to implementing those areas which are left as interfaces
> with the specific intention of being implemented by 3rd parties) is a goal
> of this project, or more importantly why it is considered to be a worthwhile
> direction.
>>From a personal PoV, I've used JavaMail before and have had experience
with using it. I thought it might be fun to work on as an initial task
working with Geronimo. And it's better than writing up my thesis :-)
> The fact is that this work will require considerable effort and, if it is
> done correctly, only ever result in a product virtually indistinguishable
> from Sun's original save for the licence.
Yes, this is indeed the case. In fact, the only parts where we could
differ would be in the implementation of the actual transport/stores
anyway, since the API is firmly fixed in how its supposed to behave.
> I'd like to know if this really is a goal of Geronimo or whether the
> situation of javaMail could be given more attention before Alex expends too
> much more effort on it.
The J2EE 1.4 spec mandates a JavaMail implementation of some kind; whether
this be based on the Sun RI or another open-source one is still open.
(Additionally, queries have been given to the nature of (L)GPL code, which
may rule out (L)GPL implementations of JavaMail)
The goals I had when starting this were;
o To provide JavaMail integration with Geronimo without dependency on
Sun's JavaMail (Mainly for licensing reasons)
o To provide an Apache implementation of the mail store/transport
protocols
o Subsequently to make the same version available as part of the
jakarta-commons packages, for possible integration into other Apache
products like JAMES
I have heard that the ASF are in talks with Sun regarding licensing their
JavaMail implementation through an open-source license. Should this come
about, then clearly the work I will have done implementing the APIs will
become obsolete and the correct decision will be to replace them with
Sun's implementation. As yet, however, I don't know what stage this is at,
so feel that it is worth gambling to make it available now and for the
initial, if not subsequent, releases of Geronimo.
It has also given me opportunity to work with ASF; something which I've
not done before and it's been pretty enjoyable :-)
And, as I've mentioned above, it's a lot more fun than writing up the
thesis :-)
Alex.
/***************************************************************\
|* Alex Blewitt * Hug, and the world hugs with you *|
|* Alex.Blewitt@ioshq.com * *|
|* Mobile: +44 7966 158 647 * Spread a little happiness *|
\***************************************************************/
RE: [PATCH] [JavaMail] Created resources directory and copied META-INF contents
Posted by Danny Angus <da...@apache.org>.
Guys,
As an observer, and having admited my interest in JavaMail in geronimo I'm
slightly concerned that there seems to be very little oversight or direction
involved with the JavaMail effort.
Alex is obviously working hard, but I'm concerned that what he's doing may
not be, through no fault of his, the best decision for the project.
I have a couple of reasons for saying this, none of which reflect badly on
Alex, and I want to emphasise that this is not intended to be criticism of
him in any way.
1/ JavaMail differs from most of the other j2ee API's in that it is 80%+
implementation and >20% interfaces, so an ASFL clone is far from trivial,
and represnets a serious investment by the project, one which will have to
be updated and maintained.
2/ Without an active and enthusiastic community (c.f. a lone developer) to
support it it will never be a quality replacement for sun's packages, the
quantity of conformance with Sun's specs and with RFC's required to do the
job properly is significant and (IMO) large.
Given the above I haven't seen anything which indicates that re-writing
javaMail (compared to implementing those areas which are left as interfaces
with the specific intention of being implemented by 3rd parties) is a goal
of this project, or more importantly why it is considered to be a worthwhile
direction.
The fact is that this work will require considerable effort and, if it is
done correctly, only ever result in a product virtually indistinguishable
from Sun's original save for the licence.
I'd like to know if this really is a goal of Geronimo or whether the
situation of javaMail could be given more attention before Alex expends too
much more effort on it.
d.
> -----Original Message-----
> From: Jeremy Boynes [mailto:jeremy@coredevelopers.net]
> Sent: 18 August 2003 18:35
> To:
> Subject: RE: [PATCH] [JavaMail] Created resources directory and copied
> META-INF contents
>
>
> Applied - but I have questions on the reference to org.apache.commons.mail
>
> Is this correct? Should this instead be in that implementation?
>
> --
> Jeremy
>
> > -----Original Message-----
> > From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
> > Sent: Sunday, August 17, 2003 2:01 AM
> > To: geronimo-dev@incubator.apache.org
> > Subject: [PATCH] [JavaMail] Created resources directory and copied
> > META-INF contents
> >
> >
> > Here's the JavaMail resources directory (Jar contains
> > specs/javamail/src/resources/META-INF/javamail.default.*)
> >
> > Should also be removed from the specs/javamail/src/java/META-INF
> > directory, but I can't figure out how to generate that as a patch,
> > sorry. :-/
> >
> >
RE: [PATCH] [JavaMail] Created resources directory and copied META-INF contents
Posted by Jeremy Boynes <je...@coredevelopers.net>.
Applied - but I have questions on the reference to org.apache.commons.mail
Is this correct? Should this instead be in that implementation?
--
Jeremy
> -----Original Message-----
> From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
> Sent: Sunday, August 17, 2003 2:01 AM
> To: geronimo-dev@incubator.apache.org
> Subject: [PATCH] [JavaMail] Created resources directory and copied
> META-INF contents
>
>
> Here's the JavaMail resources directory (Jar contains
> specs/javamail/src/resources/META-INF/javamail.default.*)
>
> Should also be removed from the specs/javamail/src/java/META-INF
> directory, but I can't figure out how to generate that as a patch,
> sorry. :-/
>
>