[Validator] RegExpr
Hey guys, is there any strong feeling from your side to switch the RegExpr. stuff to Java 1.4 ? Regards, matthias -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch?] feedparser (organizing imports)
Hi, I liked the remove unused import statements patch. How did you find this out? Did you use checkstyle or something? No. I used a feature from eclipse regarding that. I'm not sure about the generic import java.xxx.* removal. I prefer this style as it saves a LOT of time over worrying about which classes to import. yes yes :) I realize that some IDEs have support for just in time class import but I use Emacs which doesn't have that fancy feature ;) Would you be interested in separating the patches? I'd like to accept the remove unnecessary imports code. separating means? one patch per clazz or per package ? -Matthias Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: feedparser 0.5.0 RC1
Ok, is there any result on this issue? I played a bit with [feedparser] and it works for me ;) So +1 for rc1 But needs lot of JARs... ;-( -Matthias Kevin A. Burton wrote: (Sent this out on Friday but it looks like it bounced... ) OK. I took the time tonight and made an FeedParser 0.5.0 RC1 available for testing: http://apache.org/~burton/ http://apache.org/~burton/commons-feedparser-0.5-beta.tar.gz This is our initial release and on Monday I'll probably cut 0.5.0 final assuming there are no objections. http://jakarta.apache.org/commons/feedparser/ Since this is a first release a changelog doesn't really apply. One thing to note is that this includes Brad's RSS feed location bugfixes. The current release plan to 1.0 is to release 0.5.0 as a initial release. I'll probably want to do a 0.6.0 release right after this with some refactoring and commons-benchmark. Then I want to release a FeedParser 1.0 as the code is really solid. Thanks! Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: feedparser 0.5.0 RC1
I'm working on the Needs a lot of jars issue :) cool ;) I didn't get any -1s so I assume its a go. The big issue is that I just haven't had time to do the release... ok... next week I can help, if you want; (being Apache committer (matzew)) this week some other issue are on my plate! -Matthias Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Feedparser] dependencies of JARs
Hi, I just saw on [1] that [feedparser] depends on lot's of JARs are all of them really needed to run applications, based upon [feedparser] ? Thanks, Matthias [1] http://jakarta.apache.org/commons/sandbox/feedparser/dependencies.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Feedparser] NoClassDefFoundError
Hi, when I start the HelloFeedParser sample, I got: NoClassDefFoundError: org/saxpath/SAXPathException (see below) I loaded the *binary* from http://apache.org/~burton/ here is the SRC of my HelloFeedParser: http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/feedparser/src/java/org/apache/commons/feedparser/example/HelloFeedParser.java?rev=1.1view=markup In clazzpath I have: -commons-feedparser-0.5-beta.jar -commons-httpclient-3.0-rc1.jar -jdom-b10.jar -junit-3.8.1.jar -log4j-1.2.8.jar -xerces-2.0.2.jar -xml-apis-2.0.2.jar -xmlrpc-1.2-b1.jar -jaxen-full.jar OR!!! jaxen-1.1-beta-4.jar like suggested on [feedparser] dependency list Did I miss something? -Matthias snip org.apache.commons.feedparser.FeedParserException: java.lang.NoClassDefFoundError: org/saxpath/SAXPathException at org.apache.commons.feedparser.FeedParserImpl.parse(FeedParserImpl.java:191) at org.apache.commons.feedparser.FeedParserImpl.parse(FeedParserImpl.java:75) at org.apache.commons.feedparser.FeedParserImpl.parse(FeedParserImpl.java:135) at HelloFeedParser.main(HelloFeedParser.java:55) Caused by: java.lang.NoClassDefFoundError: org/saxpath/SAXPathException at org.apache.commons.feedparser.RSSFeedParser.parse(RSSFeedParser.java:63) at org.apache.commons.feedparser.FeedParserImpl.parse(FeedParserImpl.java:185) ... 3 more /snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [email] promote RC4 to 1.0 status
-8- [X] +1 Promote RC4 to commons-email-1.0 [ ] +0 In favour of this release [ ] -0 Against this release [ ] -1 Do not release RC4 Thanks Eric! Eric Pugh wrote: Hi all, A couple of packaging issues were discovered in Email 1.0 RC3. I was encouraged to fix them and then call for a fresh vote, so I appreciate the understanding of the community that the (now) 4 release candidates it's taken to get email to 1.0. My first time signing a project. The release candidate is available at http://www.apache.org/~epugh/email/distributions/ and is just RC3 with some packaging tweaks, not Java code changes. The documentation is available at http://www.apache.org/~epugh/email/docs This is a full release vote (and so three +1's are required). please check the release before voting +1. i will not tally the votes before 2300 hours GMT on Tuesday 15th of March. here's my +1 - Eric -8- [ ] +1 Promote RC4 to commons-email-1.0 [ ] +0 In favour of this release [ ] -0 Against this release [ ] -1 Do not release RC4 - 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] -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany phone: +49-2572-9170275 cell phone: +49-179-1118979 email: matzew AT apache DOT org url: http://www.wessendorf.net callto://mwessendorf (Skype) icq: 47016183 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: feedparser 0.5.0 RC1
Kevin, please do a chmod on the files: Forbidden You don't have permission to access /~burton/commons-feedparser-0.5-beta.tar.gz on this server. Apache/2.0.53 (Unix) Server at apache.org Port 80 :-) Kevin A. Burton wrote: OK. I took the time tonight and made an FeedParser 0.5.0 RC1 available for testing: http://apache.org/~burton/ http://apache.org/~burton/commons-feedparser-0.5-beta.tar.gz This is our initial release and on Monday I'll probably cut 0.5.0 final assuming there are no objections. http://jakarta.apache.org/commons/feedparser/ Since this is a first release a changelog doesn't really apply. One thing to note is that this includes Brad's RSS feed location bugfixes. The current release plan to 1.0 is to release 0.5.0 as a initial release. I'll probably want to do a 0.6.0 release right after this with some refactoring and commons-benchmark. Then I want to release a FeedParser 1.0 as the code is really solid. Thanks! Kevin -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany phone: +49-2572-9170275 cell phone: +49-179-1118979 email: matzew AT apache DOT org url: http://www.wessendorf.net callto://mwessendorf (Skype) icq: 47016183 - 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: [Email] To release or not to release
) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTe stRunner.java:325) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnit Task.java:848) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask .java:556) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask .java:532) at org.apache.tools.ant.Task.perform(Task.java:341) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.j ava:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAc tion(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:616 ) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:486) at org.apache.maven.cli.App.main(App.java:1215) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: javax.mail.NoSuchProviderException: smtp at javax.mail.Session.getService(Session.java:750) at javax.mail.Session.getTransport(Session.java:689) at javax.mail.Session.getTransport(Session.java:632) at javax.mail.Session.getTransport(Session.java:612) at javax.mail.Session.getTransport(Session.java:667) at javax.mail.Transport.send0(Transport.java:148) at javax.mail.Transport.send(Transport.java:80) at org.apache.commons.mail.Email.send(Email.java:821) ... 44 more [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 0,541 sec [junit] [ERROR] TEST org.apache.commons.mail.SimpleEmailTest FAILED jar:jar: [jar] Building jar: C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\email\target\common s-email-1.0.jar Copying: from 'C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\email\target\commo ns-email-1.0.jar' to: 'C:\Dokumente und Einstellungen\Administrator\.maven\repository\commons-email\jars\commons -email-1.0.jar' Copying: from 'C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\email\project.xml' to: 'C:\Dokumente und Einstellungen\Administrator\.maven\repository\commons-email\poms\commons -email-1.0.pom' BUILD SUCCESSFUL Total time: 1 minutes 13 seconds Finished at: Thu Jan 20 10:03:52 CET 2005 -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 18, 2005 2:58 PM To: Matthias Wessendorf; 'Jakarta Commons Developers List' Subject: RE: [Email] To release or not to release At 10:04 AM +0100 1/18/05, Matthias Wessendorf wrote: h..., I just set up my box. checked out [email] but build fails because of the old story regarding download of javamail I run maven jar:install I have forgotten, what to do... After all works (again) for me, I will do produce and signing the release, since I have commit priviledg. You need to do one of two things: 1) manually install the JARs where Maven wants them
[commons-el] new release?
Hi folks, on your project site the last release is from 2003. There are some changes in CVS that aren't reflected by the shipped JAR. eg. Logger replaced by [commons-logging] eg. Coercions' methods refactored... Do you plan to roll out a new release? That contains these changes? Thanks, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Email] To release or not to release
h..., I just set up my box. checked out [email] but build fails because of the old story regarding download of javamail I run maven jar:install I have forgotten, what to do... After all works (again) for me, I will do produce and signing the release, since I have commit priviledg. Thanks! -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Monday, January 17, 2005 4:20 PM To: 'Jakarta Commons Developers List'; 'Dion Gillard' Subject: RE: [Email] To release or not to release +1 -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Monday, January 17, 2005 11:32 AM To: Jakarta Commons Developers List; Corey Scott Subject: Re: [Email] To release or not to release I'm +1. On Mon, 17 Jan 2005 17:12:20 +0800, Corey Scott [EMAIL PROTECTED] wrote: Can someone with commit priviledge please change email over from RC1 to v.1.0? The RC has been out for quite a while now and so far there are no complaints about this. There are several other things waiting for this release, e.g. a proposed change to the jelly email classes (change to Commons Email) and some proposed extensions to Email itself, so completing the release would be greatly appreciated. Many Thanks, Corey - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Email] To release or not to release
+1 -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Monday, January 17, 2005 11:32 AM To: Jakarta Commons Developers List; Corey Scott Subject: Re: [Email] To release or not to release I'm +1. On Mon, 17 Jan 2005 17:12:20 +0800, Corey Scott [EMAIL PROTECTED] wrote: Can someone with commit priviledge please change email over from RC1 to v.1.0? The RC has been out for quite a while now and so far there are no complaints about this. There are several other things waiting for this release, e.g. a proposed change to the jelly email classes (change to Commons Email) and some proposed extensions to Email itself, so completing the release would be greatly appreciated. Many Thanks, Corey - 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]
[solved] [GUMP@brutus]: Project commons-email (in module jakarta-commons) failed
Hi, I included a patch (http://issues.apache.org/bugzilla/show_bug.cgi?id=32889) now there are e.g two setTo() methods in Email.java: -setTo(java.util.Collection); -setTo(java.lang.String[]); So it bounces inside of EmailTest.java I first removed the patch. All is fine now... again... Btw. I will refactor the EmailTest.java and Email.java so that the patch works. Sorry for bothering, but I fogot to run the tests on my box... Matthias -Original Message- From: dIon Gillard [mailto:[EMAIL PROTECTED] Sent: Saturday, January 15, 2005 10:17 AM To: commons-dev@jakarta.apache.org Subject: [EMAIL PROTECTED]: Project commons-email (in module jakarta-commons) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-email has an issue affecting its community integration. This issue affects 6 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package - fulcrum-intake : Services Framework - fulcrum-security-adapter-turbine : Services Framework - fulcrum-template : Services Framework - jakarta-jetspeed : Enterprise Information Portal - jakarta-turbine-2 : A servlet based framework. Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-e mail/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-email-15012005.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons/email/build.p roperties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons/email/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons/email/project .properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-e mail/gump_work/build_jakarta-commons_commons-email.html Work Name: build_jakarta-commons_commons-email (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/email] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jak arta-commons/target/classes:/usr/local/gump/public/workspace/a nt/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/d ist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dis t/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace /ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/an t/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/ dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant /dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/ dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/j unit.jar:/usr/local/gump/public/workspace/xml-commons/java/bui ld/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap /lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/boo tstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-co mmons/lang/dist/commons-lang-15012005.jar:/usr/local/gump/publ ic/workspace/dumbster/build/dumbster.jar:/usr/local/gump/packa ges/javamail-1.3.2/mail.jar:/usr/local/gump/packages/javamail- 1.3.2/lib/mailapi.jar:/usr/local/gump/packages/jaf-1.0.1/activ ation.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 Plugin 'maven-deploy-plugin' in project 'Commons Email' is not available build:start: java:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons/email/ target/classes java:compile: [echo] Compiling to /home/gump/workspaces2/public/workspace/jakarta-commons/email/ target/classes [javac] Compiling 8 source files to /home/gump/workspaces2/public/workspace/jakarta-commons/email/ target/classes java:jar-resources: Copying 1 file to /home/gump/workspaces2/public/workspace/jakarta-commons/email/ target/classes test:prepare-filesystem: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons/email/ target/test-classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/jakarta-commons/email/ target/test-reports test:test-resources: test:compile: [javac] Compiling 13 source files to
RE: [feedparser] problems
I noticed some new activity on [feedparser]. But some problems I mentioned in this email are still existing. Any thoughts? Thanks! Matthias -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 5:45 PM To: commons-dev@jakarta.apache.org Subject: [feedparser] problems Hi all, I loaded [feedparser] and saw, that inside of package org.apache.commons.feedparser.post are clazzes with package-declaration org.apache.commons.feedparser see: http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/feed parser/src /java/org/apache/commons/feedparser/post/MetaWeblogPostAgent.j ava?rev=1. 1view=auto Also I saw usage of org.apache.xmlrpc.* (http://ws.apache.org/xmlrpc/) but maven-dependency tells nothing on XML-RPC... see: http://jakarta.apache.org/commons/sandbox/feedparser/dependencies.html Btw, I couldn't run Maven. I tried maven jar but not success. see log below. Anybody still working on feedparser? Thanks, Matthias C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparsermaven jar __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc4 Plugin 'maven-deploy-plugin' in project 'Commons Feedparser' is not available build:start: java:prepare-filesystem: java:compile: [echo] Compiling to C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\fee dparser/target/classes [javac] Compiling 81 source files to C:\Programme\eclipse-SDK-3.0-win32\ecli pse\workspace\feedparser\target\classes C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\FeedParser.java:35: package org.apache.log4j does not exi st import org.apache.log4j.Logger; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\FeedParser.java:48: cannot resolve symbol symbol : class Logger location: class org.apache.commons.feedparser.FeedParser private static Logger log = Logger.getLogger( FeedParser.class ); ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\locate\FeedLocator.java:21: package org.peerfear.newsmons ter.network does not exist import org.peerfear.newsmonster.network.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\locate\FeedLocator.java:25: package org.apache.log4j does not exist import org.apache.log4j.Logger; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\locate\FeedLocator.java:47: cannot resolve symbol symbol : class Logger location: class org.apache.commons.feedparser.locate.FeedLocator private static Logger log = Logger.getLogger( FeedLocator.class ); ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\locate\ProbeLocator.java:22: package org.peerfear.newsmon ster.network does not exist import org.peerfear.newsmonster.network.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\locate\ProbeLocator.java:26: package org.apache.log4j doe s not exist import org.apache.log4j.Logger; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\locate\ProbeLocator.java:42: cannot resolve symbol symbol : class Logger location: class org.apache.commons.feedparser.locate.ProbeLocator private static Logger log = Logger.getLogger( ProbeLocator.class ); ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\post\MetaWeblogPostAgent.java:25: package org.apache.xmlr pc does not exist import org.apache.xmlrpc.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\test\TestAtom.java:32: package org.peerfear.newsmonster.t ools does not exist import org.peerfear.newsmonster.tools.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\test\TestAtom.java:33: package org.peerfear.newsmonster.n etwork does not exist import org.peerfear.newsmonster.network.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\test\TestFeedFilter.java:32: package org.peerfear.newsmon ster.tools does not exist import org.peerfear.newsmonster.tools.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparse r\src\java \org\apa che\commons\feedparser\test\TestFeedFilter.java:33: package org.peerfear.newsmon ster.network does not exist
[feedparser] problems
Hi all, I loaded [feedparser] and saw, that inside of package org.apache.commons.feedparser.post are clazzes with package-declaration org.apache.commons.feedparser see: http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/feedparser/src /java/org/apache/commons/feedparser/post/MetaWeblogPostAgent.java?rev=1. 1view=auto Also I saw usage of org.apache.xmlrpc.* (http://ws.apache.org/xmlrpc/) but maven-dependency tells nothing on XML-RPC... see: http://jakarta.apache.org/commons/sandbox/feedparser/dependencies.html Btw, I couldn't run Maven. I tried maven jar but not success. see log below. Anybody still working on feedparser? Thanks, Matthias C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparsermaven jar __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc4 Plugin 'maven-deploy-plugin' in project 'Commons Feedparser' is not available build:start: java:prepare-filesystem: java:compile: [echo] Compiling to C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\fee dparser/target/classes [javac] Compiling 81 source files to C:\Programme\eclipse-SDK-3.0-win32\ecli pse\workspace\feedparser\target\classes C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\FeedParser.java:35: package org.apache.log4j does not exi st import org.apache.log4j.Logger; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\FeedParser.java:48: cannot resolve symbol symbol : class Logger location: class org.apache.commons.feedparser.FeedParser private static Logger log = Logger.getLogger( FeedParser.class ); ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\locate\FeedLocator.java:21: package org.peerfear.newsmons ter.network does not exist import org.peerfear.newsmonster.network.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\locate\FeedLocator.java:25: package org.apache.log4j does not exist import org.apache.log4j.Logger; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\locate\FeedLocator.java:47: cannot resolve symbol symbol : class Logger location: class org.apache.commons.feedparser.locate.FeedLocator private static Logger log = Logger.getLogger( FeedLocator.class ); ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\locate\ProbeLocator.java:22: package org.peerfear.newsmon ster.network does not exist import org.peerfear.newsmonster.network.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\locate\ProbeLocator.java:26: package org.apache.log4j doe s not exist import org.apache.log4j.Logger; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\locate\ProbeLocator.java:42: cannot resolve symbol symbol : class Logger location: class org.apache.commons.feedparser.locate.ProbeLocator private static Logger log = Logger.getLogger( ProbeLocator.class ); ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\post\MetaWeblogPostAgent.java:25: package org.apache.xmlr pc does not exist import org.apache.xmlrpc.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\test\TestAtom.java:32: package org.peerfear.newsmonster.t ools does not exist import org.peerfear.newsmonster.tools.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\test\TestAtom.java:33: package org.peerfear.newsmonster.n etwork does not exist import org.peerfear.newsmonster.network.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\test\TestFeedFilter.java:32: package org.peerfear.newsmon ster.tools does not exist import org.peerfear.newsmonster.tools.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\test\TestFeedFilter.java:33: package org.peerfear.newsmon ster.network does not exist import org.peerfear.newsmonster.network.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\test\TestFeedLocator.java:32: package org.peerfear.newsmo nster.tools does not exist import org.peerfear.newsmonster.tools.*; ^ C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\feedparser\src\java \org\apa che\commons\feedparser\test\TestFeedLocator.java:33: package org.peerfear.newsmo nster.network does not exist import org.peerfear.newsmonster.network.*; ^
[feedparser] nightly build
Hi all, is there a plan to [feedparser] (from sandbox) to nightly build? Best regards Mit freundlichen Grüßen -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][EMAIL] Release Commons-Email 1.0
--- [X] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Friday, December 03, 2004 6:09 PM To: Commons-Dev Subject: [VOTE][EMAIL] Release Commons-Email 1.0 Dear community, Commons Email is now ready for release. The code is stable, all bugs fixed, and the unit tests all run. Additionally the various licensing issues with the Sun jars and Dumbster have been resolved. I have created Release Candidate 1 distributions using Maven dist, they are available here: http://www.apache.org/ ~epugh/email/distributions and the site docs are available at http://www.apache.org/~epugh/email/docs. Votes, please. Voting will last at least 72 hours. Thanks. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my +1. Eric - 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]
[email] kama
could anyone add kama for [email] to my Apache account? (matzew) Btw. I am in jakarta-UNIX-Group on c.a.o However, I had had kama for [email] since it was in sandbox. I would like to apply patches, that the tests are runing on unix-systems. Thanks! Best regards Mit freundlichen Grüßen -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matzew AT apache DOT org URL: http://www.wessendorf.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] website
Hi all, the old [email]-site (http://jakarta.apache.org/commons/sandbox/email/) has a nice layout. but the new has an ugly layout: http://jakarta.apache.org/commons/email/ Best regards Mit freundlichen Grüßen -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/email - Imported sources
cool! Eric, I just *surfed* cvs, we lost the cvs-log from sandbox, isn't it? -Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 12:10 PM To: Jakarta Commons Developers List; Mark Lowe Subject: RE: cvs commit: jakarta-commons/email - Imported sources Yup.. the notice will go out later when I get the site up.. -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 11:14 AM To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta-commons/email - Imported sources Does that mean its promoted and worth sumbmitting patches again? On 25 Nov 2004 09:56:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: epugh 2004/11/25 01:56:57 Log: import commons email to commons prope CV:: -- Status: Vendor Tag: commons_sandbox Release Tags: commons_promotion N jakarta-commons/email/.cvsignore N jakarta-commons/email/LICENSE.txt N jakarta-commons/email/README.txt N jakarta-commons/email/STATUS.html N jakarta-commons/email/maven.xml N jakarta-commons/email/project.properties N jakarta-commons/email/project.xml N jakarta-commons/email/build.xml N jakarta-commons/email/NOTICE.txt N jakarta-commons/email/build.properties.sample N jakarta-commons/email/src/java/org/apache/commons/mail/DefaultAuth enticator.java N jakarta-commons/email/src/java/org/apache/commons/mail/Email.java N jakarta-commons/email/src/java/org/apache/commons/mail/EmailAttach ment.java N jakarta-commons/email/src/java/org/apache/commons/mail/HtmlEmail.java N jakarta-commons/email/src/java/org/apache/commons/mail/MultiPartEmail. java N jakarta-commons/email/src/java/org/apache/commons/mail/SimpleEmail.jav a N jakarta-commons/email/xdocs/downloads.xml N jakarta-commons/email/xdocs/examples.xml N jakarta-commons/email/xdocs/index.xml N jakarta-commons/email/xdocs/navigation.xml N jakarta-commons/email/xdocs/changes.xml No conflicts created by this import - 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: cvs commit: jakarta-commons/email - Imported sources
No idea, as we moved (MyFaces) from SF to Apache. I loaded a tar-ball did local cvs (on my box) renamed the packages and removed the sf-links. after that I checked it in localy. created a Tar-ball for the new. That guy was imported to apache cvs by the incubator-guys, I guess. BTW. perhaps you saw my accident yesterday. I saw some clazzes without @version etc. I submitted by accident $LOG (for CVS) I guess it is not common inside of Jakarta? In myFaces we still use this feature. Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 1:13 PM To: Matthias Wessendorf Cc: Commons-Dev Subject: RE: cvs commit: jakarta-commons/email - Imported sources Possibly.. I just followed the directions in the wiki. I also didn't manage to import properly the /src/test tree and the /xdocs/ tree as well. Not sure why. The cvs-log should still be in the jakarta-commons-sandbox project, correct? Eric -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 12:22 PM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: RE: cvs commit: jakarta-commons/email - Imported sources cool! Eric, I just *surfed* cvs, we lost the cvs-log from sandbox, isn't it? -Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 12:10 PM To: Jakarta Commons Developers List; Mark Lowe Subject: RE: cvs commit: jakarta-commons/email - Imported sources Yup.. the notice will go out later when I get the site up.. -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 11:14 AM To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta-commons/email - Imported sources Does that mean its promoted and worth sumbmitting patches again? On 25 Nov 2004 09:56:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: epugh 2004/11/25 01:56:57 Log: import commons email to commons prope CV:: -- Status: Vendor Tag: commons_sandbox Release Tags: commons_promotion N jakarta-commons/email/.cvsignore N jakarta-commons/email/LICENSE.txt N jakarta-commons/email/README.txt N jakarta-commons/email/STATUS.html N jakarta-commons/email/maven.xml N jakarta-commons/email/project.properties N jakarta-commons/email/project.xml N jakarta-commons/email/build.xml N jakarta-commons/email/NOTICE.txt N jakarta-commons/email/build.properties.sample N jakarta-commons/email/src/java/org/apache/commons/mail/DefaultAuth enticator.java N jakarta-commons/email/src/java/org/apache/commons/mail/Email.java N jakarta-commons/email/src/java/org/apache/commons/mail/EmailAttach ment.java N jakarta-commons/email/src/java/org/apache/commons/mail/HtmlEmail.jav a N jakarta-commons/email/src/java/org/apache/commons/mail/MultiPartEmai l. java N jakarta-commons/email/src/java/org/apache/commons/mail/SimpleEmail.j av a N jakarta-commons/email/xdocs/downloads.xml N jakarta-commons/email/xdocs/examples.xml N jakarta-commons/email/xdocs/index.xml N jakarta-commons/email/xdocs/navigation.xml N jakarta-commons/email/xdocs/changes.xml No conflicts created by this import - 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: cvs commit: jakarta-commons/email - Imported sources
Probably you are using Subversion and not CVS for Myfaces, so it ran through cvs2svn which preserved history. no, we are using CVS. cvs import doesn't preserve history. If you wanted to do that, you'd have to move the *,v files of the server around (which you did in the MyFaces case). yes, thats true! I submitted by accident $LOG (for CVS) I guess it is not common inside of Jakarta? I've never seen any Apache code base use it, but that doesn't mean much. I personally don't like it, but its a matter of taste. I can understand that point! ;-) Matthias Stefan - 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 Validator 1.1.4
I used 1.1.4 inside of Apache MyFaces. works well! However, here is my +1 REgards, Matthias -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 10:10 AM To: Commons Developers Jakarta Subject: [VOTE] Release Validator 1.1.4 The release candidate has been available for a week now with no problems reported. This is a very minor maintenance release (adding four missing getters/setters missing from Version 1.1.3) . The new version will enable a number of Struts bugzilla tickets to be resolved. The plan is to cut the Validator 1.1.4 release from the VALIDATOR_1_1_2_BRANCH (VALIDATOR_1_1_2_BRANCH is for the 1.1.x series and HEAD contains the 2.x series) on completion of a successful vote. Here's my +1 Niall --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- - 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: [GUMP@brutus]: Project commons-email (in module jakarta-commons-sandbox) failed
Craig, I haven't looked at the sources for the tests, but if you are trying to start a dummy email server on a port 1024, this is guaranteed to fail (unless you are running as root) on any Unix platform, which is definitely the case for the nightly builds (Red Hat Linux 9.0). thanks for pointig this out. I just remember ;-) the failure reported by was because of a typo (assertTrue(this.fakeMailServer.getReceivedEmailSize() = intMsgNo);) was fixed by Eric on my box it also fails (JUNIT) :-( test:test: [junit] Running org.apache.commons.mail.DefaultAuthenticatorTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,08 sec [junit] Running org.apache.commons.mail.EmailAttachmentTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 4,667 sec [junit] Running org.apache.commons.mail.EmailTest [junit] Tests run: 36, Failures: 0, Errors: 0, Time elapsed: 2,744 sec [junit] Running org.apache.commons.mail.HtmlEmailTest java.net.BindException: Address already in use: JVM_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(Unknown Source) at java.net.ServerSocket.bind(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at com.dumbster.smtp.SimpleSmtpServer.run(Unknown Source) at java.lang.Thread.run(Unknown Source) java.net.BindException: Address already in use: JVM_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(Unknown Source) at java.net.ServerSocket.bind(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at com.dumbster.smtp.SimpleSmtpServer.run(Unknown Source) at java.lang.Thread.run(Unknown Source) [junit] Tests run: 6, Failures: 2, Errors: 0, Time elapsed: 3,605 sec [junit] [ERROR] TEST org.apache.commons.mail.HtmlEmailTest FAILED [junit] Running org.apache.commons.mail.MultiPartEmailTest java.net.BindException: Address already in use: JVM_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(Unknown Source) at java.net.ServerSocket.bind(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at com.dumbster.smtp.SimpleSmtpServer.run(Unknown Source) at java.lang.Thread.run(Unknown Source) [junit] Tests run: 10, Failures: 1, Errors: 0, Time elapsed: 2,704 sec [junit] [ERROR] TEST org.apache.commons.mail.MultiPartEmailTest FAILED [junit] Running org.apache.commons.mail.SendWithAttachmentsTest [junit] Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 8,231 sec [junit] [ERROR] TEST org.apache.commons.mail.SendWithAttachmentsTest FAILED [junit] Running org.apache.commons.mail.SimpleEmailTest java.net.BindException: Address already in use: JVM_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(Unknown Source) at java.net.ServerSocket.bind(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at java.net.ServerSocket.init(Unknown Source) at com.dumbster.smtp.SimpleSmtpServer.run(Unknown Source) at java.lang.Thread.run(Unknown Source) [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 0,67 sec [junit] [ERROR] TEST org.apache.commons.mail.SimpleEmailTest FAILED jar:jar: [jar] Building jar: C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\email\target\common s-email-1.0-dev.jar Copying: from 'C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\email\target\commo ns-email-1.0-dev.jar' to: 'C:\Dokumente und Einstellungen\Administrator\.maven\repository\commons-email\jars\commons -email-1.0-dev.jar' Copying: from 'C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\email\project.xml' to: 'C:\Dokumente und Einstellungen\Administrator\.maven\repository\commons-email\poms\commons -email-1.0-dev.pom' BUILD SUCCESSFUL -Matthias Craig McClanahan On Wed, 24 Nov 2004 00:57:45 PST, dIon Gillard [EMAIL PROTECTED] wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-email has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-e mail/index.html That said, some
[Email] nightly builds
Hi all, I just saw, that the nightly build of [email] is empty. Did I miss something? Regards, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Email to Commons Proper
cool, thanks Emmanuel. Eric will this be the last step for leaving sandbox? Regards, Matthias -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Sunday, November 21, 2004 3:48 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: [VOTE] Promote Email to Commons Proper I prepared a bundle for dumbster on codehaus. It will be synchronize with ibiblio in few hours. Emmanuel - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Friday, November 19, 2004 5:26 AM Subject: Re: [VOTE] Promote Email to Commons Proper Impressively, Jason has now updated the SF site, the Dumbster site and released a new version under the ASL 2.0. All that remains is to get it into Maven, and I figure that one of the [email] guys can happily do that (there are instructions on the Maven site for it). So nothing looks likely to slow down a release, and many kudos to Jason Kitchen for being so responsive to our legal particulars. Hen On Thu, 18 Nov 2004 19:57:09 +, robert burrell donkin [EMAIL PROTECTED] wrote: On 18 Nov 2004, at 11:39, Eric Pugh wrote: Alright.. This thread has somewhat gotton away from me. Since Dumbster is now licensed as ASL (despite the website being out of date), can we move to a conclusion on this thread? If we consider that [email] hasn't materially changed, and therefore a new vote isn't required, then I currently tally: +1 Eric Pugh +1 Matthias Wessendorf +1 Yoav Shapira Robert, you raised the original lgpl issue which I hope is now sorted out. While you didn't specifically put a -1 down, I think it was implied. Would you be willing to change that to something else? i'm now +1 to promotion (and like henri -1 to release until all the loose ends concerning the dumbster license) i would like to see a note added to the web site recommending the latest (ASF licensed) dumbster. i'd also like to see a new version of dumbster (with an ASL license) uploaded to the maven java repository and the project.xml updated to reflect that. - 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] Promote Email to Commons Proper
Henri, +1 to promotion to Commons proper. -1 to release until the dumbster site and release we are dependent on is on a license we can use. release is still ASL (see cvs): http://cvs.sourceforge.net/viewcvs.py/dumbster/dumbster/src/com/dumbster /smtp/SimpleSmtpServer.java?rev=1.3view=auto Regards, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Email to Commons Proper
Corey, yes you are right, main motivation is getting [email] out of sandbox :-) your #1 should be the easiest way. Btw. do you know if the JAMES-folks have a facility like dumbster? Regards, Matthias -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 8:14 AM To: Jakarta Commons Developers List Subject: Re: [VOTE] Promote Email to Commons Proper So back to the original problem. Dumbster is currently used by the tests. The way I see it this leaves us with a few options: 1) Remove it (and wait for the ok or change of license 2) Replace it (I havent seen an alternative, but I am willing to look) 3) Do it ourselves. To be honest, my main motivation is just to get Email promoted and moving. That said, after using dumbster for a while I have found it to be a good idea, although I find the implementation to be quite limited. As it also seems to be a one man show, the likelihood of it progressing to far, is low. For this reason, I would like to test the water a suggest, what does everything think about doing a similar component and putting it the sandbox? For my mind, this would help us immensely, we could shape the component so that is was more agreeable to what we are trying to test and ensure that a user was able to retrieve a decent amount of info from the 'sent' mails, as this is a lacking at the moment. I am willing to work on this, but I will need someone to help me champion it and CVS committer. -Corey - 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] Promote Email to Commons Proper
ah, now I read the rest, well doing such a component is a nice thing. since unit-tests for [email] are a plus. well I don't know how to promote such a component to sandbox, perhaps eric knows more? I guess must post some code, that you will push to Jakarta Commons Sandbox. After that, there will be a vote for adding it to Sandbox? Just my personal thoughts. Since I haven't started an own project in ASF/Jakarta. With MyFaces (JSF-Implementation) it was different, we had code in SF.net. Asked the incubator-folks. After that we droped LGPL and used Apache2.0 Then the way was ready to start in ASF. Incubator-folks voted us to be on board. -Matthias -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 8:14 AM To: Jakarta Commons Developers List Subject: Re: [VOTE] Promote Email to Commons Proper So back to the original problem. Dumbster is currently used by the tests. The way I see it this leaves us with a few options: 1) Remove it (and wait for the ok or change of license 2) Replace it (I havent seen an alternative, but I am willing to look) 3) Do it ourselves. To be honest, my main motivation is just to get Email promoted and moving. That said, after using dumbster for a while I have found it to be a good idea, although I find the implementation to be quite limited. As it also seems to be a one man show, the likelihood of it progressing to far, is low. For this reason, I would like to test the water a suggest, what does everything think about doing a similar component and putting it the sandbox? For my mind, this would help us immensely, we could shape the component so that is was more agreeable to what we are trying to test and ensure that a user was able to retrieve a decent amount of info from the 'sent' mails, as this is a lacking at the moment. I am willing to work on this, but I will need someone to help me champion it and CVS committer. -Corey - 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] Promote Email to Commons Proper
Serge, http://quintanasoft.com/dumbster/ faking SMTP ;-) Regards, Matthias -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 9:54 AM To: Jakarta Commons Developers List Subject: Re: [VOTE] Promote Email to Commons Proper Matthias Wessendorf wrote: your #1 should be the easiest way. Btw. do you know if the JAMES-folks have a facility like dumbster? Sorry, what is dumbster? -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [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] Promote Email to Commons Proper
yeah Mark, nice deal! I also just surfed to sf.net and figured out email-address of jasionkitchen ;-) so back to vote! ;-) -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Promote Email to Commons Proper
Rory, well the project pages tell you GPL... http://sourceforge.net/projects/dumbster/ cheers! -Original Message- From: Rory Winston [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 2:02 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Promote Email to Commons Proper I had a peek on SF, and it looks like the developer has changed the license now: http://cvs.sourceforge.net/viewcvs.py/dumbster/dumbster/license.txt?rev= 1.2view=auto Cheers, Rory Matthias Wessendorf wrote: yeah Mark, nice deal! I also just surfed to sf.net and figured out email-address of jasionkitchen ;-) so back to vote! ;-) -Matthias - 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] Promote Email to Commons Proper
+1 Email is indeed a nice *component*, that simplifies the JavaMail-Api. -Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 12:10 PM To: Commons-Dev Subject: [VOTE] Promote Email to Commons Proper Email exhibits all of the qualities of a component that should be in Commons proper: - It's small and focused. - It's API is well defined - It has good unit test coverage. It has also been tested in real world email applications (Turbine 2.3, 2.4, 3.0, Scarab). - It has automated nightly builds, website, and Maven all working - It has incubated in the sandbox for long enough to become stable (97% Jcoverage!) Email is a mature component that should move to Commons proper so it can be released to the public. Here's my +1. The website has additional information: http://jakarta.apache.org/commons/sandbox/email/index.html Here's the component proposal for reference: (1) INTRODUCTION The Email Component contains a set of Java classes providing a thin convenience layer over JavaMail. (2) DEPENDENCIES The Email component is dependent upon the following external components for development and use: * Java Development Kit (Version 1.2 or later) * JavaMail . (Version 1.2 or later) * JavaBeans Activation Framework (Version 1.0.1 or later) - dependency of JavaMail. * JUnit Testing Framework (Version 3.7 or later) - for unit tests only, not required for deployment * Dumbster Fake SMTP (Version 1.0.3 or later) - for unit tests only, not required for deployment (3) Required Jakarta-Commons Resources CVS Repository - New directory email in the jakarta-commons CVS repository. Mailing List - Discussions will take place on the general commons-dev mailing list. To help list subscribers identify messages of interest, it is suggested that the message subject of messages about this component be prefixed with [email]. Bugzilla - New component Email under the Commons product category, with appropriate version identifiers as needed. (4) Initial Committers The initial committers on the DBUtils component shall be: * Eric Pugh (Commons Committer) * Joe Germuska (Commons Sandbox Committer) Current active contributors include: * Corey Scott * Mark Lowe - 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]
Validator inside of Email.java (RE: [email] Dumbster failing)
Hi Eric, I just update my email sources. and looked abit on the patches you are submitting. Cool to have some unittest. Btw. I saw that EmailValidator of Commons Validator is used inside of Email.java; Does it realy make sence to validate an e-mail inside that class? shouldn't this work be done outside? eg. enter e-mail via Struts (validate it) in action.clazz passing the String to the class that is using [email] ? Just my thought. Btw. what should we do with the @author tags? since some projects of Apache/Jakarta are removing them. Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 11:35 PM Cc: Jakarta Commons Developers List Subject: RE: [email] Dumbster failing Not a problem. I appreciate your working with me on this. I am looking forward to getting [email] whipped into shape! ERi -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 7:21 PM To: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Subject: Re: [email] Dumbster failing Ok, I have the tests all up and running with Maven. I have also made some minor mods, based on the tests or improving the input checking (this is why some of the tests are failing, there where against my changes not the HEAD version sorry) So once we get this formatting issue sorted, I will submit to you the new patch. This should raise the test coverage to 90+% for all (non-deprecated) classes. Thanks, Corey - 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: Validator inside of Email.java (RE: [email] Dumbster failing)
Want to say: A object represented by a clazz (subclass) of Email should be a valid Email. The validation should be done *before* creating an object of that class. -Matthias -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 9:09 AM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: Validator inside of Email.java (RE: [email] Dumbster failing) Hi Eric, I just update my email sources. and looked abit on the patches you are submitting. Cool to have some unittest. Btw. I saw that EmailValidator of Commons Validator is used inside of Email.java; Does it realy make sence to validate an e-mail inside that class? shouldn't this work be done outside? eg. enter e-mail via Struts (validate it) in action.clazz passing the String to the class that is using [email] ? Just my thought. Btw. what should we do with the @author tags? since some projects of Apache/Jakarta are removing them. Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 11:35 PM Cc: Jakarta Commons Developers List Subject: RE: [email] Dumbster failing Not a problem. I appreciate your working with me on this. I am looking forward to getting [email] whipped into shape! ERi -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 7:21 PM To: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Subject: Re: [email] Dumbster failing Ok, I have the tests all up and running with Maven. I have also made some minor mods, based on the tests or improving the input checking (this is why some of the tests are failing, there where against my changes not the HEAD version sorry) So once we get this formatting issue sorted, I will submit to you the new patch. This should raise the test coverage to 90+% for all (non-deprecated) classes. Thanks, Corey - 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: [email] was RE: Validator inside of Email.java (RE: [email] Dumbster failing)
see intermixed HumI'll answer the easy question first.. I think the @author tags should stay since it is an option. The PMC justs asks that projects make a decision on it one way or the other. So, for [email], I'll register myself on the yes they should stay side. yes ok :) no problem with it. In MyFaces, which is now in Incubator, we keep them too. But Struts for instance has removed them. The reason is that it helps figure out who had impact on what code, and at least for me, gives me the warm fuzzy's! It doensn't change copyright or anything, that remains with ASF. I belive it encourages contribution to see your name in lights and I would like them to stay. yes! that's it ;-) So, on the second side.. I guess, to what extent do we validate email information? I agree that requiring commons-validator seems a bit much for a small project like [email] just to use it. On the other hand, it does wrap the functionatliy up. Can you think of way to have our cake and eat it too? In other words, what is involved in maybe adding some sort of email validator decorate/helper class? Maybe something in a contrib directory showing how to do it.. well helperclazzes sounds more reasonable to me, but does this blow up [email] ? [email] should remain small, and having a dependency on commons-validator is a lot... yes! my +1 on remoing this dependency Eric PS, please tag your emails with [email], many folks filter on that type of tag in commons! sorry just forgotten... Matthias -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 9:25 AM To: 'Jakarta Commons Developers List' Subject: RE: Validator inside of Email.java (RE: [email] Dumbster failing) Want to say: A object represented by a clazz (subclass) of Email should be a valid Email. The validation should be done *before* creating an object of that class. -Matthias -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 9:09 AM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: Validator inside of Email.java (RE: [email] Dumbster failing) Hi Eric, I just update my email sources. and looked abit on the patches you are submitting. Cool to have some unittest. Btw. I saw that EmailValidator of Commons Validator is used inside of Email.java; Does it realy make sence to validate an e-mail inside that class? shouldn't this work be done outside? eg. enter e-mail via Struts (validate it) in action.clazz passing the String to the class that is using [email] ? Just my thought. Btw. what should we do with the @author tags? since some projects of Apache/Jakarta are removing them. Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 11:35 PM Cc: Jakarta Commons Developers List Subject: RE: [email] Dumbster failing Not a problem. I appreciate your working with me on this. I am looking forward to getting [email] whipped into shape! ERi -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 7:21 PM To: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Subject: Re: [email] Dumbster failing Ok, I have the tests all up and running with Maven. I have also made some minor mods, based on the tests or improving the input checking (this is why some of the tests are failing, there where against my changes not the HEAD version sorry) So once we get this formatting issue sorted, I will submit to you the new patch. This should raise the test coverage to 90+% for all (non-deprecated) classes. Thanks, Corey - 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: [email] Anyone interested?
Corey, are you thinking of introducing preconfigured email-objects as well? -Matthias -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 10:27 AM To: Jakarta Commons Developers List Subject: [email] Anyone interested? Is anyone interested in a set of wrapper classes around the rest of the Mail API, naming for the receiving of email? As email is intended to be small maybe this would consistute a new project? Just interested to hear anyones thoughts (positive or negative welcome :-D) -Corey - 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: [email] Anyone interested?
I guess Corey means only helper classes for [email] - A simple wrapper for validation - configured email-settings, that is in XML. for now, a developer needs to set all the stuff (eg. smtp-server, user,...) with a xml based *config* you could have more easy development. only setting sender,recipient, subject and text. isn't it? I guess he didn't wanted to created a mail server :) Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 11:09 AM To: Jakarta Commons Developers List; Corey Scott Subject: RE: [email] Anyone interested? I guess it depends on the scope of the extra dependencies and functionality. This sounds like it's within the scope of [email]. It isnt called [sendemail]!Also, is this starting to intrude on the space that James has? Not looking to create a mail server, or anything. You may want to look at http://james.apache.org/ for ideas. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 10:27 AM To: Jakarta Commons Developers List Subject: [email] Anyone interested? Is anyone interested in a set of wrapper classes around the rest of the Mail API, naming for the receiving of email? As email is intended to be small maybe this would consistute a new project? Just interested to hear anyones thoughts (positive or negative welcome :-D) -Corey - 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: [email] Anyone interested?
my +1 too -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:29 PM To: Jakarta Commons Developers List Subject: Re: [email] Anyone interested? I think this is a great idea!! -Corey Hi, These ideas are all very interesting. I would just caution against falling into the same pits experienced by [configuration] and [math]: that is, endlessly debating/adding features, refactoring, etc, before ever making a release. It might be good to get a 1.0 release out there and then discuss/act upon these new ideas for 1.1 or 2.0. Release early, release often is always my vote ;) Yoav Shapira http://www.yoavshapira.com - 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: [email] Anyone interested?
hi, Bases on the release early, release often criteria, maybe it makes sense to get the rest of Corey's unit tests patches in, and spend a bit of time verifing all the javadocs etc. Then do a 1.0 of whats there. That way we don't have to be quite as contrained by the existing API, as projects that depend on email will have a nice released version that they can use. yes, sounds good to me. But in 1.0 [email] should not depend on Commons Validator. This also might be the time to migrate out of the sandbox? I guess this depends on a vote in commons-dev list, isn't it? Regards, Matthias -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:44 PM To: 'Jakarta Commons Developers List'; 'Corey Scott' Subject: RE: [email] Anyone interested? my +1 too -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:29 PM To: Jakarta Commons Developers List Subject: Re: [email] Anyone interested? I think this is a great idea!! -Corey Hi, These ideas are all very interesting. I would just caution against falling into the same pits experienced by [configuration] and [math]: that is, endlessly debating/adding features, refactoring, etc, before ever making a release. It might be good to get a 1.0 release out there and then discuss/act upon these new ideas for 1.1 or 2.0. Release early, release often is always my vote ;) Yoav Shapira http://www.yoavshapira.com - 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: [email] Anyone interested?
David, thanks for pointing this out! Regards, Matthias -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 6:12 PM To: Jakarta Commons Developers List Subject: RE: [email] Anyone interested? --- Eric Pugh [EMAIL PROTECTED] wrote: Bases on the release early, release often criteria, maybe it makes sense to get the rest of Corey's unit tests patches in, and spend a bit of time verifing all the javadocs etc. Then do a 1.0 of whats there. That way we don't have to be quite as contrained by the existing API, as projects that depend on email will have a nice released version that they can use. This also might be the time to migrate out of the sandbox? Sandbox projects are not allowed to have releases so you would need to get voted into commons proper before releasing 1.0. David -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:44 PM To: 'Jakarta Commons Developers List'; 'Corey Scott' Subject: RE: [email] Anyone interested? my +1 too -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:29 PM To: Jakarta Commons Developers List Subject: Re: [email] Anyone interested? I think this is a great idea!! -Corey Hi, These ideas are all very interesting. I would just caution against falling into the same pits experienced by [configuration] and [math]: that is, endlessly debating/adding features, refactoring, etc, before ever making a release. It might be good to get a 1.0 release out there and then discuss/act upon these new ideas for 1.1 or 2.0. Release early, release often is always my vote ;) Yoav Shapira http://www.yoavshapira.com - 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] __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - 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: [email] Current status, etc.
Hi Corey, I read your mail and saw that you contributed some unit tests. thanks. I am using email in a webapp for sending ecards. That works fine. I submitted two patches for this project, since I got kamar. One allows you do to pop3BeforeSmtp auth. (thanks to Daniel Perry) the other allows you to set a port for STMP server. All patches depend on my needs. the first was created during a discussion in struts user list, second was inside of bugzilla, so I submitted it. However, I start next month a project, that needs email as well and now I am thinking on dealing with XML based configurations. Now the programmer must set user, host etc. If you declare it in xml it is not static build into my app. Any comments? Regards, Matthias -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Saturday, October 23, 2004 10:03 AM To: Jakarta Commons Developers List Subject: [email] Current status, etc. I recently came across this project and noticed that it seems to be very inactive. I must say that this is surprising cause there are few web apps that don't use email is some variation or another. So I have a couple of questions: 1) Are you using this project? 2a) If so, what can be done to improve it? What is annoying about it? 2b) If not, why not? What doesn't it do that stops you from using it? 3) Any other suggestions? All responses will be greatly appreciated. Thanks, Corey Scott PS. It is not my intention to start a flame war, so please be honest but not (too) brutal in any criticism - 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: [email] Current status, etc.
A project like [email] should not, IMHO, have its own configuration code. That changes it from a low-level library usable by all to one that forces a specific configuration route. This is no good for frameworks like Spring where the configuration mechanism is part of the framework. Jupp, that sounds reasonable. The EmailConfigurator, which I plan is for my own. The customer is more able to change his email settings. not more. (perhaps also I like to play a bit with topics like dependency injection ;-)) For now, [email] works good for me and is handy! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Current status, etc.
Corey, I haven't looked at [Configuration] project. On my current project I have a solution like: -user's config is in xml I wrote a Configuratore, using Digester, and populating the properties of my UserConfig JavaBean. The JavaBean is used on setting up connection to a Server. Regards, Matthias -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Saturday, October 23, 2004 12:23 PM To: Jakarta Commons Developers List Subject: Re: [email] Current status, etc. Stephen, Forgive me for asking for confirmation, but does this mean that you are NOT in favor of changing the way that the Email library handles configuration? Meaning that the coder must still set all of the config vars? I think this is fine, in fact I find that I use the config project for this anyway, as config has (IMHO) to be externalized. With all that said, maybe would could make some kind of wrapper or standard set of config vars but make it in such a way that makes it optional? This would probably be a config instance (from the config project) or similar, Matthias does this suit your needs? Corey - 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: kama for commons/sandbox Email
thanks guys! it was the /home/cvs-thing, thank James! Regards, Matthias -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Friday, August 27, 2004 1:58 PM To: Jakarta Commons Developers List Subject: RE: kama for commons/sandbox Email James Mitchell wrote on Friday, August 27, 2004 1:26 PM: 1. Make sure you are using 'extssh' as the connection method in Eclipse (as Craig suggested) 2. Make sure the Repository path is set to /home/cvs and not /home/cvspublic (as Martin suggested) 3. Open the view Error Log in Eclipse to see the internal error report of Eclipse. That might give you another idea, what's really going wrong. - Jörg - 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]
[Sandbox/Email] - Maven
hi, when I try to run Maven, I got that: WARNING: Failed to download activation-1.0.2.jar. The build cannot continue because of the following unsatisfied dependencies: javamail-1.2.jar (try downloading from http://java.sun.com/products/javamail/) activation-1.0.2.jar (try downloading from http://java.sun.com/products/javabeans/glasgow/jaf.html) Total time: 5 seconds Any workarounds ? -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matthias AT wessendorf DOT net URL: http://www.wessendorf.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: kama for commons/sandbox Email
Martin, the eclipse-project-properties for CVS tell me, that I used my apache-account for module jakarta-commons-sandbox/email mmm... -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, August 27, 2004 7:35 AM To: Jakarta Commons Developers List Subject: Re: kama for commons/sandbox Email Make sure you checked out the tree using your Apache account, and that you're not trying to check in from a tree checked out using anonymous CVS. -- Martin Cooper On Fri, 27 Aug 2004 07:18:19 +0200, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hen, thanks. I just tryed to commit via cvs (SSH) with my account [EMAIL PROTECTED], but got CVS-Error (The Server reported an error while performing the cvs commit command). anything to do with jakarata-unix-group ? Regards, Matthias -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Thursday, August 26, 2004 7:37 AM To: Jakarta Commons Developers List Subject: Re: kama for commons/sandbox Email Now added to the jakarta group. Hen On Wed, 25 Aug 2004, Henri Yandell wrote: Karma added. I've asked the infrastructure group to add you to the jakarta unix group, so you won't be able to use your karma until then. Hen On Wed, 25 Aug 2004, Matthias Wessendorf wrote: I'd take care of patches if no one who's been more active on commons-email. I think it is a great project. The patch I would like submit allows the users to use the pop3-before-smtp-functionality for mailservers. Some mailserver may need this... perhaps one reason is spam? So if someone wants to give me sandbox karma, I'll take care of that bug/enhancement. http://issues.apache.org/bugzilla/show_bug.cgi?id=29435 Matthias -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matthias AT wessendorf DOT net URL: http://www.wessendorf.net - 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]
Commons-Email: (was Javamail license on geronimo-dev)
Does anyone know more on it? since Email uses java-mail from sun. regards, matthias -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 14, 2004 4:57 AM To: [EMAIL PROTECTED] Subject: Javamail license I know Geir has been working on this, but it popped up on my radar again... I think we have a serous problem with Javamail unless sun is willing to relicense it. The license is here http://java.sun.com/products/javamail/LICENSE.txt I think the biggest problem for us is this section (near the bottom): (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. Does the ASF allow us to ship software from ASF servers that contain dependencies that have this kind of language? -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Validator] Niall Pemberton as Committer
+1 -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Monday, May 24, 2004 10:16 PM To: Jakarta Commons Developers List Subject: [Validator] Niall Pemberton as Committer Niall Pemberton is an Apache Struts Committer who would like to apply some patches to the Validator, with the hope of moving toward another release. Here's my +1 -Ted. - 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: [validator] Why doesn't commons-validator include functional validators?
that facade method sounds great, i use in JSF-Apps the business logic of some commons validators ;-) Cheers, -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 26, 2004 7:17 PM To: Jakarta Commons Developers List Subject: Re: [validator] Why doesn't commons-validator include functional validators? Personally I prefer the facade method. I like the fact that, for example, the UrlValidator only contains the logic to validate a url and knows nothing about the validator framework it sits in. I think this has two advantages: * Users could utilise the validation without having to adopt the framework - maybe embedding it in their business logic or an alternative framework. Some users (e.g. Edgar Dollin's recent message on the Struts Dev list) don't want to put their validation rules in an XML file. I don't think we should limit validator's use by forcing the adoption of the framework. * It's easier to test - writing test scripts is simpler, you don't have to have a whole load of XML set up to test the actual validation logic. The other thing I was thinking is that the method signitures are too simple...validations could return several things: true/false, a converted value, an error code, an error message - maybe all of these should be returned in a ValidatorResult object rather than just true/false. Also how about having a validator context object - in the Struts world if someone wanted to write a validator which accessed the Request, then they could provide it through the context. public ValidatorResult isValid(Object bean, Field field, ValidatorAction va, Context context); Niall - Original Message - From: Don Brown [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, May 26, 2004 4:58 PM Subject: Re: [validator] Why doesn't commons-validator include functional validators? Yes, in my view, validator config should refer directly to the validator being used. This makes the config more readable, IMO. I thought about making a FieldChecks-type facade object for commons-validator, but the adapter methods - i.e. isValid(Object bean, Field field) - still need to be generated for each validator and I think it is cleaner to, when adding a new validator or changing an existing, only have to modify one file, the validator, rather than the validator and the facade. To help solve the duplication, I've created a SimpleValidator abstract class that has two methods: public boolean isValid(Object bean, Field field); public abstract boolean isValid(String val); For the simple validators, they could extend this class and only implement the abstract method. I'm not sure what else one could do since the limiting factor is the unique signatures of the actual validation method. Don David Graham wrote: --- Don Brown [EMAIL PROTECTED] wrote: Just to be clear, the approach I feel would be simplest is to add isValid(Object bean, Field field)-type methods to each validator. This way, the validators commons-validator provides can be used as they are or front-ended like how Struts' FieldChecks class interacts with them. So would you configure validator xml elements that reference DateValidator directly instead of FieldChecks? Would we be able to remove some of FieldChecks' methods? I've already gone through several validators, adding unit tests as I go, and things are looking good. Before I finish the rest of the validators, however, I want to make sure this is a good idea in the eyes of everyone else. For example, the new DateValidator looks like this: public boolean isValid(Object bean, Field field); public boolean isValid(Object bean, Field field, Locale locale); public boolean isValid(String value, String datePattern, boolean strict); public boolean isValid(String value, Locale locale); The top two methods do four things: 1. Pull the necessary parameters out of field variables (ie datePattern out of a field var to be passed to the third method) 2. Extract the field value as a String 3. Return true if the value is blank or null since the field may not be required (the bottom two methods return false in such a case) 4. Delegate handling to the bottom two methods Are these steps going to be duplicated for every pluggable validator? If so, maybe we could front DateValidator and friends with something like FieldChecks that contains the glue code? David Any objections? Don David Graham wrote: I'd be interested in any patches in this area so please open a bugzilla ticket for this. It sounds like you have some good ideas for making validator easier to use; I just don't have much time right now to
RE: [Validator] Don Brown as Committer
read Don's mail about commons-validator and his plans..., so here is my +1 Cheers, -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 6:19 PM To: Jakarta Commons Developers List Subject: [Validator] Don Brown as Committer Don Brown is an active Apache Struts Committer who would like to apply some patches to the Validator, with the hope of moving toward another release. Here's my +1 -Ted. - 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]
[FileUpload] Utilclass for storing files in a specified directory
I developed a class, that contains two methods, that store files to a
specified dir.
one methode takes only FormFile as argument, it loads that path for
storing form a properties-file.
the second takes FormFile and a String, which contains the desired path
for storing,
if not a properties-file is given ...
would it be usefull, to have such a util-class directly in
FileUpload-Project ?
(i didn't figured out a methode like this...)
snip
/**
*
* Saves a Jakarta FormFile to a confiured place.
*
* @param file - the FormFile to store
* @return place of file
*/ public static String saveFile(FormFile file){
String retVal = null;
try {
//retrieve the file data
ByteArrayOutputStream baos = new
ByteArrayOutputStream();
InputStream stream = file.getInputStream();
Properties props = new Properties();
//properties must exist
props.load(Thread.currentThread().getContextClassLoader().getResourceAsS
tream(fileupload.properties));
String place= props.getProperty(uploadPath);
if(!place.endsWith(/))
place = new
StringBuffer(place).insert(place.length(),/).toString();
retVal = place+file.getFileName();
//write the file to the file specified
OutputStream bos = new FileOutputStream(retVal);
int bytesRead = 0;
byte[] buffer = file.getFileData();
while ((bytesRead = stream.read(buffer)) != -1)
{
bos.write(buffer, 0, bytesRead);
}
bos.close();
//close the stream
stream.close();
}
catch (FileNotFoundException fnfe) {
fnfe.printStackTrace();
}
catch (IOException ioe) {
ioe.printStackTrace();
}
return retVal;
}
/**
*
* Saves a Jakarta FormFile to a desired place.
*
* @param file - the FormFile to store
* @param place - the desired place for the file
* @return place of file
*/
public static String saveFile(FormFile file, String place) {
String retVal = null;
try {
//retrieve the file data
ByteArrayOutputStream baos = new
ByteArrayOutputStream();
InputStream stream = file.getInputStream();
Properties props = new Properties();
//properties must exist
props.load(Thread.currentThread().getContextClassLoader().getResourceAsS
tream(ecards.properties));
String tomcatVerzeichnis=
props.getProperty(uploadPath);
retVal = tomcatVerzeichnis+place;
System.out.println(FILE: +retVal);
//write the file to the file specified
OutputStream bos = new FileOutputStream(retVal);
int bytesRead = 0;
byte[] buffer = file.getFileData();
while ((bytesRead = stream.read(buffer)) != -1)
{
bos.write(buffer, 0, bytesRead);
}
bos.close();
//close the stream
stream.close();
}
catch (FileNotFoundException fnfe) {
fnfe.printStackTrace();
}
catch (IOException ioe) {
ioe.printStackTrace();
}
return retVal;
}
/snip
Cheers, Matze
--
Matthias Weßendorf
Aechterhoek 18
D-48282 Emsdetten
Germany
Email: matthias AT wessendorf DOT net
URL: http://www.wessendorf.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Just a test
jupp, noticed the same ... (today) -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, May 24, 2004 7:25 PM To: Jakarta Commons Developers List Subject: [math] Just a test Unsure why my email is not coming through. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Sandbox-Email] pop before smtp
During disscussion with Daniel Perry, we both figured out, that there no Pop3BeforeSmtp-Support in Sandbox-Email Daniel wrotes a nice patch, that supports popBeforeSmtp. he send me his Email.java, that i am now also able to run this feature so would it be usefull to integrate the patch in email? cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [validator] Why doesn't commons-validator include functional validators?
Don, (perhaps abit OT) do you know this article? http://weblogs.java.net/pub/wlg/618 and the JSR 94 (Java Rule Engine) http://www.jcp.org/en/jsr/detail?id=94 perhaps you will find something usefull. Cheers, Matze -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Friday, May 21, 2004 10:37 PM To: Jakarta Commons Developers List Subject: [validator] Why doesn't commons-validator include functional validators? After looking through the different validator usages - Struts, Spring, and the unit tests - I'm a bit confused why commons-validator doesn't ship with functional validators that can be used directly and not hidden by some adapter. commons-validator contains validator classes, yes, but you still need to create a validator adapter class that accepts at least the bean and the Field object to interact with the validator. Furthermore, this adapter class (Struts and Spring both call it CheckFields) contains framework specific references, usually dealing with their errors system. The problem with this approach is it requires huge levels of duplication as each container needs to write their own adapter and error creation code. I'm particularly confused because it seems the solution already exists within commons-validator - ValidationResult(s). I would think a better approach would be for commons-validator to provide adapters for every validator to extract the field information from Field and pass it along to the actual validator. The process of creating messages should be left to the class that called validator.validate() to process ValidationResults and handle the errors in a container-specific way. This way, new containers that want to use commons-validator don't have to write their own monolithic adapter class but can use validators as they are. If commons-validator wants to separate a validator into a commons-validator adapter class and a actual validation class, that is fine, but there really isn't any need for that adapter to depend on a container. If my premise is sound and the solution agreeable, I would be willing to do the leg work of writing container-independent adapters for each of the validators. Don - 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: [Validator] 1.1.3 Release
works fine with nightly builds from struts thanks! -Original Message- From: Robert Leland [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 10:20 PM To: Jakarta Commons Developers List Subject: Re: [Validator] 1.1.3 Release +1, Thanks If anyone would like to try out that release before hand the can go to http://apache.org/~rleland/commons-validator I uploaded it based on a build from the 1_1_2_BRANCH last night. -Rob -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 08:09 PM To: [EMAIL PROTECTED] Subject: [Validator] 1.1.3 Release If there are no objections, I'd like to roll a 1.1.3 release Friday, April 30, sometime after 5PM EST (GMT-5). -Ted. - 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]
