Re: Lang dependency [VOTE] Release Commons Email 1.0
On Fri, 2005-09-02 at 12:40 +, Henning P. Schmiedehausen wrote: Stephen Colebourne [EMAIL PROTECTED] writes: The dependency on commons-lang is IMHO not really a big issue. The jar has ~ 200k and we are talking about a component which is probably not used on J2ME. If 200k for a really useful library is a problem, then commons-email isn't probably the right tool either. This is a belief that is correct in theory, yet proves wrong in practice (based on user feedback). At some point, I shall have to draw together all the URLs from the net regarding inter-commons dependencies. The two issues are jar-hell (where jar versions required by two jars clash), and the forced jar effect (where users resent having to pickup other jars to use a library jar). I know everything about jar hell, using unreleased jar versions, maven SNAPSHOTs and build tools that suddently get redesigned while you are not looking. Trust me. I'm from Turbine. :-) I'd actually agree with you if it wasn't for commons-lang. To me, there are two commons libs which I would consider ok for another commons component to depend on them: commons-lang and commons-collections. Both are pretty stable, have no external dependencies themselves and they contain such a huge number of useful classes, that trying to replace these would IMHO lead to code duplication and code-rotting. Personally, I pretty much consider c-l and c-c part of the regular java toolbox. Trying to invent that code again and again makes IMHO no sense. We tried this over in Turbine land and I can only say I'm happy that we finally got rid of all that reinvented code and use the commons. it's been great to see code factored into reusable libraries such as lang and collections. however, the perspective of creating basic reusable libraries is very different from the perspective of creating applications. over the years, some pretty bitter lessons have been learnt about the difficulties that arise from dependencies between basic libraries. i agree with stephen that dependencies between commons libraries is now considered something to be avoided whenever possible. many middleware vendors now repackage the basic libraries they use. this allows them to depend upon a single known version without risking conflict with libraries used by applications. so, i'd suggest that email adopts a solution along those lines. the simplest and quickest approach would be to simply copy the necessary source and repackage it as org.apache.commons.email.lang. if people are happy with this approach, i'd be willing to make the change. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lang dependency [VOTE] Release Commons Email 1.0
Henning P. Schmiedehausen wrote: Give us a patch. Code before words. As I said, I've looked into this and I might do some work for 1.1. Not for 1.0. I send this as a patch on Bugzilla today. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lang dependency [VOTE] Release Commons Email 1.0
Stephen Colebourne [EMAIL PROTECTED] writes: Henning P. Schmiedehausen wrote: Give us a patch. Code before words. As I said, I've looked into this and I might do some work for 1.1. Not for 1.0. I send this as a patch on Bugzilla today. Cool. Thanks. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lang dependency [VOTE] Release Commons Email 1.0
robert burrell donkin [EMAIL PROTECTED] writes: so, i'd suggest that email adopts a solution along those lines. the simplest and quickest approach would be to simply copy the necessary source and repackage it as org.apache.commons.email.lang. if people are happy with this approach, i'd be willing to make the change. I'm -0 on simply repackaging to o.a.e.l at least for the EmailException. We don't need the Nestable Interface and the shebang surrounding it. Stephen suggested using the patten used in commons-collections and that would be fine with me. For StringUtils and RandomStringUtils, I'm +1. Do we copy all of this or just the methods that we need? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lang dependency [VOTE] Release Commons Email 1.0
Henning P. Schmiedehausen writes:
Stephen Colebourne [EMAIL PROTECTED] writes:
My -1 will change to -0 if there is no public API
dependency on [lang] (as the dependency can then be
removed in v1.1). Which means changing the superclass
of EmailException, and following the pattern of
[collections] FunctorException.
Give us a patch. Code before words. As I said, I've looked into this
and I might do some work for 1.1. Not for 1.0.
Regards
Henning
The patch is in the attachment, followed by the Java code itself, and
there is nothing special: it does the same things, but without
dependency exposed in public API.
There will be not so good idea to apply this after release 1.0, since
that will mean breaking binary compatibility.
--Andrei Polushin
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.mail;
import java.io.PrintStream;
import java.io.PrintWriter;
/**
* EmailException
* @author jakarta-commons
* @since 1.0
*/
public class EmailException extends Exception
{
/** serialization version */
static final long serialVersionUID = 5550674499282474616L;
/** Does [EMAIL PROTECTED] Throwable} support nested exceptions. */
private static final boolean HAVE_THROWABLE_CAUSE = haveThrowableCause();
private static boolean haveThrowableCause()
{
try {
Throwable.class.getDeclaredMethod(getCause, new Class[0]);
return true;
} catch (NoSuchMethodException ex) {
return false;
}
}
/** The exception or error that caused this exception to be thrown. */
private Throwable cause = null;
/**
* Create a new EmailException with no message and no cause.
* Note: This constructor should only be used as a last resort. Please
* provide at least a message.
* @since 1.0
*/
public EmailException()
{
super();
}
/**
* Create a new EmailException with a message but no other cause.
* @param msg the reason for this exception.
* @since 1.0
*/
public EmailException(String msg)
{
super(msg);
}
/**
* Create a new EmailException with a message and a cause.
* @param msg the reason for this exception.
* @param cause the contributing Throwable (e.g. some other Exception)
* @since 1.0
*/
public EmailException(String msg, Throwable cause)
{
super(msg);
this.cause = cause;
}
/**
* Create a new EmailException with a cause but no message.
* @param cause the contributing Throwable (e.g. some other Exception)
* @since 1.0
*/
public EmailException(Throwable cause)
{
super(cause == null ? null : cause.getMessage());
this.cause = cause;
}
/**
* Returns the exception or error that caused this exception to be thrown.
* @return the cause of this exception or codenull/code if the
* cause is nonexistent or unknown.
* @since 1.0
*/
public Throwable getCause()
{
return cause;
}
/**
* Prints the stack trace of this exception to the standard error stream.
*/
public void printStackTrace()
{
printStackTrace(System.err);
}
/**
* Prints the stack trace of this exception to the specified stream.
*
* @param out the codePrintStream/code to use for output
*/
public void printStackTrace(PrintStream out)
{
synchronized (out)
{
PrintWriter pw = new PrintWriter(out, false);
printStackTrace(pw);
pw.flush();
}
}
/**
* Prints the stack trace of this exception to the specified writer.
*
* @param out the codePrintWriter/code to use for output
*/
public void printStackTrace(PrintWriter out)
{
synchronized (out)
{
super.printStackTrace(out);
if (cause != null !HAVE_THROWABLE_CAUSE)
{
out.print(Caused by: );
cause.printStackTrace(out);
}
}
}
}
diff -d -r -C2
commons-email.orig/src/java/org/apache/commons/mail/EmailException.java
commons-email/src/java/org/apache/commons/mail/EmailException.java
*** commons-email.orig/src/java/org/apache/commons/mail/EmailException.java
Fri Sep 02 18:38:56 2005
---
Re: Lang dependency [VOTE] Release Commons Email 1.0
Stephen Colebourne wrote: Henning P. Schmiedehausen wrote: Give us a patch. Code before words. As I said, I've looked into this and I might do some work for 1.1. Not for 1.0. I send this as a patch on Bugzilla today. The patches are now there. They remove the whole [lang] dependency by adding a package scoped EmailUtils class, and changing the EmailException class. The EmailException change could be applied separately if desired, but since the tests pass with the whole change, I would suggest applying it. I also noticed an oddity in Email.sendMimeMessage(), where the Validate.notNull() method was used. This [lang] method will throw an IllegalArgumentException in case of error, yet this is undocumented by sendMimeMessage(). Also, every other error thrown by [email] is an EmailException. So, perhaps this should be changed to throw an EmailExecption? BTW: The new classes use [lang]/[collections] brace positioning. Feel free to adjust if you have a code formatter, or tell me to adjust them. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lang dependency [VOTE] Release Commons Email 1.0
--- Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Stephen Colebourne [EMAIL PROTECTED] writes: Could you now please either supply strong facts (I do agree up to some point with you on the lang issue and I'm currently looking into it. But I see no way that we do any changes for the 1.0 release) or leave it. I am asking for the exception to be changed with my -1. I am requesting the dependency to be removed because it is essentially unecessary, and will damage the reputation of [email] and commons by its presence. However I recognise that the removal of the dependency is more of a decision for the email committers. You had seven release candidates time to raise your concerns. Doing it on the vote isn't exactly nice. I understand your fustration. We all have time constraints. Part of my role as a commons committer (and not an email committer) is to object to mistakes that will bite commons as a whole, eg. via loss of reputation. This is particularly important for a first release. The dependency on commons-lang is IMHO not really a big issue. The jar has ~ 200k and we are talking about a component which is probably not used on J2ME. If 200k for a really useful library is a problem, then commons-email isn't probably the right tool either. This is a belief that is correct in theory, yet proves wrong in practice (based on user feedback). At some point, I shall have to draw together all the URLs from the net regarding inter-commons dependencies. The two issues are jar-hell (where jar versions required by two jars clash), and the forced jar effect (where users resent having to pickup other jars to use a library jar). My -1 will change to -0 if there is no public API dependency on [lang] (as the dependency can then be removed in v1.1). Which means changing the superclass of EmailException, and following the pattern of [collections] FunctorException. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lang dependency [VOTE] Release Commons Email 1.0
Stephen Colebourne [EMAIL PROTECTED] writes: The dependency on commons-lang is IMHO not really a big issue. The jar has ~ 200k and we are talking about a component which is probably not used on J2ME. If 200k for a really useful library is a problem, then commons-email isn't probably the right tool either. This is a belief that is correct in theory, yet proves wrong in practice (based on user feedback). At some point, I shall have to draw together all the URLs from the net regarding inter-commons dependencies. The two issues are jar-hell (where jar versions required by two jars clash), and the forced jar effect (where users resent having to pickup other jars to use a library jar). I know everything about jar hell, using unreleased jar versions, maven SNAPSHOTs and build tools that suddently get redesigned while you are not looking. Trust me. I'm from Turbine. :-) I'd actually agree with you if it wasn't for commons-lang. To me, there are two commons libs which I would consider ok for another commons component to depend on them: commons-lang and commons-collections. Both are pretty stable, have no external dependencies themselves and they contain such a huge number of useful classes, that trying to replace these would IMHO lead to code duplication and code-rotting. Personally, I pretty much consider c-l and c-c part of the regular java toolbox. Trying to invent that code again and again makes IMHO no sense. We tried this over in Turbine land and I can only say I'm happy that we finally got rid of all that reinvented code and use the commons. I simply don't see the point. It is like saying I don't want to use HashMap because it is not in JDK 1.2; I write my own class. The point of having commons is, that we actually use that code. We are not just showcasing this, we are eating our own dog food. And with tools that might some day (maven 2) or today (ivy) able to resolve transitive dependencies, I don't even see a reason not to include external dependencies even in the commons. And commons-email is not exactly an everyday, let's throw this in our application component like c-l, c-c or commons-math. My -1 will change to -0 if there is no public API dependency on [lang] (as the dependency can then be removed in v1.1). Which means changing the superclass of EmailException, and following the pattern of [collections] FunctorException. Give us a patch. Code before words. As I said, I've looked into this and I might do some work for 1.1. Not for 1.0. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
