On Feb 9, 2006, at 9:43 AM, Bruce Snyder wrote:
On 2/9/06, Kevan Miller <[EMAIL PROTECTED]> wrote:
On Feb 9, 2006, at 5:06 AM, Rick McGuire wrote:
David Blevins wrote:
On Feb 8, 2006, at 4:26 PM, Rick McGuire wrote:
David Blevins wrote:
On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote:
David Blevins wrote:
At first blush it looks like there are just three util classes
that make the javamail-transport module dependent on our
specific javamail implementation.
Do you think it makes much sense to try and keep them separate?
Or are they too coupled already to be worth it?
It's kind of a PITA to have to have a tight (i.e. snapshot)
dependency on a spec project. But obviously javamail is a mess
and it may just be too hard.
I'm starting to think it was a mistake to have javamail-transport
be a separate jar file from the spec code. In the Sun case, all
of the code is in a single jar, so you only need the javamail jar
and the activation jar to use it. Because of our current split,
we require 3 jars. It might make sense to move the transport/
store code into the spec jar since they are so tightly coupled.
If they are fundamentally one unit and completely tied together,
it may make more sense to put them together. Course, I may not
understand the implications of what I say :)
The javamail-transport module got created, I believe, from a
combination and history. The SMTP transport code was not
originally included with the spec code, but resided in the sandbox
for a while. When it got promoted out of the sandbox, it was
placed into it's own module in the Geronimo tree rather than rolled
into the spec code. Probably ok if this is only used bundled with
Geronimo, but makes less sense if we believe this might be used
standalone.
I guess if the javamail-transport module is going to be where all
the change occurs, then having it outside specs kind of handy --
provided the javamail module itself calms down and doesn't keep
changing right along with it.
I believe it's going to be a while before the spec module calms
down. I'm finding more and more unimplemented/incompletely
implemented features all the time.
Hi Rick,
I started to look at adding the javamail spec to GBuild, yesterday,
before seeing this thread. Two benefits -- 1) forced me to look at
how projects get added to continuum and 2) more importantly, should
be much easier to make spec changes generally available.
This will still require the occasional online build (or manual
download) when the javamail spec changes, but is still better than
the current situation.
Since I'm ready to go, I'll go ahead and commit my changes and get
things running.
Thanks for doing this, Kevan, but shouldn't we put the entire specs
project in there instead of just a single module? I'm not sure if
other modules are going to be moving as much as JavaMail.
Also, I'm not sure if GBuild will know to build the spec using Maven 2
or not - do you know? If not, as David Blevins advised me, we may need
to just create a small shell script that calls mvn clean install,
check it into the specs SVN base dir and then set up the JavaMail
build as a shell script that calls the script.
Hi Bruce,
I was thinking of adding the entire specs project also. However,
David Blevins advised against it and convinced me that it's not a
wise thing to do. Let's see how I can do... ;-)
The basic issue is that the specs project is composed of SNAPSHOT and
non-SNAPSHOT modules. If we add the entire specs project to GBuild,
we'll start publishing both types of modules (or it will be hard not
to do so...). This seems unwise. Plus, if we update a spec without
updating the spec version in pom.xml, we might start publishing non-
SNAPSHOT modules with new content. Doubly unwise.
I think it's best that we only add individual SNAPSHOT spec modules
to GBuild. When these modules are released, we'll need to remove them
from GBuild. This process could use a bit more rigor, but shouldn't
be too hard to manage...
Thoughts?
FYI, after 1 misstep, javamail is building on GBuild. Now, just need
to add specs to the rsync that's moving things to apache...
--kevan
