On Tuesday, Aug 19, 2003, at 12:19 Europe/London, Danny Angus wrote:
Alex,
I'd rather keep this discussion on the list, and with your permission I'll
FW this reply..
Don't have a problem if you do, but I feel that the majority of the list are unlikely to want to wade down through this in any more detail. Some of the PMC might, though.
Possibly, but the JavaMail specs don't actually change that much. And any such changes that do fall behind would be picked up by the TCK for the next flavour, wouldn't they? For example, there was one new method (setSender()) added in the most recent version of the JavaMail API.
Yeah, and if we used Sun's API it would be no problem, if we don't then *someone* does indeed still have to update our version of the API.
Agreed.
Hopefully I said that I was going to do this in 3 stages, and I'm only at the end of stage 1 at the moment. But it is planned to continue along that path, and therefore the work I have done so far is to work towards that end goal.
I understand, but I don't want to see you wasting your time.
That's OK, it's a personal challenge more than anything else. And if Apache don't want the source, I can still make it available under an open-source license myself that isn't the LGPL (issues of which still arise in the Java land...)
You say that 'you believe this is complex and nasty' -- I don't think
it's as nasty and complex as you do. To be honest, the actual answer is
likely to lie somewhere between the two viewpoints.
Fair enough. I've actually written Mime parsers before, but not in Java.
However the javaMail parser effort is compounded by the fact that you *also*
have to conform to the API spec which means that you have to somehow do this
using all the same classes and methods that Sun have used.
True. I didn't say it was going to be easy, either :-) TBH it would be useful if you could provide input on MIME parsing, if you've got any source available on that.
I climbed Ben Nevis once (highest mountain in the UK). It was covered with fog/cloud (we started early) and the mountain disappeared into the cloud. We were pretty sure that the mountain ended at the cloud level, so we kept climbing, and every now and again it would plateau off. Just as we thought we were getting to the top, we went round a bend and there would be another stretch of mountain, going up into the clouds.
I would never have climbed Ben Nevis if I could have seen all of it when I started. However, I could climb it thinking that the end was round the corner, and indeed, when I got there I found I had more to do. But in this way, I did get to the top of the mountain. [Getting down was another story ...]
Yes, I agree, but they are most unlikely to do that.
Not necesarily, Apache has some clout when it comes to making our voice heard with Sun.
Good. Let's see what happens, and as such time as the legal situation is clarified and we can use their binary code, we can swap out what I've done with theirs.
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.
Yes, they are. And they will require some work to implement correctly, but (hopefully) not insurmountable.
Not implement, copy.
No, not copy. A copy is an exact replica. What we want is something that does the same. And I used the term 'implement' to mean 'does the same'.
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.
Yes, this is indeed the case. However, if Geronimo (or whatever) passes
the TCK then it will by inclusion pass the JavaMail stuff. Any failures
can be easily noted and brought up.
But why expend this effort when we could use the API as it is intended to be
used??
Because legally, we don't know we can.
Also IIRC the TCK's test the conformance of implementations, not of the API's themselves.
Well, they have to test the conformance of an implementation, just use the implementation that we give (that is based on the APIs). The purpose of the TCK is to make sure that everything it tests behaves in a way consistent with the JavaDoc/specs. If the TCK doesn't test feature X (like the comparison of two URLName's protocols/schemas) then that may be ambiguous and there could be different reference implementations.
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.
Actually, I started doing this with the goal of then moving it later to
a commons- package, but developing it in the incubation of Geronimo
because (a) I wanted to get involved with more than just the JavaMail,
and (b) because I'm not an ASF committer and thus don't have many
priviledges at the moment :-)
But basically it is a personal decision, and not something which has been
agreed upon by either the geronimo comitters or the incubator PMC.
In the initial phases of this project, there were calls for volunteers for different topics. I suggested JavaMail, proposed some discussions about whether to re-implement the API or reuse it, and asked for legal advice. No further legal analysis has been reported on here (yet), and in order to do the implementation of JavaMail you need to have the API available.
So it is a PMC decision that hasn't been answered on the legality of reusing the JavaMail mailapi-jar file yet, and in the absence of that I am taking the only course towards making JavaMail available.
As for whether it should be part of Geronimo; the J2EE server must have
Transport/Stores provided, and I intend to do those later.
Yes, thats the implementation, I'm only concerned with the API.
Acknowledged.
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.
I'm not sure where 'mandated' comes in to it.
This is an ASF project, not sourceforge, it has rules and processes which
must be complied with, one of which is that the project must comply with its
charter, another of which is that there should be oversight by the PMC and
not a free-for-all.
Fair enough. I've not worked on sourceforge either, and this is my first run into ASF as well.
I attempted to make my concerns loudly at the start of this implementation run and it hasn't been resolved yet.
I don't believe that copying the javaMail API is mentioned, nor that it was
necessarily intended by the proposal, it hasn't been explicitly sanctioned
by the comitters or the PMC.
I think that, given the issues I've raised, there should be a debate about
the issues and a decision made.
In order to do this, we need to know from a firm footing what the legal position currently is, and from that decide what the right way forward is.
If contributors to the James project wanted to copy javaMail there would
have to be a proposal, a debate and a vote, and even then we might have to
justify to the Board why it was acceptable under the charter.
James isn't in the incubator though. Geronimo is. My understanding of the difference is that ideas can be tried, and then removed subsequently (or even replaced with the Sun API).
Seems to me that the same thing should apply here.
Quite possibly. PMC people, what's your say in this? How do we resolve (a) the legal issues, and then (b) what step(s) are necessary to get the decision ratified?
I don't know the
licensing/redistribution issues associated with the JavaMail API (as
opposed to the implementation) are actually compatible with Geronimo's
goals. There's been some debate about not using LGPL stuff in Geronimo,
for example. In any case, my purpose was to provide an implementation
Which is *fine* but you are actually providing a copy of the API which may
be much less fine..
No, I am not copying the API. I am implementing it from JavaDoc and from the spec. I have not used any reference to either the RI or the source code in order to do it. I am fully complying to the extent that I am aware from the JavaMail-spec-license which declares that it is allowable to provide a clean-room implementation of the APIs provided that no source or binary reference to the RI is allowable.
and then let the community decide (as opposed to just the committers) what to do with it.
.. particularly if you are not prepared to stick around and maintain it.
... then it can just be deleted. Or someone else can maintain it. Or legal issues can be resolved with Sun to allow (re)distribution of the mailapi.jar. Or we can have a J2EE server without mail support and fail the TCK. Or ...
If I am the only person actually interested in this JavaMail API then it is clearly a bad thing if I go elsewhere/don't come back. And I had hoped that there would be a little more support for wanting the JavaMail APIs in the James group (hence the original cross-posting of the announcement), or indeed for other Apache projects (maven, ant, turbine) that may require the use of JavaMail.
Having an ASF JavaMail API (and implementation) would allow that, and if it were going to be cross-used, then a migration to commons-javamail (or similar) would make eventual sense. And if many projects were to use the commons-javamail (especially if some of them -- like Geronimo -- were using it and running against the TCK) then there would be a lot more reason to keep it up.
The Transports and Stores and other classes distributed in the "com.sun" packages are Sun's "refrence implementation" of the API,
I think the term 'reference implementation' can be misused as well.
Not really, it is used to describe the implementation produced and approved
by Sun of an API which is intended to be used as a benchmark to demonstrate
how an implementation of the API should function.
No. The JavaMail Reference Implementation is their implementation of both the com.sun mail transports/stores, and also the implementation of the API. They have not released a seperate JavaMail API and JavaMail implementation; it is all one bundle. Granted, within the bundle they have different Jars, but the entire thing is referred to as the JavaMail Reference Implementation, or even more incorrectly, the JavaMail API.
I meant my replacement to be both the API and an implementation of Store/transport as appropriate.
Yep I know, but why copy the API?
Because in my inexpert legal opinion, Apache does not have the right to re-re-distribute mailapi.jar or mail.jar from the JavaMail Reference Implementation/API package. Thus we can provide a program that contains mailapi.jar, but we can't allow others to redistribute the geronimo package. Immediately, therefore, we can't have mailapi.jar in the Geronimo codebase and for that codebase to be handled by mirrors around the world.
Anything which was capable of being used wholly in place of the API would be an alternative API, not an implementation.
Correct, and I'm not proposing to do this.
But you *ARE* doing it, I'm watching you do it.
No, it's the same API conforming to the same interface. Perhaps it's my mis-interpretation of your 'alternative API' or 'wholly in place of the API'.
I'm implementing the javax.mail package as described by http://java.sun.com/products/javamail/ as the specs/javamail module. Nothing more, nothing less.
Are we not therfore creating an alternative when we should actually be
creating an implementation?
No, we are creating a clone of the API and an implementation of the
API. Licensing issues surrounding the API itself are unclear, whereas a
clean-room implementation of them is clearer.
Yes and who has decided that it is worth hosting and maintaining a project
to do this for javaMail, simply in order to redistirbute it under the ASFL?
1. Geronimo must have a JavaMail component to satisfy the J2EE TCK.
2. It has been mandated that Geronimo will pass the 1.4 J2EE TCK.
3. It is not (IMNSHO/IANAL) possible to redistribute the mailapi.jar file
4. In the absence of redistributing the mailapi.jar file, an alternative must be found.
There seemed to be issues as to whether even having the JavaMail in the
distribution were possible; the alternative being to force the user to
download it from Sun.
Which James does, believe me it is not a barrier, though I admit it may be a
slight inconvenience.
And there is no-one on the James team who would think an ASFL JavaMail would be a good thing?
Maintenance is likely (IMNSHO) to be a trivial issue and once built,
only deltas in the spec will need to be applied. Hopefully others will
be sufficiently interested (e.g. in the James camp, or if it migrates
into commons-javamail) to perform those changes as and when. It may not
be the original Geronimo people that do this.
But why would anyone bother to maintain this when Sun's original version of
the API is available?
You would only do this if the API is unavailalbe. My inexpert legal readings indicate that it is. Similarly, James does not redistribute it because you are not allowed to.
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.
Is it, though? My understanding of the API license is that you can't do
it in an ASF-compatible license (for the reasons that James doesn't
ship with the API).
James doesn't ship source with javaMail coreect, james binaries can and are
shipped with javaMail.
Is this in the letter of the license, though? Do you have the right to distribute it, and allow others to redistribute that?
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.
I don't know what the talks are; it just lists them on the apache websites :-)
You yourself say "licensing their JavaMail implementation" this is _by_definition_ the RI not the API.
Sun uses the term "JavaMail API" to mean their reference implementation. The javax.mail API are only downloadable through their Reference Implementation.
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.
If it comes to a stage where the API implementation (as opposed to the
transport/store implementation) is becoming delapidated, then no doubt
it will be something that can be junked then. At least in the meantime,
we have an open-source (in the sense of freely redistributable) API
that we can use to build the transports/stores.
I don't think that is the Apache Way, I've been led to understand that the
most important thing is community, that products should be maintained by
self-sustaining communities.
Agreed. And hopefully, this will become one for the whole J2EE space.
Ideally, this would also happen for the JavaMail as well, but although some other patches have been made to the specs/javamail (and activation package, on which it depends) I have done the bulk of the initial work. But that's not to say in the future it won't develop, and everything has to start somewhere. Killing off a product because within a week it has not got a full community behind it is a bit of overkill IMNSHO ...
The incubator exists to build such communities, geronimo is being incubated.
My problem is that your copy of javaMail isn't a project being incubated, no
one has taken any decision that it should be pursued and I feel quite
strongly that it may be more of a liability to geronimo than an asset in the
longer term.
It's part of the goal of Geronimo, though. Geronimo provides a J2EE server, that server needs a mail stack, and that's what I'm working towards.
It's good that you're raising concerns about the long-term life of JavaMail here. Hopefully others (if they are still reading this by now :-) will realise that it's not just me, and that everyone can make it better.
It's also good that you're explicitly bringing this to the attention of the PMC. Hopefully a decision will not be far off.
Alex.
