You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bi...@apache.org on 2006/04/10 03:36:20 UTC
svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
Author: billbarker
Date: Sun Apr 9 18:36:19 2006
New Revision: 392872
URL: http://svn.apache.org/viewcvs?rev=392872&view=rev
Log:
Restore the ability to build with the Mail Resources
Modified:
tomcat/tc6.0.x/trunk/build.xml
Modified: tomcat/tc6.0.x/trunk/build.xml
URL: http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/build.xml?rev=392872&r1=392871&r2=392872&view=diff
==============================================================================
--- tomcat/tc6.0.x/trunk/build.xml (original)
+++ tomcat/tc6.0.x/trunk/build.xml Sun Apr 9 18:36:19 2006
@@ -60,7 +60,15 @@
<target name="build-prepare">
<available classname="junit.framework.TestCase" property="junit.present" />
-
+ <condition property="javamail.present">
+ <and>
+ <available classname="javax.activation.DataSource"
+ classpath="${activation.jar}" />
+ <available classname="javax.mail.Service"
+ classpath="${mail.jar}" />
+ </and>
+ </condition>
+
<mkdir dir="${tomcat.classes}"/>
<mkdir dir="${tomcat.build}"/>
@@ -82,8 +90,10 @@
excludes="**/CVS/**,**/.svn/**">
<classpath refid="tomcat.classpath" />
<exclude name="org/apache/tomcat/util/net/puretls/**" />
- <exclude name="org/apache/naming/factory/MailSessionFactory.java"/>
- <exclude name="org/apache/naming/factory/SendMailFactory.java"/>
+ <exclude name="org/apache/naming/factory/MailSessionFactory.java"
+ unless="javamail.present" />
+ <exclude name="org/apache/naming/factory/SendMailFactory.java"
+ unless="javamail.present" />
</javac>
<!-- Copy static resource files -->
<filter token="VERSION" value="${version}"/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Yes, that's a good option if we want to keep this feature as part of
> the core and not
> modularize it.
I don't see any reason to ship javamail binaries.
> What about having 2 distros of tomcat - a minimal container, and a
> bloated one with
> all the features bundled. Lazy people can get the large one, and not
> have to download
> anything.
I would like to keep things equivalent to 5.5: a reasonable feature set.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
Posted by Costin Manolache <co...@gmail.com>.
On 4/11/06, Bill Barker <wb...@wilshire.com> wrote:
>
>
> > -----Original Message-----
> > From: Costin Manolache [mailto:costin@gmail.com]
> > Sent: Tuesday, April 11, 2006 9:36 AM
> > To: Tomcat Developers List
> > Subject: Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
> >
> > On 4/11/06, Remy Maucherat <re...@apache.org> wrote:
> > > Costin Manolache wrote:
> > > > What about: keep them excluded in the build target for
> > tomcat, but add a
> > > > separate target to build only javamail-dependent classes,
> > and package them in
> > > > a separate jar.
> > > >
> > > > That would keep 'core' tomcat clean, and would work for
> > other kind of
> > > > modules that have external deps.
> > > >
> > > > It would be even better if we could just move them in a separate
> > > > package - for example
> > > > org.apache.tomcat.modules.mail, and exclude o.a.t.modules from the
> > > > core build. Everything that will have external deps, and
> > maybe things
> > > > that are not essential could go there.
> > >
> > > This is a possibility, but maybe there are solutions in
> > this particular
> > > case.
> >
> > The solution depends on how you define the problem :-)
> >
> > If you think the problem is to compile javamail dependent code - you
> > are right, dummy or
> > link would work. Next problem would be how people could use it - even
> > if it is in tomcat,
> > they'll need to download additional jars, etc.
> >
>
> Well, if we use the Geronimo jars, then it would be possible to ship them
> with the binary distro, since they are ASF licensed :).
Yes, that's a good option if we want to keep this feature as part of
the core and not
modularize it.
>
>
> > I define the problem as "this should be an optional component, not
> > really required by
> > the spec or used by majority of users". The people who use it are
> > likely to be in a J2EE
> > environment where they have javamail, and could easily have the
> > additional tomcat module.
> >
>
> I mostly favor keeping the JavaMail support, since removing it (or even
> making it a separate download) is likely to generate a flood of BZ reports
> from people that can't be bothered to read the docs :). It has been there
> since TC 4.0.0, so a lot of people are going to expect to just drop their
> old war into TC 6 and have it work.
What about having 2 distros of tomcat - a minimal container, and a
bloated one with
all the features bundled. Lazy people can get the large one, and not
have to download
anything.
Costin
>
>
>
> >
> > Costin
> >
> >
> > >
> > > For example, I can either add my dummy classes, or a svn
> > link could be
> > > created to
> > >
> > https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo
> > -spec-javamail/src/main/java/javax/mail
> > > (and activation too)
> > >
> > > Rémy
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> > >
> >
>
>
>
> This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> I mostly favor keeping the JavaMail support, since removing it (or even
> making it a separate download) is likely to generate a flood of BZ reports
> from people that can't be bothered to read the docs :). It has been there
> since TC 4.0.0, so a lot of people are going to expect to just drop their
> old war into TC 6 and have it work.
Ok, I thought about it some more, and I would like to keep the JavaMail
support present.
About the APIs, I think we should (eventually) use SVN links to the
proper folders in https://svn.apache.org/repos/asf/geronimo/specs/trunk
and make them part of (in a virtual way) our source tree. For now
(especially since the new APIs are not there yet), I will continue
putting temporary stuff in the javax. folder to make sure everything builds.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
Posted by Bill Barker <wb...@wilshire.com>.
> -----Original Message-----
> From: Costin Manolache [mailto:costin@gmail.com]
> Sent: Tuesday, April 11, 2006 9:36 AM
> To: Tomcat Developers List
> Subject: Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
>
> On 4/11/06, Remy Maucherat <re...@apache.org> wrote:
> > Costin Manolache wrote:
> > > What about: keep them excluded in the build target for
> tomcat, but add a
> > > separate target to build only javamail-dependent classes,
> and package them in
> > > a separate jar.
> > >
> > > That would keep 'core' tomcat clean, and would work for
> other kind of
> > > modules that have external deps.
> > >
> > > It would be even better if we could just move them in a separate
> > > package - for example
> > > org.apache.tomcat.modules.mail, and exclude o.a.t.modules from the
> > > core build. Everything that will have external deps, and
> maybe things
> > > that are not essential could go there.
> >
> > This is a possibility, but maybe there are solutions in
> this particular
> > case.
>
> The solution depends on how you define the problem :-)
>
> If you think the problem is to compile javamail dependent code - you
> are right, dummy or
> link would work. Next problem would be how people could use it - even
> if it is in tomcat,
> they'll need to download additional jars, etc.
>
Well, if we use the Geronimo jars, then it would be possible to ship them
with the binary distro, since they are ASF licensed :).
> I define the problem as "this should be an optional component, not
> really required by
> the spec or used by majority of users". The people who use it are
> likely to be in a J2EE
> environment where they have javamail, and could easily have the
> additional tomcat module.
>
I mostly favor keeping the JavaMail support, since removing it (or even
making it a separate download) is likely to generate a flood of BZ reports
from people that can't be bothered to read the docs :). It has been there
since TC 4.0.0, so a lot of people are going to expect to just drop their
old war into TC 6 and have it work.
>
> Costin
>
>
> >
> > For example, I can either add my dummy classes, or a svn
> link could be
> > created to
> >
> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo
> -spec-javamail/src/main/java/javax/mail
> > (and activation too)
> >
> > Rémy
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
Posted by Costin Manolache <co...@gmail.com>.
On 4/11/06, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > What about: keep them excluded in the build target for tomcat, but add a
> > separate target to build only javamail-dependent classes, and package them in
> > a separate jar.
> >
> > That would keep 'core' tomcat clean, and would work for other kind of
> > modules that have external deps.
> >
> > It would be even better if we could just move them in a separate
> > package - for example
> > org.apache.tomcat.modules.mail, and exclude o.a.t.modules from the
> > core build. Everything that will have external deps, and maybe things
> > that are not essential could go there.
>
> This is a possibility, but maybe there are solutions in this particular
> case.
The solution depends on how you define the problem :-)
If you think the problem is to compile javamail dependent code - you
are right, dummy or
link would work. Next problem would be how people could use it - even
if it is in tomcat,
they'll need to download additional jars, etc.
I define the problem as "this should be an optional component, not
really required by
the spec or used by majority of users". The people who use it are
likely to be in a J2EE
environment where they have javamail, and could easily have the
additional tomcat module.
Costin
>
> For example, I can either add my dummy classes, or a svn link could be
> created to
> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/javax/mail
> (and activation too)
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> What about: keep them excluded in the build target for tomcat, but add a
> separate target to build only javamail-dependent classes, and package them in
> a separate jar.
>
> That would keep 'core' tomcat clean, and would work for other kind of
> modules that have external deps.
>
> It would be even better if we could just move them in a separate
> package - for example
> org.apache.tomcat.modules.mail, and exclude o.a.t.modules from the
> core build. Everything that will have external deps, and maybe things
> that are not essential could go there.
This is a possibility, but maybe there are solutions in this particular
case.
For example, I can either add my dummy classes, or a svn link could be
created to
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/javax/mail
(and activation too)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
Posted by Costin Manolache <co...@gmail.com>.
What about: keep them excluded in the build target for tomcat, but add a
separate target to build only javamail-dependent classes, and package them in
a separate jar.
That would keep 'core' tomcat clean, and would work for other kind of
modules that have external deps.
It would be even better if we could just move them in a separate
package - for example
org.apache.tomcat.modules.mail, and exclude o.a.t.modules from the
core build. Everything that will have external deps, and maybe things
that are not essential could go there.
Costin
On 4/10/06, Remy Maucherat <re...@apache.org> wrote:
> Bill Barker wrote:
> > My patch does nothing, unless you specify the jars specifically in the
> > build.properties file. There was a good reason that I didn't patch
> > build.properties.default as well.
> >
> > I'm +1 to use the Geronimo implementations of JavaMail, +0 to using the
> > optional configuration that I just put in, -1 to removing any ability to
> > build Tomcat without even optional JavaMail support.
>
> Is it really urgent to restore the compilation of these components ?
> Personally, I would like to avoid restoring the mess that was the old
> build scripts, so I don't see a problem with keeping these off for now.
> I think API files that won't be shipped with the binary or used anywhere
> else will be needed in our repositories (for example, for supporting the
> EJB and JPA related annotations, while avoiding to run into conflicts or
> advertising support we don't actually have).
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> My patch does nothing, unless you specify the jars specifically in the
> build.properties file. There was a good reason that I didn't patch
> build.properties.default as well.
>
> I'm +1 to use the Geronimo implementations of JavaMail, +0 to using the
> optional configuration that I just put in, -1 to removing any ability to
> build Tomcat without even optional JavaMail support.
Is it really urgent to restore the compilation of these components ?
Personally, I would like to avoid restoring the mess that was the old
build scripts, so I don't see a problem with keeping these off for now.
I think API files that won't be shipped with the binary or used anywhere
else will be needed in our repositories (for example, for supporting the
EJB and JPA related annotations, while avoiding to run into conflicts or
advertising support we don't actually have).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
Posted by Bill Barker <wb...@wilshire.com>.
"Remy Maucherat" <re...@apache.org> wrote in message
news:443A13C4.30106@apache.org...
> billbarker@apache.org wrote:
>> Author: billbarker
>> Date: Sun Apr 9 18:36:19 2006
>> New Revision: 392872
>>
>> URL: http://svn.apache.org/viewcvs?rev=392872&view=rev
>> Log:
>> Restore the ability to build with the Mail Resources
>
> Sorry, I am not going to accept these dependencies on proprietary code
> anymore. I may add dummy API sources in the repository (that will not get
> bundled, obviously), rewrite the classes using reflection, or remove
> javamail support. Would these solutions work for you ?
>
My patch does nothing, unless you specify the jars specifically in the
build.properties file. There was a good reason that I didn't patch
build.properties.default as well.
I'm +1 to use the Geronimo implementations of JavaMail, +0 to using the
optional configuration that I just put in, -1 to removing any ability to
build Tomcat without even optional JavaMail support.
> I will add back the other JARs eventually, including DBCP and JDT.
>
> R�my
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r392872 - /tomcat/tc6.0.x/trunk/build.xml
Posted by Remy Maucherat <re...@apache.org>.
billbarker@apache.org wrote:
> Author: billbarker
> Date: Sun Apr 9 18:36:19 2006
> New Revision: 392872
>
> URL: http://svn.apache.org/viewcvs?rev=392872&view=rev
> Log:
> Restore the ability to build with the Mail Resources
Sorry, I am not going to accept these dependencies on proprietary code
anymore. I may add dummy API sources in the repository (that will not
get bundled, obviously), rewrite the classes using reflection, or remove
javamail support. Would these solutions work for you ?
I will add back the other JARs eventually, including DBCP and JDT.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org