Kees Jongenburger wrote:
> it's currently even more complicated, depending on whether a jar is
> present at compile time the resulting mmbase.jar is diffrent (you are
> reversing the problem by demanding that a developer will compile
> against informix)

A developer does not need to compile against informix, unless he is testing it.

As long as we make sure that the release is compiled against informix, I think 
everything is fine.

> I am in favour of making a difference between compille time and
> runtime, but not in those situations. servler.jar is the only
> compiletime required jar that I can think of (I'm not that smart :) ).

log4j.jar, too, I think (also not at runtime).


> If editwizards required xerces, it's fine 
> if tests require junit that's fine to
> but why require informix / javamail in the core?

I think it is clear that we should support Informix, and it seems useful to support 
mail.

> are you shure javamail is shiped with tomcat?

No.

> 
> Is there already code in the core that requires javamail?

Only JMSendMail, I presume.


> btw if informix where to be removed from the core the build process
> would become more elegant.

But the installation process would become less elegant. You'll end up adding two or 
more jars for
everything that we support.

mmbase-log4j.jar (with only 5 or 6 classes)
log4j.jar

mmbase-informix.jar (only 2 or 3 classes)
informix.jar

you'll probably also have to do it for every other database, just for symmetry, also 
if at compile
time hsql.jar is not ncessary, you'll of course still should compile a mmbase-hsql.jar 
(hsql.jar may
become necessary during compile-time, isn't it?)


mmbase-email.jar
mmbase-mail.jar (only JMSendMail.java, and perhaps 1 or 2 others, e.g. SendMail.java, 
and SendMailInterface)
mail.jar


I think building all those jars will take ages (only the lengthyness of stdout of ant 
is already
terrifying!), while compiling 20 or 30 classes more in mmbase.jar, will hardly be 
noticeable.

Yes, the build.xml for mmbase.jar itself will become very simple, but we'll simply 
have more
build.xml's instead..

I can perhaps agree even this is elegant, but I only want to doubt if really this is
practicle. Applications are nice, but should we really move everything what is slighly 
optional to
one? Perhaps, perhaps not.

Btw, the informix compile time dependency is only in the support class, so this 
dependency will be
dropped any way.

Michiel


-- 
Michiel Meeuwissen                  mihxil'
Mediacentrum 140 H'sum                [] ()
+31 (0)35 6772979         nl_NL eo_XX en_US




Reply via email to