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: [VOTE] Release Commons Email 1.0
Stephen Colebourne [EMAIL PROTECTED] writes: c) The jar file is built on JDK1.4. Is that your target JDK version? If your target is lower, then compiling using JDK1.4 can cause issues when running with earlier versions. This discussion has occurred before in the archives. The chances are that in a component like this, you won't be affected, but the risk is present. This point is -0. It is built with (in project.properties): maven.compile.source=1.3 maven.compile.target=1.3 so that shouldn't be a problem IMHO. (Eric and I did our tests on the 1.4.2 runtime, though). Thanks for pointing this out, if you advise to build the release using the 1.3.1 JDK, I will consider looking into this. 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: [VOTE] Release Commons Email 1.0
Stephen Colebourne [EMAIL PROTECTED] writes: d) Gump is currently failing commons-email. This doesn't give me confidence in giving email a +1. To quote Stefan: Gump is an experiment. Not a code testing tool. Did you actually _look_ at the gump output? It says: The build cannot continue because of the following unsatisfied dependency: maven-findbugs-plugin-0.9.1.jar (try downloading from http://maven-plugins.sourceforge.net/maven-findbugs-plugin/) And if you look at ibiblio: http://www.ibiblio.org/maven/maven-plugins/plugins/maven-findbugs-plugin-0.9.1.jar Oh look! It is there! It just seems that gump is running maven with -o. So it cannot find a dependency. Is this the fault of the project? Surely not. e) Text files, including the NOTICE and LICENSE use Unix line endings. This is a debated point, but I always prefer to see at least the zips use Windows line endings. % svn propget svn:eol-style LICENSE.txt native I build on Linux. Eric on some other unixish platform. If you volunteer to build the ZIPs for us on Windows or can convince the maven people to put some magic in so that the line endings are correct, fine. If you check out the source from SVN, you will get the correct line endings for your platform. This how it works. 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. You had seven release candidates time to raise your concerns. Doing it on the vote isn't exactly nice. 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. 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: [VOTE] Release Commons Email 1.0
I'd much rather we build the release with jdk 1.3. There are 1.4 specific methods, e.g. in StringBuffer that mean that code compiled on 1.4 wont necessarily run on 1.3 On 9/2/05, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Stephen Colebourne [EMAIL PROTECTED] writes: c) The jar file is built on JDK1.4. Is that your target JDK version? If your target is lower, then compiling using JDK1.4 can cause issues when running with earlier versions. This discussion has occurred before in the archives. The chances are that in a component like this, you won't be affected, but the risk is present. This point is -0. It is built with (in project.properties): maven.compile.source=1.3 maven.compile.target=1.3 so that shouldn't be a problem IMHO. (Eric and I did our tests on the 1.4.2 runtime, though). Thanks for pointing this out, if you advise to build the release using the 1.3.1 JDK, I will consider looking into this. 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] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Email 1.0
Dion Gillard [EMAIL PROTECTED] writes: I'd much rather we build the release with jdk 1.3. There are 1.4 specific methods, e.g. in StringBuffer that mean that code compiled on 1.4 wont necessarily run on 1.3 I thought that the -source and -target switches of javac were intended to deal with these problems. Were they not? Anyway, I just tried the 1.3.1 JDK. The jar builds, the tests fail due to the fact that dumbster is compiled for 1.4 and my toolchain for rebuilding that (ant and everything) simply does not run on 1.3.1 any longer. So if anyone has a 1.3 compiled dumbster.jar for me, I'll try again. The 1.3.1 built jar passes the tests when running the test cases under the 1.4.2 runtime. You can get this jar from people.apache.org/~henning/commons-email-1.0-rc7.jar for testing. Personally I'd consider this good enough. As a side note: 1.3 is in EOL process at Sun. At what point do we consider compatibility to 1.3 no longer necessary? Regards Henning On 9/2/05, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Stephen Colebourne [EMAIL PROTECTED] writes: c) The jar file is built on JDK1.4. Is that your target JDK version? If your target is lower, then compiling using JDK1.4 can cause issues when running with earlier versions. This discussion has occurred before in the archives. The chances are that in a component like this, you won't be affected, but the risk is present. This point is -0. It is built with (in project.properties): maven.compile.source=1.3 maven.compile.target=1.3 so that shouldn't be a problem IMHO. (Eric and I did our tests on the 1.4.2 runtime, though). Thanks for pointing this out, if you advise to build the release using the 1.3.1 JDK, I will consider looking into this. 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] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Re: [VOTE] Release Commons Email 1.0
Henning P. Schmiedehausen wrote on Friday, September 02, 2005 1:00 PM: Dion Gillard [EMAIL PROTECTED] writes: I'd much rather we build the release with jdk 1.3. There are 1.4 specific methods, e.g. in StringBuffer that mean that code compiled on 1.4 wont necessarily run on 1.3 I thought that the -source and -target switches of javac were intended to deal with these problems. Were they not? Only if you tell the compiler to use also the rt.jar from the target JDK. Otherwise the compiler might chose a better fitting overloaded method, that was not available in the previous version. You can tell this Maven/Ant with a property, but this implies a known location of the proper rt.jar in the build environment. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Email 1.0
--- Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Stephen Colebourne [EMAIL PROTECTED] writes: d) Gump is currently failing commons-email. This doesn't give me confidence in giving email a +1. Did you actually _look_ at the gump output? It says: The build cannot continue because of the following unsatisfied dependency: maven-findbugs-plugin-0.9.1.jar My bad. Point withdrawn. 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]
Re: [VOTE] Release Commons Email 1.0
Which version of dumbster is being used? I specifically got a 1.3 version deployed to ibiblio to help us test this. On 9/2/05, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Dion Gillard [EMAIL PROTECTED] writes: I'd much rather we build the release with jdk 1.3. There are 1.4 specific methods, e.g. in StringBuffer that mean that code compiled on 1.4 wont necessarily run on 1.3 I thought that the -source and -target switches of javac were intended to deal with these problems. Were they not? Anyway, I just tried the 1.3.1 JDK. The jar builds, the tests fail due to the fact that dumbster is compiled for 1.4 and my toolchain for rebuilding that (ant and everything) simply does not run on 1.3.1 any longer. So if anyone has a 1.3 compiled dumbster.jar for me, I'll try again. The 1.3.1 built jar passes the tests when running the test cases under the 1.4.2 runtime. You can get this jar from people.apache.org/~henning/commons-email-1.0-rc7.jar for testing. Personally I'd consider this good enough. As a side note: 1.3 is in EOL process at Sun. At what point do we consider compatibility to 1.3 no longer necessary? Regards Henning On 9/2/05, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Stephen Colebourne [EMAIL PROTECTED] writes: c) The jar file is built on JDK1.4. Is that your target JDK version? If your target is lower, then compiling using JDK1.4 can cause issues when running with earlier versions. This discussion has occurred before in the archives. The chances are that in a component like this, you won't be affected, but the risk is present. This point is -0. It is built with (in project.properties): maven.compile.source=1.3 maven.compile.target=1.3 so that shouldn't be a problem IMHO. (Eric and I did our tests on the 1.4.2 runtime, though). Thanks for pointing this out, if you advise to build the release using the 1.3.1 JDK, I will consider looking into this. 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] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] dumbster and JDK 1.3 (was Re: [VOTE] Release Commons Email 1.0)
There is only a 1.0.3, a 1.5 and a 1.6 version of dumbster @ ibiblio. All three don't work with the 1.3 JDK. Regards Henning On Fri, 2005-09-02 at 22:47 +1000, Dion Gillard wrote: Which version of dumbster is being used? I specifically got a 1.3 version deployed to ibiblio to help us test this. On 9/2/05, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Dion Gillard [EMAIL PROTECTED] writes: I'd much rather we build the release with jdk 1.3. There are 1.4 specific methods, e.g. in StringBuffer that mean that code compiled on 1.4 wont necessarily run on 1.3 I thought that the -source and -target switches of javac were intended to deal with these problems. Were they not? Anyway, I just tried the 1.3.1 JDK. The jar builds, the tests fail due to the fact that dumbster is compiled for 1.4 and my toolchain for rebuilding that (ant and everything) simply does not run on 1.3.1 any longer. So if anyone has a 1.3 compiled dumbster.jar for me, I'll try again. The 1.3.1 built jar passes the tests when running the test cases under the 1.4.2 runtime. You can get this jar from people.apache.org/~henning/commons-email-1.0-rc7.jar for testing. Personally I'd consider this good enough. As a side note: 1.3 is in EOL process at Sun. At what point do we consider compatibility to 1.3 no longer necessary? Regards Henning On 9/2/05, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Stephen Colebourne [EMAIL PROTECTED] writes: c) The jar file is built on JDK1.4. Is that your target JDK version? If your target is lower, then compiling using JDK1.4 can cause issues when running with earlier versions. This discussion has occurred before in the archives. The chances are that in a component like this, you won't be affected, but the risk is present. This point is -0. It is built with (in project.properties): maven.compile.source=1.3 maven.compile.target=1.3 so that shouldn't be a problem IMHO. (Eric and I did our tests on the 1.4.2 runtime, though). Thanks for pointing this out, if you advise to build the release using the 1.3.1 JDK, I will consider looking into this. 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] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] -- 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 Linux, Java, perl, Solaris -- Consulting, Training, Engineering 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Email 1.0
-- 8- [X ] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 Thanks! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Email 1.0
On Wed, 2005-08-31 at 10:50 -0400, Eric Pugh wrote: --8- [X] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 - robert signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Commons Email 1.0
Eric Pugh wrote: --8- [ ] +1 Release Email 1.0 [ ] +0 General support but not definitive [X] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 -1 a) The dependency on [lang] is exposed in the public API of [email], thus you can never remove the dependency in the future. The problem is in EmailException which extends NestableException. This exposure can be removed by following the design pattern of FunctorException in [collections]. Leaving the dependency visible will seriously compromise [email] in the future. b) The dependency on [lang] is excessive for such a small component. I recognise that there are differing views on this so I will leave this point as a -0, but see point (a). However, in my opinion, the [lang] dependency should be removed before v1.0 with the creation of a package scoped util class with the four required methods from [lang]. c) The jar file is built on JDK1.4. Is that your target JDK version? If your target is lower, then compiling using JDK1.4 can cause issues when running with earlier versions. This discussion has occurred before in the archives. The chances are that in a component like this, you won't be affected, but the risk is present. This point is -0. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Email 1.0
Stephen Colebourne wrote: Eric Pugh wrote: --8- [ ] +1 Release Email 1.0 [ ] +0 General support but not definitive [X] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 -1 a) The dependency on [lang] is exposed in the public API of [email], thus you can never remove the dependency in the future. The problem is in EmailException which extends NestableException. This exposure can be removed by following the design pattern of FunctorException in [collections]. Leaving the dependency visible will seriously compromise [email] in the future. b) The dependency on [lang] is excessive for such a small component. I recognise that there are differing views on this so I will leave this point as a -0, but see point (a). However, in my opinion, the [lang] dependency should be removed before v1.0 with the creation of a package scoped util class with the four required methods from [lang]. c) The jar file is built on JDK1.4. Is that your target JDK version? If your target is lower, then compiling using JDK1.4 can cause issues when running with earlier versions. This discussion has occurred before in the archives. The chances are that in a component like this, you won't be affected, but the risk is present. This point is -0. two more points d) Gump is currently failing commons-email. This doesn't give me confidence in giving email a +1. e) Text files, including the NOTICE and LICENSE use Unix line endings. This is a debated point, but I always prefer to see at least the zips use Windows line endings. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Email 1.0
On 9/2/05, Stephen Colebourne [EMAIL PROTECTED] wrote: [snip] two more points d) Gump is currently failing commons-email. This doesn't give me confidence in giving email a +1. Gump is failing with a port in use problem. e) Text files, including the NOTICE and LICENSE use Unix line endings. This is a debated point, but I always prefer to see at least the zips use Windows line endings. Stephen -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Commons Email 1.0
Since commons-email RC 1 there have been quite a few new release candidates. At this point ALL the bugs in Bugzilla have been dealt with. The code has been tagged as EMAIL_1_0_RC7 and differs from RC6 in some doc/code cleanup and minor refactoring. The binaries and docs are available from http://people.apache.org/ ~epugh/commons-email/ I have ignored the unit tests as they are currently failing due to some other reason on my box. They all pass cleanly on other Commons developer's boxes. This might be a good thing to double check. Votes, please. The vote will run for 72 hours. --8- [ ] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 Thanks! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Email 1.0
Eric Pugh [EMAIL PROTECTED] writes: [X] +1 Release Email 1.0 The binaries and docs are available from http://people.apache.org/ ~epugh/commons-email/ I have ignored the unit tests as they are currently failing due to some other reason on my box. They all pass cleanly on other Commons developer's boxes. This might be a good thing to double check. jar:jar, site, dist:build-bin and dist:build-src are ok on Linux with JDK 1.4.2. And with the latest and greatest maven xdoc plugin, even the site is readable again... 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: [VOTE] Release Commons Email 1.0
Eric, What are the code dependencies of Email RC7 - Commons lang version? Etc. . Is it dependant on all current production releases - Or does it depend on other betas / release canditates. Sorry if this information is available elsewhere I just wouldn't know where to look Thanks, Allan -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 31, 2005 9:50 AM To: Jakarta Commons Developers List Subject: [VOTE] Release Commons Email 1.0 Since commons-email RC 1 there have been quite a few new release candidates. At this point ALL the bugs in Bugzilla have been dealt with. The code has been tagged as EMAIL_1_0_RC7 and differs from RC6 in some doc/code cleanup and minor refactoring. The binaries and docs are available from http://people.apache.org/ ~epugh/commons-email/ I have ignored the unit tests as they are currently failing due to some other reason on my box. They all pass cleanly on other Commons developer's boxes. This might be a good thing to double check. Votes, please. The vote will run for 72 hours. --8- [ ] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 Thanks! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail to [EMAIL PROTECTED] and delete the document. E-mails containing unprofessional, discourteous or offensive remarks violate Sentry policy. You may report employee violations by forwarding the message to [EMAIL PROTECTED] No recipient may use the information in this e-mail in violation of any civil or criminal statute. Sentry disclaims all liability for any unauthorized uses of this e-mail or its contents. This e-mail constitutes neither an offer nor an acceptance of any offer. No contract may be entered into by a Sentry employee without express approval from an authorized Sentry manager. Warning: Computer viruses can be transmitted via e-mail. Sentry accepts no liability or responsibility for any damage caused by any virus transmitted with this e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Email 1.0
Flatoff Allan [EMAIL PROTECTED] writes: It was/is available at http://jakarta.apache.org/commons/email/dependencies.html activation, commons-lang, javamail. dumbster is needed only for testing, not for using commons-email. Regards Henning Eric, What are the code dependencies of Email RC7 - Commons lang version? Etc. . Is it dependant on all current production releases - Or does it depend on other betas / release canditates. Sorry if this information is available elsewhere I just wouldn't know where to look Thanks, Allan -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 31, 2005 9:50 AM To: Jakarta Commons Developers List Subject: [VOTE] Release Commons Email 1.0 Since commons-email RC 1 there have been quite a few new release candidates. At this point ALL the bugs in Bugzilla have been dealt with. The code has been tagged as EMAIL_1_0_RC7 and differs from RC6 in some doc/code cleanup and minor refactoring. The binaries and docs are available from http://people.apache.org/ ~epugh/commons-email/ I have ignored the unit tests as they are currently failing due to some other reason on my box. They all pass cleanly on other Commons developer's boxes. This might be a good thing to double check. Votes, please. The vote will run for 72 hours. --8- [ ] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 Thanks! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail to [EMAIL PROTECTED] and delete the document. E-mails containing unprofessional, discourteous or offensive remarks violate Sentry policy. You may report employee violations by forwarding the message to [EMAIL PROTECTED] No recipient may use the information in this e-mail in violation of any civil or criminal statute. Sentry disclaims all liability for any unauthorized uses of this e-mail or its contents. This e-mail constitutes neither an offer nor an acceptance of any offer. No contract may be entered into by a Sentry employee without express approval from an authorized Sentry manager. Warning: Computer viruses can be transmitted via e-mail. Sentry accepts no liability or responsibility for any damage caused by any virus transmitted with this e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [VOTE] Release Commons Email 1.0
On 9/1/05, Eric Pugh [EMAIL PROTECTED] wrote: --8- [x] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons email 1.0
On Tue, 2005-03-08 at 22:13, Stephen Colebourne wrote: From: Eric Pugh [EMAIL PROTECTED] snip And, in the interests of finally getting a release out, especially since we have the required +1 votes, can I just add the file by hand? Icky, I know, but... As this is a 1.0, personally I'd prefer to see a clean (re)vote and release. +1 there are a lot of eyes on email at the moment so i'd guess that should be no problem getting the required number of votes. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
Okay...
I have fixed the NOTICE.txt in the jar at the top level not being in the
META-INF. However, I can't seem to get the NOTICE.txt in the top level
of either the src or binary distributions. The postGoal in commons
build here doesn't seem to run. No xdocs, no jars, no NOTICE.txt...:
postGoal name=dist:prepare-src-filesystem
j:set var=maven.dist.src.assembly.dir
value=${pom.getPluginContext('maven-dist-plugin').getVariable('maven.di
st.src.assembly.dir')} /
!-- Copy Files --
ant:copy todir=${maven.dist.src.assembly.dir}
ant:fileset dir=.
ant:include name=NOTICE.txt/
/ant:fileset
/ant:copy
!-- Copy Jars --
ant:copy todir=${maven.dist.src.assembly.dir}
ant:fileset dir=${maven.build.dir}
ant:include name=*.jar/
/ant:fileset
/ant:copy
!-- Copy XDocs --
ant:copy todir=${maven.dist.src.assembly.dir}/xdocs
ant:fileset dir=xdocs /
/ant:copy
/postGoal
To what extent is the NOTICE.txt a mandatory requriement? TO me, it
looks just like the LICENSE.txt...
And, in the interests of finally getting a release out, especially since
we have the required +1 votes, can I just add the file by hand? Icky, I
know, but...
Eric
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons email 1.0
From: Eric Pugh [EMAIL PROTECTED] To what extent is the NOTICE.txt a mandatory requriement? TO me, it looks just like the LICENSE.txt... The NOTICE.txt is the thing that specifies the Apache name. It is essential, and all releases must contain it in every jar, plus the top level of the src and bin zips. And, in the interests of finally getting a release out, especially since we have the required +1 votes, can I just add the file by hand? Icky, I know, but... As this is a 1.0, personally I'd prefer to see a clean (re)vote and release. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
I am using 1.8.1. However, I just found out that the darn jars aren't
supposed to be on ibiblio. I checked on the maven mailing list and
found out it was a problem. Silly me for bringing it up.. So now I
need to rollback to the older version.
Does the 1.9-SNAPSHOT help this situation of non redistributable jars?
Eric
-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 03, 2005 9:42 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [VOTE] Release commons email 1.0
Do you use the ant plugin 1.8.1 for maven or the 1.9-SNAPSHOT ?
Arnaud
-Message d'origine-
De : Eric Pugh [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 3 mars 2005 16:48
À : 'Jakarta Commons Developers List'
Objet : RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the
Maven Ant
plugin, it may be that the hand tweaking is no longer
required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I
am going to regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little
changes today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with
MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the
regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons email 1.0
With 1.9 the generated ant file allows the user to set itself the
dependency with a property.
I published the doc here :
http://www.apache.org/~brett/maven-stage-site/reference/plugins/ant/
You can try it :
maven plugin:download
-Dmaven.repo.remote=http://cvs.apache.org/repository
-DgroupId=maven
-DartifactId=maven-ant-plugin
-Dversion=SNAPSHOT
If you find a problem we can resolve them before the 1.9 release.
Arnaud
On Fri, 4 Mar 2005 08:59:50 -0800, Eric Pugh [EMAIL PROTECTED] wrote:
I am using 1.8.1. However, I just found out that the darn jars aren't
supposed to be on ibiblio. I checked on the maven mailing list and
found out it was a problem. Silly me for bringing it up.. So now I
need to rollback to the older version.
Does the 1.9-SNAPSHOT help this situation of non redistributable jars?
Eric
-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 03, 2005 9:42 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [VOTE] Release commons email 1.0
Do you use the ant plugin 1.8.1 for maven or the 1.9-SNAPSHOT ?
Arnaud
-Message d'origine-
De : Eric Pugh [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 3 mars 2005 16:48
À : 'Jakarta Commons Developers List'
Objet : RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the
Maven Ant
plugin, it may be that the hand tweaking is no longer
required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I
am going to regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little
changes today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with
MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the
regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the Maven Ant
plugin, it may be that the hand tweaking is no longer required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I am going to
regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little changes
today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the Maven Ant
plugin, it may be that the hand tweaking is no longer required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I am going to
regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little changes
today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
Do you use the ant plugin 1.8.1 for maven or the 1.9-SNAPSHOT ?
Arnaud
-Message d'origine-
De : Eric Pugh [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 3 mars 2005 16:48
À : 'Jakarta Commons Developers List'
Objet : RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the
Maven Ant
plugin, it may be that the hand tweaking is no longer
required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I
am going to regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little
changes today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with
MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the
regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons email 1.0
I'm +1! On Wed, 2 Mar 2005 09:27:28 -0800, Eric Pugh [EMAIL PROTECTED] wrote: The only open bug/enhancement is 32900: http://issues.apache.org/bugzilla/show_bug.cgi?id=32900. It is quite clearly an enhancement that is post 1.0, and there is some discussion on the bug list of whether it fits into the commons-email charter. Eric Pugh -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 3:24 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release commons email 1.0 Are there any open bugs/enhancements? On Tue, 1 Mar 2005 09:01:03 -0800, Eric Pugh [EMAIL PROTECTED] wrote: My +1 of course! [X] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
The only open bug/enhancement is 32900: http://issues.apache.org/bugzilla/show_bug.cgi?id=32900. It is quite clearly an enhancement that is post 1.0, and there is some discussion on the bug list of whether it fits into the commons-email charter. Eric Pugh -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 3:24 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release commons email 1.0 Are there any open bugs/enhancements? On Tue, 1 Mar 2005 09:01:03 -0800, Eric Pugh [EMAIL PROTECTED] wrote: My +1 of course! [X] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons email 1.0
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote: [X] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. BTW i've checked the sums and signatures - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons email 1.0
+1 modulo the following nits: * Binary distro includes NOTICE.txt in the jar (top level, should probably be with LICENSE.txt in META-INF) but not in the top level directory of the distribution. * Source distro does not include NOTICE.txt * Ant build.xml in source distro fails with MalformedURLException in get deps. When I regenerated the build.xml using maven ant, the regenerated build.xml worked. Could be build.xml is out of date? * Make sure to update the repo link on the web site to point to svn. Phil robert burrell donkin wrote: On Tue, 2005-03-01 at 06:58, Eric Pugh wrote: [X] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. BTW i've checked the sums and signatures - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons email 1.0
+1 (not a comitter) -CS On Mon, 28 Feb 2005 22:58:37 -0800, Eric Pugh [EMAIL PROTECTED] wrote: Hi all, The commons-email RC3 release has been available for a couple days, and has isn't fundamentally changed from the RC2 release that has been out for a couple months. I'd like to move to releasing the code here: http://www.apache.org/~epugh/email/distributions/ as commons-email-1.0. Documentation is available at http://www.apache.org/~epugh/email/docs/. Assuming this vote passes, my plan is to rename the jars, and then deploy them, as well as tag the 1.0 based on the RC3 tag in SVN. [ ] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons email 1.0
[X] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. Matthias thanks Eric! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
My +1 of course! [X] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons email 1.0
Are there any open bugs/enhancements? On Tue, 1 Mar 2005 09:01:03 -0800, Eric Pugh [EMAIL PROTECTED] wrote: My +1 of course! [X] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release commons email 1.0
Hi all, The commons-email RC3 release has been available for a couple days, and has isn't fundamentally changed from the RC2 release that has been out for a couple months. I'd like to move to releasing the code here: http://www.apache.org/~epugh/email/distributions/ as commons-email-1.0. Documentation is available at http://www.apache.org/~epugh/email/docs/. Assuming this vote passes, my plan is to rename the jars, and then deploy them, as well as tag the 1.0 based on the RC3 tag in SVN. [ ] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
