geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <bruce.sny...@gmail.com>
Subject Re: Compilation errors in module javamail-transport
Date Thu, 09 Feb 2006 14:43:50 GMT
On 2/9/06, Kevan Miller <kevan.miller@gmail.com> 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.

Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

Apache Geronimo (http://geronimo.apache.org/)

Castor (http://castor.org/)

Mime
View raw message