[configuration] Build fails under Maven 1.1-beta2
Hi all, Under maven 1-1.-beta2 there seems to be an issue with the maven- tasks-plugin. I upgraded to 1.2.0 from 1.1.0 to see if that resolved it, but no joy. I actually think the issue is in the project.xml of the tasks plugin. At any rate, if I comment it out, everything is fine. Also, since we are at RC stage, can I bump the versions of the maven- tasks-plugin and maven-findbugs-plugin (should be 1.0!) Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] findbugs and JDK1.3
One more thing... I noticed that findbugs is commented out: !-- Commented out, does not run on JDK 1.3 reportmaven-findbugs-plugin/report -- According to the homepage for Findbugs, while yes, it does require JDK1.4 to run, it should analyze 1.3 code. When we compile for 1.3, does that mean you are using a 1.3 JDK as well? RC is looking good, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 37363] - [email] Address char-set can not be individuallyset
James, We should keep this discussion on the commons-dev email list, I'll cc it there. I would love to take a patch file for you, and if you haven't worked with Open Source before and Apache specifically I can help you. In terms of getting the changes in, well we are ALL apache developers! In order to submit a patch, all you have to do is check out the source, make the change, write a unit test, and then create a patch file. I find Eclipse and Maven make this very very easy. I suggest you read http://www.apache.org/foundation/how-it-works.html for more about Apache Foundation and how you can become involved. Eric On Nov 30, 2005, at 10:44 PM, James Huang wrote: Well, my use case is simpler but I know for sure it is happening in real word: the encoding of email addresses is different from that of the whole message. This happens to some Japanese mail systems, as I was told. To cope with my use case, the fix is extremely easy: in the org.apache.commons.mail.Email class, just add a few more methods to take javax.mail.internet.InternetAddress as parameter. Afterall, I believe InternetAddress is used internally anyway. I don't want to go through the hassle of creating accounts, etc., in order to submit patches, and just hoping some apache mail developer will make this easy fix. Your scenario is interesting but different; I'd imaging you'll have to change the encoding for the message body itself in order to send to different recipients (expecting specific encoding)? Cheers, -James From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 37363] -[email] Address char-set can not be individually set Date: Tue, 29 Nov 2005 15:36:57 +0100 (CET) DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37363. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37363 --- Additional Comments From [EMAIL PROTECTED] 2005-11-29 15:36 --- Would you like to submit a patch and a unit test? Basically, what this allows you to do is send a single email to multiple recipients, and each recipient gets their own charset for their email? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi? tab=email --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Committer - Jörg Schaible
A very enthusiastic +1, it is about time! On Sep 25, 2005, at 4:40 PM, Phil Steitz wrote: I would like to nominate Jörg Schaible as an Apache Jakarta Commons Committer. Jörg has provided patches to [configuration], [id] and [i18n] and has contributed to discussion on commons-dev for over a year now. He is interested in contributing to [lang] and [io], as well as helping to get [id] graduated from the sandbox and released. I think he would make a valuable addition to the commons committers. Votes please, closing Wednesday 28 September, Miidnight GMT. Phil -- -- [ ] +1, let him commit! [ ] +0 [ ] -0 [ ] -1, no, because - 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][restarted] Release Commons Email 1.0
Get my +1 in the email record. [X ] +1 Release Email 1.0 based on RC8 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive (We want to see RC9, RC10, and R11 first!) [ ] -1 Do not release Email 1.0 based on RC8 Cheers, Eric Pugh On Sep 1, 2005, at 8:05 AM, Eric Pugh wrote: -- 8- [X ] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 Thanks! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
[VOTE][RESULT] Release Commons Email 1.0
It looks like Commons Email 1.0 based on Henning's RC8 is go for launch! The following people voted +1 for the release: Dion Gillard +1 Stephen Colebourne +1 Henning Schmiedehausen +1 Eric Pugh +1 The following people voted +0 for the release: robert burrel donkin +0 phil steitz +0 There were no -1. Henning has generously volunteered to be the release manager, and has dealt with some of the comments raised by the +0 committers. Eric Pugh On Sep 19, 2005, at 2:13 AM, Henning P. Schmiedehausen wrote: Phil Steitz [EMAIL PROTECTED] writes: Agree with Robert's comments and am also +0, with three additional comments= : * The ant build depends javamail 1.3.2, while the maven POM references 1.3.= 3.=20 The ant build should be updated to match the POM Ok, will do. * It would be good to provide some instructions in the README, release note= s=20 or web site on what users have to do to get javamail and activation manuall= y=20 deployed locally so the maven and ant builds work. There is some information on how to get javamail and activation in RELEASE-NOTES.txt. If more information is wanted, patches are always welcome. * Before cutting the final release, you should update the index.xml page to= =20 eliminate the reference to RCs Yes. The release will be based on RC8, not RC8 as 1.0. I will have to change the references from RC8 to 1.0 anyway. Currently, I'm waiting for Eric to call the vote to close and post a result. Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][restarted] Release Commons Email 1.0
I would like to restart the vote for Commons Email 1.0 based on RC8. The various packaging/dependency issues have been resolved, and Commons Email is working great on WebLogic. While this voting process has dragged on, it has also led to a lot of polish being added, and reducing the chance of a 1.0.1 coming out in a week! [ ] +1 Release Email 1.0 based on RC8 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive (We want to see RC9, RC10, and R11 first!) [ ] -1 Do not release Email 1.0 based on RC8 Cheers, Eric Pugh On Sep 1, 2005, at 8:05 AM, Eric Pugh wrote: -- 8- [X ] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 Thanks! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Email 1.0
-- 8- [X ] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 Thanks! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][email] commons-email release candidate 6 available
Mac OS X 10.4 and I assume US locale. However, I have to downgrade
my dumbster to 1.5, so I could imagine weirdness. I am okay with
things as long as it works for you.
I'll call the vote now.
Eric Pugh
On Aug 31, 2005, at 4:46 AM, Henning P. Schmiedehausen wrote:
Eric Pugh [EMAIL PROTECTED] writes:
So now there are no outstanding bugs left. However, after I applied
the patchs, I reran my tests using a maven clean first, and now am
having some unit test failures.
It seems like attaching a bad url doesn't actually cause any
failures Can someone else confirm this issue?
The unit tests work fine for me with both en_US and en_US.UTF-8
locale. What platform, what locale did you try?
Regards
Henning
Eric
On Aug 30, 2005, at 8:22 AM, Henning P. Schmiedehausen wrote:
BodyPart primary = getPrimaryBodyPart();
if ((primary instanceof MimePart) StringUtils.isNotEmpty
(charset)) {
((MimePart) primary).setText(msg, charset);
} else {
primary.setText(msg);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero
for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Commons Email 1.0
Since commons-email RC 1 there have been quite a few new release candidates. At this point ALL the bugs in Bugzilla have been dealt with. The code has been tagged as EMAIL_1_0_RC7 and differs from RC6 in some doc/code cleanup and minor refactoring. The binaries and docs are available from http://people.apache.org/ ~epugh/commons-email/ I have ignored the unit tests as they are currently failing due to some other reason on my box. They all pass cleanly on other Commons developer's boxes. This might be a good thing to double check. Votes, please. The vote will run for 72 hours. --8- [ ] +1 Release Email 1.0 [ ] +0 General support but not definitive [ ] -0 Unhappy about the release but not definitive [ ] -1 Do not release Email 1.0 Thanks! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] September archive of components
commons-xo was used in Turbine 3 and 2. For Turbine 2, we have implemented something else, and Turbine 3 is dormant, so I think from Turbine land I can give a +1. Eric On Aug 28, 2005, at 7:50 PM, Henri Yandell wrote: Here's the list to archive in September, on September 3rd (next Saturday): cache clazz codec-multipart convert events filters functor graph2 http jex jjar jpath jux mapper messenger periodicity reflect rupert scaffold services simplestore tbm test threading threadpool workflow xmlio xmlunit xo Any -1's to the above? Special cases etc? There are some at 5 months inactivity. I'll hit them in a month or so. Hen - 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: [ANNOUNCEMENT][email] commons-email release candidate 6 available
Henning (and others), Do you think we are at a good enough point to call for 1.0? I am working on fixing the Gump metadata descriptor, which is currently broken due to findbugs, but that shouldn't affect our 1.0. Eric On Aug 25, 2005, at 4:19 AM, Henning P. Schmiedehausen wrote: Eric Pugh [EMAIL PROTECTED] writes: the sixth release candidate for commons email is now available for download from http://people.apache.org/~epugh/commons-email/. I tagged rc6 to tags/EMAIL_1_0_RC6 and moved the trunk to rc7-dev. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT][email] commons-email release candidate 6 available
I looked through, and the fix you suggested was quite
straightforward.. Don't know why I didn't think of it myself! Doh!
So now there are no outstanding bugs left. However, after I applied
the patchs, I reran my tests using a maven clean first, and now am
having some unit test failures.
It seems like attaching a bad url doesn't actually cause any
failures Can someone else confirm this issue?
Eric
On Aug 30, 2005, at 8:22 AM, Henning P. Schmiedehausen wrote:
BodyPart primary = getPrimaryBodyPart();
if ((primary instanceof MimePart) StringUtils.isNotEmpty
(charset)) {
((MimePart) primary).setText(msg, charset);
} else {
primary.setText(msg);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] another method signature change in 1.0-rc6
Yes, think we expected to do a couple fixes to Turbine once we hit 1.0... Eric On Aug 25, 2005, at 6:41 AM, Henning P. Schmiedehausen wrote: .../target/src/org/apache/turbine/util/velocity/ VelocityHtmlEmail.java:191: send() in org.apache.turbine.util.velocity.VelocityHtmlEmail cannot override send() in org.apache.commons.mail.Email; attempting to use incompatible return type found : void required: java.lang.String public void send() throws EmailException ^ .../target/src/org/apache/turbine/util/velocity/VelocityEmail.java: 242: send() in org.apache.turbine.util.velocity.VelocityEmail cannot override send() in org.apache.commons.mail.Email; attempting to use incompatible return type found : void required: java.lang.String public void send() throws EmailException ^ Note: Some input files use or override a deprecated API. Note: Recompile with -deprecation for details. 2 errors Those methods have returned void up to 1.0-rc5. Yet another Turbine breakage... ;-) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Findbugs
Digging into it, I don't really get the setSendDate() being public
either. I lean towards it being private as well. Also, why can't
we return null? The logic in getSendDate() seems odd.. If you
haven't sent the email, then it should be null:
public Date getSentDate(){
return sentDate;
}
I am not sure about the toLowerCase().. The line you referenced
doesn't seem to deal with headers, but, if you want to make the
change, go ahead. and I'll be happy to post (and tag!) an RC7.
Cheers,
Eric
On Aug 25, 2005, at 6:38 AM, Henning P. Schmiedehausen wrote:
Hi,
I've added a findbugs task to the email build and it has a few things
to report. We might discuss a little bit whether it is worth to work
on this:
Email.java 911, 926: externally mutable object
This is correct. The date object could be changed after it was put
into the Email object. Personally I consider this a minor
issue. Change would be
public void setSentDate(Date date) {
this.sentDate = (date == null) ? new Date() : new Date
(date.getTime());
}
public Date getSentDate() {
if (this.sentDate == null) {
return new Date();
else
return new Date(this.sentDate.getTime());
}
(IMHO, sentDate should be private, not protected. Then you could omit
the test in the getSentDate method)
Email.java 286: dubious String.toLowerCase()
Correct, too. As Mail headers are defined as US-ASCII (according to
RFC 2822, 2.1 General Description), we could use explicit US-ASCII
coding.
Email.java: Field not initialized in constructor:
org.apache.commons.mail.Email.session
Hm. We have lots of these. Why does Findbugs nag about that one?
Email.java 426
MultiPartEmail 295
HtmlEmail 195 catches Exception, but Exception is not thrown in
the
try block and RuntimeException is not explicitly
caught
False positives IMHO. There are a few Exceptions inside these blocks
that derive from Exception.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero
for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[general][exec] Exec needs a BugZilla component!
While the [email] component is perfectly happy to host [exec] bugs in CVS as we are just a couple letters off, it may be confusing to people! http://issues.apache.org/bugzilla/show_bug.cgi?id=36314 Who has the karma to create component? If someone wants to grant it to me, I'll be happy to make the change.. I wasn't sure the bugzilla-admin address was for these types of items... Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general][exec] Exec needs a BugZilla component!
Thanks.. I have updated the component. On Aug 24, 2005, at 5:23 PM, Rahul Akolkar wrote: On 8/24/05, Eric Pugh [EMAIL PROTECTED] wrote: While the [email] component is perfectly happy to host [exec] bugs in CVS as we are just a couple letters off, it may be confusing to people! http://issues.apache.org/bugzilla/show_bug.cgi?id=36314 Who has the karma to create component? If someone wants to grant it to me, I'll be happy to make the change.. I wasn't sure the bugzilla-admin address was for these types of items... AFAICT, [exec] is fairly new, and in sandbox. There is a [Sandbox] entry in BZ for Commons, which is the one to use for [exec]. Though that doesn't help your problem of mistaken filings under [email], I'm not sure if anything can be done (just yet). -Rahul - 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]
[ANNOUNCEMENT][email] commons-email release candidate 6 available
the sixth release candidate for commons email is now available for download from http://people.apache.org/~epugh/commons-email/. The only change was a backwards compatible change to expose MimeMessage from Email class (http://issues.apache.org/bugzilla/ show_bug.cgi?id=35881). The only odd thing is that in the docs, the links to the project reports didn't show up.. If no one finds a show stopper, then Henning has graciously volunteered to be the release manager and perform the magic signing of the jars with his Apache key. - eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] status?
I've applied the one patch (35881) that was simple from Siegfried, and the other one I don't feel comfortable b/c it involves changing a signature (34056). I am going to tackle the RC now. Eric Pugh On Aug 22, 2005, at 4:53 PM, robert burrell donkin wrote: On Mon, 2005-08-22 at 19:40 +1000, Dion Gillard wrote: Unfortunately for me, my Dad's still in ICU in hospital, and I'm on limited email and 'spare' time. Sorry for the hassle. no hassle intended :) - robert On 8/22/05, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: robert burrell donkin [EMAIL PROTECTED] writes: where are we now on the 1.0 roadmap? what work's remaining before we can roll another candidate? I think that Dion wanted to look into the different exceptions thrown issue that hit Turbine. IMHO this is just a minor nit, though. There is also the issue of the two open bugzilla issues that some people want to roll in before 1.0 Personally, I'm +1 for a new RC, there was no activity in the last week or so, so the interest seems to have died down and I'd really like to see either an RC or a 1.0 relase soon. We can still tie up loose ends in 1.0.1 or 1.1 Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] status?
I will call for one as soon as RC6 has been out for a couple days.. Dying for a vote and a release.. This horse has been beaten for long enough! On Aug 24, 2005, at 5:59 PM, Dion Gillard wrote: Do you want to do an official vote? On 8/25/05, Eric Pugh [EMAIL PROTECTED] wrote: I've applied the one patch (35881) that was simple from Siegfried, and the other one I don't feel comfortable b/c it involves changing a signature (34056). I am going to tackle the RC now. Eric Pugh On Aug 22, 2005, at 4:53 PM, robert burrell donkin wrote: On Mon, 2005-08-22 at 19:40 +1000, Dion Gillard wrote: Unfortunately for me, my Dad's still in ICU in hospital, and I'm on limited email and 'spare' time. Sorry for the hassle. no hassle intended :) - robert On 8/22/05, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: robert burrell donkin [EMAIL PROTECTED] writes: where are we now on the 1.0 roadmap? what work's remaining before we can roll another candidate? I think that Dion wanted to look into the different exceptions thrown issue that hit Turbine. IMHO this is just a minor nit, though. There is also the issue of the two open bugzilla issues that some people want to roll in before 1.0 Personally, I'm +1 for a new RC, there was no activity in the last week or so, so the interest seems to have died down and I'd really like to see either an RC or a 1.0 relase soon. We can still tie up loose ends in 1.0.1 or 1.1 Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http:// www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: commons-dev- [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] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] Update on bug list
Hi all, I checked out 34056 (http://issues.apache.org/bugzilla/show_bug.cgi? id=34056) and it doesn't seem bad. The one thing Henning highlighted: -getPrimaryBodyPart().setText(msg, charset); +//BROKEN! +//getPrimaryBodyPart().setText(msg, charset); +getPrimaryBodyPart().setText(msg); I don't see why this is broken... Seems to me like we add getPrimaryBodyPart().setText(msg,charset) as well... I also looked at 35881 (http://issues.apache.org/bugzilla/ show_bug.cgi?id=35881), and despite not being able to apply, the change doesn't seem bad either. I would like to see the 1.0 release be one we can rely on for a while, and the changes to faciliate subclassing/extension in 34056 and 35881, and then cutting RC6 seem like an okay path forward. Any opinions? I think at least 35881 can be applied, and if we get back the info on 34056 on the // BROKEN bit, then it could go in as well. Commons-email has taken this long, whats another week or two... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Jerome Lacoste wrote a proposal a couple months ago to the CruiseControl mailing list talking about the same basic idea. His proposal is here: http://www.coffeebreaks.org/blogs/?p=8. I will forward this thread to him as he might be very interested in contributing. At any rate, something like this in Jakarta Commons would be great, I know I am using at least three different implementations of the same basic functionality! Eric Pugh On Aug 1, 2005, at 7:04 PM, Kev Jackson wrote: This is a very short description of the cleaned up Ant exec task design: * Exec: the former Ant task class used to create and configure Execute instances. Now mainly a convience class for starting new Execute instances. * Execute: the main class for running one process. Handles creation and configuration of the necessary objects (stream pump, watchdog, process destroyer). Can wait for the full execution time to enable synchronous return of the process return code or spawn a process to run async. * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. * WatchDog: used to time out a running process. After a given time has passed, the process is checked if it's still running and there after destroyed. * CommandLauncher: a family of classes for actually starting the processes. Implementations exist for e.g. Java 1.1, Java 1.3, WinNT, Mac, VMS and so on. These classes handles the platform specifics. * Environment: used to retrive the current environment as well as setting new environment variables. Reading the current environment is done using platform specific commands (e.g. cmd /c set, env, /bin/env) and parsing the result. This could of course be improved on J2SE 5.0 to use System.getenv() instead. * StreamPumper: used to read/write the three stream (in, out, error) simultaniously. * CommandLine: class for handling (e.g. parsing, quoting) command lines. It might be worth extracting the interface from Ant, creating an implementation (using the interface) and then using this in a branch of Ant just to test that we've extracted all the necessary functionality. IIRC Environment is really derived through JavaEnvUtils (though I'll have to check source). A common interface for a commandLine would allow us to create platform specific commandLines depending on environment 2c Kev - 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: sandbox access
Most projects are very happy to have more interest! That is part of the reason they are in sandbox, is to build up a group of interested developers...! On May 17, 2005, at 8:01 PM, Craig McClanahan wrote: The convention in the sandbox (and in Commons Proper for that matter) are to coordinate with the developers (if any) working on the component you want to modify, and add yourself to the STATUS.html file that is there as well. Craig On 5/17/05, Torsten Curdt [EMAIL PROTECTED] wrote: Guys, I got access to the sandbox mainly for javaflow and jci. ...but would it be ok to commit code/fixes to other sandbox projects as well? cheers -- Torsten - 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: [resources] was: Re: RESEND: RE: Load message resources from DB???
As a big user of Configuration, I've thought that it would be quite useful in many places. The flexibility it adds is really useful. Configuration isn't specifically locale aware, however, we have discussed adding a ConfigurationLocaleAware decorator that would handle that. The Scarab project has it's own logic that takes a Configuration and makes it locale aware for i18n purposes for example. Eric On Apr 7, 2005, at 12:10 PM, James Mitchell wrote: Like many of the Jakarta Commons projects, Commons Resources was based, in part, from the initial work done in Struts and later copied over to commons with the intent to one day use that library. This is what was done for Beanutils, Digester, Validator, and more I'm sure. (Craig, correct me if I am wrong here) MessageResources (the one in Struts) was created because ResourceBundle (java api) did not provide the required functionality (at the time it was needed). I have only had a cursory look at Configuration. From what I know of it, it is a reusable library for getting configuration data into your application (typically during startup). Commons Resources is a reusable library for retrieving properties pairs (locale aware) for your application. I do not know if Configuration is locale aware, but I suppose Commons Resources could be extended (or changed) to use Configuration. The database extensions I did for Resources are specific to Resources, but that can be changed if enough people think we should do that. I can see how Resources, I18N, and Configuration could play nice together in providing i18n'd messages and configuration data. Would there be any interest in such an animal? -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Benedict, Paul C [EMAIL PROTECTED] To: 'Struts Users Mailing List' user@struts.apache.org Sent: Thursday, April 07, 2005 9:59 AM Subject: RE: RESEND: RE: Load message resources from DB??? James, How much different is Common Resources from Common Configuration? In essence, a property file is really just a list of configuration pairs. Thanks, Paul -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 06, 2005 4:22 PM To: Struts Users Mailing List Subject: Re: RESEND: RE: Load message resources from DB??? - Original Message - From: Fogleson, Allen [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org; [EMAIL PROTECTED] Sent: Wednesday, April 06, 2005 2:40 PM Subject: RE: RESEND: RE: Load message resources from DB??? Yes there is the OJBMessageResource class and I believe the same author wrote a HibernateMessageResource class. The class I wrote is mostly a JNDIJDBCMessageResource which has a timeout cache attached to it. The config is comprised of three elements (comma separated) 1) The JNDI Name of the datasource to use that maps to a table. 2) The sql to use basically this sql relies on the fact that variable 1 is the locale, and variable 2 is the key . 3) The time that the cached value previously retrieved from the DB is valid. If this is 0 timeout is never. The ones mentioned in Bill's book are very good implementations but I feel that it is sometimes nicer to have an implementation that does not add extra class libraries (i.e. OJB or Hibernate). If you are already using one of those in your app I would say then use those Message Resource extensions, but if you want something relatively simple that just uses standard J2EE and the struts libs then use mine. (I really should get it up on a site somewhere :) Hi, I wrote OJBMessageResources a while back and it has not been updated since it was last published. Struts will soon be changing (1.3.something) the internal mechanism from MessageResources/PropertyMessageResources (and factory) to commons-resources. That's why I wrote 3 implementations for commons-resources: HibernateResources IBatisResources JDBCResources (not in CVS yet) http://cvs.sourceforge.net/viewcvs.py/struts/commons-resources- optional/ These are not released (because commons-resources has not been released, but it is out of the sandbox, which is a good thing), but I will publish and announce the extensions when it get's the 1.0 stamp of approval. Al Thanks. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive,
RE: Moving benchmark out of sandbox?
I took a spin around benchmark, and it looked good however.. I think you need some sort of tutorial and demo. Unlike other tools like email,lang, which are very obvious how you use them (Answer: you write code with them!), benchmark is more of a tool. There were references to other tools that I didn't quite get, and maybe some sort of sample report would be good. Maybe run benchmark against the tomcat codebase or something. On a certain level, if my understanding is right that benchmark is a tool, not a library, I somewhat wonder if this shouldn't be out from under commons and part of some sort of jakarta project instead? Building community is tough from the sandbox. However, I have done it with Configuration, (which is really thriving), and to a certain extent with Email, although I need to get some of the contributors voted in as committers. When people express interest, grab 'em! Ask for feedback, take their concerns seriously, and pretty soon you'll be getting patches! Eric -Original Message- From: Kevin A. Burton [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 15, 2005 4:50 AM To: Jakarta Commons Developers List Subject: Re: Moving benchmark out of sandbox? Dion Gillard wrote: Using nightly builds? Thats a step in the right direction I guess ;) I'll setup nightly builds and then blog about the benchmark package and what you can do with it... then build really nice javadoc. I guess I'm getting ahead of myself because I want to integrate it within FeedParser :) Thanks! Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - 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] [email] promote RC4 to 1.0 status
Ugh. Cygwin. Fast way to frustration on windows.. Actually, I just got my new powerbook, so theoretically I can run MacPGP from http://macgpg.sf.net and do it. However, when I generate a new keypair, that means that I'll either have two keypairs, or I just don't use the first one anymore? I haven't signed anything else with it, and haven't cross signed it at all, so theorectically moving to a new keypair is fine, correct? Eric -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, March 14, 2005 6:51 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] [email] promote RC4 to 1.0 status The gpg docs are here http://www.gnupg.org/gph/en/manual.html and yes, you need to generate a keypair first before trying to sign something. I don't know if it is ok to gen and store keys on apache boxes, though. Anyone know? If you can get Cygwin or something equivalent that lets you run gpg and shell scripts locally, you can use the scripts that I added to /committers/releases to create and verify the sigs once you have created the keypair using gpg --gen-key hth, Phil On Mon, 14 Mar 2005 09:56:17 -, Eric Pugh [EMAIL PROTECTED] wrote: I was taking a swing at ascii armour'ing the signatures, and have a couple questions. Following the directions in http://wiki.apache.org/jakarta-commons/SigningReleases, there is a section about using gpg. I logged onto my Apache account, and tried to do the command: gpg --armor --export 'your name' However, nothing gets produced. What I am wondering is if I need to somehow install my key? I followed the PGPMail directions, so my private key is on my windows laptop. Do I need to create using gpg my main key instead? There are some tantalizing mentions in PGPMail's documentation about ascii armouring, but no details on how to do it, just that it exists. Eric -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Friday, March 11, 2005 9:01 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] [email] promote RC4 to 1.0 status hi eric could you ascii armour the signatures? (it's not essential but it makes them a lot nicer to read and download) - robert On Fri, 2005-03-11 at 20:30, 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] - 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: [configuration]Site update of howtos
Over in Turbine land we have the advantage of a separate turbine-site project. We have generic site doucmentation, and then the maven generated docs seperated by version: / generic site docs /2.3 /2.3.1 /2.4-M1 And so on. What we could do is have /commons/configuration/ - current site docs symlinked to /commons/configuration/1.0 /commons/configuration/1.1/ -- new site docs /commons/configuration/1.0/ -- old site docs And provide a link to the 1.1 and 1.0 from both projects Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 15, 2005 8:28 PM To: Jakarta Commons Developer List Subject: [configuration]Site update of howtos Our current site seems to be very confusing for our users as can be seen in multiple postings on the user list. The main reason is probably the user guide (the howtos), which describes the latest version in SVN rather than the 1.0 release, which is used by most users. I have now applied a quick and dirty fix for this situation: I manually uploaded the 1.0 howtos on the server. Then I created two index pages for the old and new howtos and linked to them in the main navigation bar, analogous as for the API docs. In the index page for the SVN howtos there is an explicit warning that this may not be compatible with the latest released version. This is of course only a temporary solution because it requires manual processing on the server. I don't know how we should deal with this problem. Would it make sense to store both the old and new howtos in the xdocs and let maven generate it all? I guess that would be the easiest way. Oliver - 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] [email] promote RC4 to 1.0 status
I was taking a swing at ascii armour'ing the signatures, and have a couple questions. Following the directions in http://wiki.apache.org/jakarta-commons/SigningReleases, there is a section about using gpg. I logged onto my Apache account, and tried to do the command: gpg --armor --export 'your name' However, nothing gets produced. What I am wondering is if I need to somehow install my key? I followed the PGPMail directions, so my private key is on my windows laptop. Do I need to create using gpg my main key instead? There are some tantalizing mentions in PGPMail's documentation about ascii armouring, but no details on how to do it, just that it exists. Eric -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Friday, March 11, 2005 9:01 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] [email] promote RC4 to 1.0 status hi eric could you ascii armour the signatures? (it's not essential but it makes them a lot nicer to read and download) - robert On Fri, 2005-03-11 at 20:30, 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] - 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: [ANN][configuration]Release candidate 1.1RC2
Thanks for the tip.. This also solved my last issues with packaging
email. (I hope :-) ).
Eric
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Monday, March 07, 2005 8:00 PM
To: Jakarta Commons Developers List
Subject: Re: [ANN][configuration]Release candidate 1.1RC2
Oliver Heger wrote:
NOTICE.txt is missing from source and binary distros and jar.
Not sure about this. I used maven dist to build the distros. Do I have
to tweak the maven.xml so that this file gets included?
To get it into the jar, add it as a build resource in project.xml:
resources
resource
directory${basedir}/directory
includes
includeNOTICE.txt/include
/includes
targetPathMETA-INF/targetPath
/resource
/resources
To get it into the top-level directories, you need to tweak maven.xml.
Here is one way to do it:
preGoal name=dist:build-bin
copy todir=${maven.dist.bin.assembly.dir}
fileset file='${basedir}/NOTICE.txt'/
/copy
/preGoal
preGoal name=dist:build-src
copy todir=${maven.dist.src.assembly.dir}
fileset file='${basedir}/NOTICE.txt'/
/copy
/preGoal
hth,
Phil
-
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]
[VOTE] [email] promote RC4 to 1.0 status
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]
RE: [VOTE] Release commons email 1.0
Okay...
I have fixed the NOTICE.txt in the jar at the top level not being in the
META-INF. However, I can't seem to get the NOTICE.txt in the top level
of either the src or binary distributions. The postGoal in commons
build here doesn't seem to run. No xdocs, no jars, no NOTICE.txt...:
postGoal name=dist:prepare-src-filesystem
j:set var=maven.dist.src.assembly.dir
value=${pom.getPluginContext('maven-dist-plugin').getVariable('maven.di
st.src.assembly.dir')} /
!-- Copy Files --
ant:copy todir=${maven.dist.src.assembly.dir}
ant:fileset dir=.
ant:include name=NOTICE.txt/
/ant:fileset
/ant:copy
!-- Copy Jars --
ant:copy todir=${maven.dist.src.assembly.dir}
ant:fileset dir=${maven.build.dir}
ant:include name=*.jar/
/ant:fileset
/ant:copy
!-- Copy XDocs --
ant:copy todir=${maven.dist.src.assembly.dir}/xdocs
ant:fileset dir=xdocs /
/ant:copy
/postGoal
To what extent is the NOTICE.txt a mandatory requriement? TO me, it
looks just like the LICENSE.txt...
And, in the interests of finally getting a release out, especially since
we have the required +1 votes, can I just add the file by hand? Icky, I
know, but...
Eric
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
I am using 1.8.1. However, I just found out that the darn jars aren't
supposed to be on ibiblio. I checked on the maven mailing list and
found out it was a problem. Silly me for bringing it up.. So now I
need to rollback to the older version.
Does the 1.9-SNAPSHOT help this situation of non redistributable jars?
Eric
-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 03, 2005 9:42 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [VOTE] Release commons email 1.0
Do you use the ant plugin 1.8.1 for maven or the 1.9-SNAPSHOT ?
Arnaud
-Message d'origine-
De : Eric Pugh [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 3 mars 2005 16:48
À : 'Jakarta Commons Developers List'
Objet : RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the
Maven Ant
plugin, it may be that the hand tweaking is no longer
required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I
am going to regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little
changes today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with
MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the
regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the Maven Ant
plugin, it may be that the hand tweaking is no longer required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I am going to
regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little changes
today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
Okay..
I'll take care of those changes.
The build.xml could definitly be out of date.. It has been patched a
couple times by hand, and then we have had those patches get wiped out
by the Maven build. Recently some patches were added to the Maven Ant
plugin, it may be that the hand tweaking is no longer required. Did
you get this error: no protocol: ${javamail-1.3.2.url}? I am going to
regenerate the Maven one and commit it.
I have tweaked the docs, I'll try and tackle the other little changes
today.
Eric Pugh
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 3:49 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Release commons email 1.0
+1 modulo the following nits:
* Binary distro includes NOTICE.txt in the jar (top level, should
probably be with LICENSE.txt in META-INF) but not in the top level
directory of the distribution.
* Source distro does not include NOTICE.txt
* Ant build.xml in source distro fails with MalformedURLException in get
deps. When I regenerated the build.xml using maven ant, the regenerated
build.xml worked. Could be build.xml is out of date?
* Make sure to update the repo link on the web site to point to svn.
Phil
robert burrell donkin wrote:
On Tue, 2005-03-01 at 06:58, Eric Pugh wrote:
[X] +1 Lets release commons-email, it's been too long!
[ ] 0 Commons-what? Not ready for release
[ ] -1 Don't release. I can't get dumbster (replace with your
reason) to work.
BTW i've checked the sums and signatures
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release commons email 1.0
The only open bug/enhancement is 32900: http://issues.apache.org/bugzilla/show_bug.cgi?id=32900. It is quite clearly an enhancement that is post 1.0, and there is some discussion on the bug list of whether it fits into the commons-email charter. Eric Pugh -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 3:24 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release commons email 1.0 Are there any open bugs/enhancements? On Tue, 1 Mar 2005 09:01:03 -0800, Eric Pugh [EMAIL PROTECTED] wrote: My +1 of course! [X] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Addition for DataUtils
I need the same logic.. Is it something you can share/ post to the
bugzilla?
Eric
-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 01, 2005 11:43 AM
To: Commons Developer
Subject: [lang] Addition for DataUtils
Hello... I just had to whip up a function that might be useful...
The situation was that I needed to determine if the current time fell
within a given range. The complication is that the range could span a
day, i.e., the range might be 2000-0800 (24 hr. times).
So I threw together
static boolean isTimeInRange(int rangeStart, int rangeEnd, int
timeToCheck);
...the idea being that someone would do something like:
int now = 100 * new GregorianCalendar().get(Calendar.HOUR_OF_DAY);
if (isTimeInRange(800, 2000, now)) {
// in range
}
I'm wondering if that sounds like a good edition to DateUtils?
If so, I'll create some overloaded versions (to accept actual Calendars
and probably Strings in addition to ints, and mixtures of all three,
perhaps 12-hour times too), solidify and clean up the code, throw
together a unit test and post it to Bugzilla.
Any thoughts? Part of me expects to hear this already exists somewhere,
but I didn't find it in DateUtils, which strikes me as the logical
place. Thanks all!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.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: [VOTE] Release commons email 1.0
My +1 of course! [X] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][configuration]Release 1.1
I'll take a loo at the latest as well, I need to update some dependencies anyway for Turbine! -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 12:09 PM To: Jakarta Commons Developers List Subject: Re: [VOTE][configuration]Release 1.1 Strange! Okay, I would like to have a look at bug 33723 and maybe add a unit test that checks for absolute path names (to be sure). 33691 is open, too, but I think this has been more or less solved in the meantime. Here we could only modify the constructor of SubsetConfiguration that does not take a delimiter as argument to set the default delimiter. And we could prevent trailing dots in the prefix. I hope I come to these things tomorrow. Then it's time for the second RC! Oliver Emmanuel Bourg wrote: Emmanuel Bourg wrote: I haven't had a chance to test it yet, I should have some time this week. Ok I checked again my application with the latest nightly build and it worked fine. I don't know what happened the last time I updated my commons configuration jar... I'm +1 for a 1.1-rc2 release followed by a final 1.1 Emmanuel Bourg - 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]
[VOTE] Release commons email 1.0
Hi all, The commons-email RC3 release has been available for a couple days, and has isn't fundamentally changed from the RC2 release that has been out for a couple months. I'd like to move to releasing the code here: http://www.apache.org/~epugh/email/distributions/ as commons-email-1.0. Documentation is available at http://www.apache.org/~epugh/email/docs/. Assuming this vote passes, my plan is to rename the jars, and then deploy them, as well as tag the 1.0 based on the RC3 tag in SVN. [ ] +1 Lets release commons-email, it's been too long! [ ] 0 Commons-what? Not ready for release [ ] -1 Don't release. I can't get dumbster (replace with your reason) to work. Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][configuration]Release 1.1
You didn't break fulcrum.. Fulcrum Configuration is built by Gump against the CVS head, so the API change between 1.0 and 1.1 of commons-configuration cause compile errors. The sooner we can get a release out, the better.. I'll try next week to see if I can help! Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Friday, February 18, 2005 1:53 AM To: Jakarta Commons Developers List Subject: Re: [VOTE][configuration]Release 1.1 Welcome back, Eric! We were trying to get a 1.1 release out, but this is halted now because of problems in the reloading area. In which way did we break Fulcrum? Oliver Eric Pugh wrote: Folks, I have been really tied up in real life since before Christmas, but life has started calming down. I'll be looking at getting reinvolved again in the commons projects that are near and dear to my heart! For what it's worth, I am very excited about getting another rev of configuration out. (that and gump has been complaining about Fulcrum Configuration and the new API!). Eric -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 2:16 PM To: Jakarta Commons Developers List Subject: Re: [VOTE][configuration]Release 1.1 FWIW i've never regretted holding a release and i think the right decision's been made. - robert On Thu, 2005-02-10 at 19:43, Oliver Heger wrote: Of course, I don't want to force a release out which is not mature. Let's hold it. But I feel a bit disappointed that it seems to be so hard to get the required three +1s. I think we must be careful that we do not lose our momentum :-( Oliver Emmanuel Bourg wrote: I'm actually -1 for the release, I dropped the 1.1rc1 jar in my application yesterday and it broke with an exception related to the configuration reloading stuff. This may be linked to the issue reported by Jurgen Schlierf on the commons-user list. I'd like to investigate this bug before releasing the final 1.1. Emmanuel Bourg Oliver Heger wrote: Hi all, we need another +1 to get our release out. Nobody? Oliver Oliver Heger wrote: Dear community, since the 1.0 release of [configuration] a couple of new features have been added. The code base has been stable for a while now, so I think it is time to cut out a new 1.1 release before we start to implement further features and refactorings. A complete list of changes since the 1.0 releaes can be found here: http://jakarta.apache.org/commons/configuration/changes-report.html I have created a release candidate, which can be inspected at http://www.apache.org/~oheger/commons-configuration-1.1rc1/ (the tag for 1.1RC1 is named CONFIGURATION_1_1RC1). Here is my +1! Oliver - 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] -- Dipl.-Inform. Oliver Heger Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren Klinikum der Philipps-Universität Marburg Baldingerstraße, D-35037 Marburg Tel: +49 6421 28-66923 mailto:[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]
[email] Release Candidate 3 posted!
Hi all, I have posted posted Release Candidate 3 of commons-email. The only code change from Release Candidate 2 was the change of some ArrayList to List in method signatures and some javadoc cleanup. It is tagged as EMAIL_1_0_RC3. I have attempted to go through the signing process, however, this is my first time, so please help me validate this! I'd like to get a consensus from the community on how long to leave RC3 up, and then call for a 1.0 vote based on the RC3 code. You can download and try out the distributions (and the signing stuff) here: http://www.apache.org/~epugh/email/distributions/ The documentation is available here: http://www.apache.org/~epugh/email/docs/ I'd like to get this to 1.0, as I've been sitting on the RC2 version for over two months (no good excuse why :-( ). Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: AW: AW: [proposal] avoiding jar version nightmares
I have to jump into this as well. I hope I am not just repeating what wiser minds have already said :-). The idea of changing package names just seems like a solution that looks simple, but will rapidly become a nightmare. As far as I know, no other set of libraries follow this pattern, including the Java libraries, and I think this suggests that doing this isn't wise. And, in my experience watching work done with tools like Gump, any time people do weird trickery with package names, like Sun renaming some packages from x.y.z to com.sun.x.y.z, this inevitably seems to cause lots of problems somewhere down the line. Additionally, people will soon start writing tools similar to commons-logging that attempt to put a facade over all the versions so you don't have to know which version you are working with. I understand why it is a problem, but it seems like a better solution is to pressure app vendors to upgrade faster (by using tools like Gump that demonstrate the newer versions are solid against many packages) as well as implement classloader isolation. Eric -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Sunday, December 19, 2004 5:28 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: AW: AW: AW: [proposal] avoiding jar version nightmares On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann [EMAIL PROTECTED] wrote: On Sun, 19 Dec 2004 22:17:10 -, Stephen Colebourne [EMAIL PROTECTED] wrote: I would also -1. Versioned packages is not an acceptable solution. What is an acceptable solution then? Do what I said already ... create subordinate class loaders *within* your application, and load the offending subordinate modules into their own class loaders, with their own dependencies. Oliver Craig - 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]
[configuration] Cut timestamped version of configuration?
Hi all, I noticed that there is a directory (can't quite remember now) on the cvs.apache.org where timestamp/non official releases are put. This directory is NOT synced to ibiblio. I'd like to cut a timestamped version and put it there because I would like to add to Fulcrum configuration a dependency on it. Right now Fulcrum Configuration (a tool to load up a Configuration as an Avalon component) fails due to API differences in Gump: http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-con figuration-impl/index.html The way to fix it is to either cut a release or publish a timestamped version that Fulcrum Configuration can depend on... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][EMAIL] Release Commons-Email 1.0
I checked a couple other of the mavenized projects, and they didn't seem to put NOTICE.txt in the distribution. Primarily because the primary distribution method seems to by just putting out a jar file and syncing that to ibiblio. Dion, I did try to get NOTICE.TXT in the dist, instead of putting it in the jar file in the distribution, but no luck. Is there something obvious I am missing? Eric -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 15, 2004 5:47 AM To: Jakarta Commons Developers List Subject: Re: [VOTE][EMAIL] Release Commons-Email 1.0 Shouldn't NOTICE.TXT be in the distribution? On Fri, 3 Dec 2004 18:08:50 +0100, Eric Pugh [EMAIL PROTECTED] wrote: 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] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][EMAIL] Release Commons-Email 1.0
I apologise for the delay, I had an unexpected trip to take. At this point I have updated the jar file in the distributions to have the NOTICE.txt, and renamed them commons-email-rc2. If Stephen changes his -1 to a +1 then I count 5 +1's and 2 +0's, and would like to move to an immediate release in 24 hours. Eric -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, December 04, 2004 4:51 PM To: Jakarta Commons Developers List Subject: Re: [VOTE][EMAIL] Release Commons-Email 1.0 -1 Please add NOTICE.txt to all zip files and the jar file. Then you can have a +1 ;-) Stephen - Original Message - From: Eric Pugh [EMAIL PROTECTED] To: Commons-Dev [EMAIL PROTECTED] Sent: Friday, December 03, 2004 5:08 PM 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] getProperty vs getPropertyDirect
Per my other email, can we use a better name? maybe something like interpolateProperty? It doesn't have to be a JavaBean style getter since we don't expect it to be called by external tools.. -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Friday, December 03, 2004 10:16 AM To: Jakarta Commons Developers List Subject: Re: [configuration] getProperty vs getPropertyDirect Sorry Olivier I should have waited a bit more before comiting the change :/ I have no problem reintroducing getPropertyDirect at a later time if you find an interesting use case. Emmanuel Bourg Oliver Heger wrote: After seeing the commit mails I may be a bit late. I had some ideas about extending the interpolation mechanism to support other data types than string, too. For this use case the separation of getProperty() and getPropertyDirect() would be nice, as getProperty() being a generic hook that allows for manipulation of properties (like interpolation) before they are delivered to the caller. But this was nothing concrete yet. Oliver - 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]
[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]
RE: [VOTE] Matthew Inger as Commons Committer Re: [Lang] Commit Karma
+1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] getProperty vs getPropertyDirect
At one time we had all sorts of abstraction somewhere in there.. I think for example JNDIConfiguration supported removing properites by holding them in a temporary list of properties that had been removed. If getProperty() found that the list had a property with that name, then it returned null, otherwise it called getPropertyDirect which ACTUALLY returned the property. Icky, I know, and getting rid of it has my earnest +1! Just the similiarity of the names always seemed like a code smell to me. Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Thursday, December 02, 2004 6:51 PM To: Jakarta Commons Developers List Subject: [configuration] getProperty vs getPropertyDirect Dumb question of the day : what's the usefulness of getPropertyDirect ? I cleaned a bit the code by removing the redundant getProperty implementation in CompositeConfiguration and JNDIConfiguration, now the only implementation left is in AbstractConfiguration and it delegates directly to getPropertyDirect. So at this point it seems getPropertyDirect is no longer necessary, I suggest merging it into getProperty. Emmanuel Bourg - 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: [collections] InvokerClosure
Is the final result:
CollectionUtils.forAllDo(configList, new InvokerClosure(clearProperty,
String.class, key));
Compared to the original really that much cleaner?:
for (Iterator i = configList.iterator(); i.hasNext();)
{
Configuration config = (Configuration) i.next();
config.clearProperty(key);
}
Things like this are cool.. But.. within the context of java, they just
seem more difficult to read.. Requiring the user to know what an
InvokerClosure is and does. It's neat.. I just haven't seen the use case
that requires it...
Eric
-Original Message-
From: Emmanuel Bourg [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 02, 2004 6:17 PM
To: Jakarta Commons Developers List
Subject: [collections] InvokerClosure
Hi all, I decided to play a bit with closures today and tried replacing
a trivial loop in [configuration] :
for (Iterator i = configList.iterator(); i.hasNext();)
{
Configuration config = (Configuration) i.next();
config.clearProperty(key);
}
I thought a closure would help reducing the code, but actually I ended
with something much longer :
CollectionUtils.forAllDo(configList, new TransformerClosure(new
InvokerTransformer(clearProperty, new Class[] { String.class }, new
Object[] { key })));
Then I found the invokerClosure method in ClosureUtils, the code turned
into :
CollectionUtils.forAllDo(configList,
ClosureUtils.invokerClosure(clearProperty, new Class[] { String.class
}, new Object[] { key }));
Slightly better but still quite long. Why is there no InvokerClosure
class ? This is the only closure in ClosureUtils that has no
corresponding class, this could make the code a bit shorter:
CollectionUtils.forAllDo(configList, new InvokerClosure(clearProperty,
new Class[] { String.class }, new Object[] { key }));
Also the Class[] and Object[] are quite cumbersome, that would be nice
to add methods/constructors to invoke simple methods with only one or
two parameters. Thus my example could look like this:
CollectionUtils.forAllDo(configList, new InvokerClosure(clearProperty,
String.class, key));
which is much more readable.
What do you think ?
Emmanuel Bourg
-
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] Exceptions
ByteArrayDataSource needs a test or two.. Aside from that, maybe check over
the docs and the javadocs. I am thinking we do an RC on thursday, give it a
week, and roll next week?
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 30, 2004 1:38 PM
To: Corey Scott
Cc: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: Re: [email] Exceptions
What needs to be done for 1.0 then? Give me a list and i'll put some
time aside to pitch in.
On Tue, 30 Nov 2004 20:35:48 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
Definately something we should add to our discussion list once 1.0 is
out of the way.
-Corey
On Tue, 30 Nov 2004 10:32:28 +0100, Mark Lowe [EMAIL PROTECTED] wrote:
I'll put the exception tests in with the the others, when its all in.
I left most the tests untouched anyhow just testing for EmailException
rather than MessagingException. Once EmailException is in the head
version I'll start thinking about AddressException.
Has the issue of bulk mailing comeup before? I'm thinking of a class
that extends thread and then sends a email report to a specified email
address reporting which have been sent and those that haven't. Does
this fall within the scope of commons email? Email could even extend
thread and then just use the run method when needing to mail to lots
of folk.. This would be handy for webapps where the time it takes to
send mail exceeds the time for the request-reponse cycle.
HtmlEmail email = ..
..
email.batchMail();
public void batchMail() {
this.run();
}
public void run() {
try {
send();
} catch (SomeExceptionn e) {
}
}
Or would something else be a better idea? Perhaps a separate class
EmailSender or something?
Mark
On Tue, 30 Nov 2004 11:38:30 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
Sounds good to me, I have a stack of things waiting for the
next version.
Also I think most of the bugs have been cleared off by your recent
commits so there shouldnt be any reason to stop us from a RC1
-Corey
On Mon, 29 Nov 2004 19:01:00 +0100, Eric Pugh
[EMAIL PROTECTED] wrote:
I've applied a stack of changes, including Mark's
EmailException, to the
codebase. I don't really care much about how the unit
tests look, as long
as the jcoverage keeps going up!
At this point, I think all the API changes are done, and
my gut feeling is
that we should look to final testing, cut a Release
Candidate and then roll
1.0. We should also start thinking about what the next
version will entail.
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 5:25 PM
To: Corey Scott
Cc: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: Re: [email] Exceptions
Okay I'll take a look tommorrow and sumbit my patch
with the test
cases in with the Other test methods.
Judging from you example, you agree that unexpected
exceptions should
just get thrown and that exceptions should be tested
independently to
normal tests, which all sounds good to me. Or am i wrong? If the
method isn't there to invoke an exception then if one
happens then
surely just throw it, the fact that its unexpected will
be evident by
virtue of the test failing due to errors.
Mark
On Tue, 30 Nov 2004 00:04:16 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
This is exactly what I was trying to say, just not so
elegantly :-)
Eg. Tests for the HtmlEmail class should be in teh
HtmlEmailTest class
or is this becomes too big and you want to separate
the exceptions,
then there should be two classes HtmlEmailTest (for
normal test cases)
and HtmlEmailExceptionTest
-Corey
On Mon, 29 Nov 2004 16:59:29 +0100, Eric Pugh
[EMAIL PROTECTED] wrote:
Humm... I typically make all my unit tests throw
Exception.
It reduces
the length of each test, especially when all you
are doing is
logging that
it failed with a fail(ex.getMessage).
However, if you are actually TESTING that an
exception gets thrown:
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
then I argue they should go in with whatever class we are
testing, because
when someone adds a new method to the class, it will
encourage them to add
the corresponding test case for any exeption. Or, put the
exception test
into the test.
public void testSomething
RE: cvs commit: jakarta-commons/chain/src/java/org/apache/commons/chain/web/servlet ChainProcessor.java ServletApplicationScopeMap.java ServletHeaderValuesMap.java ServletRequestScopeMap.java ServletSessionScopeMap.java
I'd guess that the JSF jar's are not distributable on IBiblio, just like the JavaMail ones? ERic -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 7:00 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-commons/chain/src/java/org/apache/commons/chain/web/servlet ChainProcessor.java ServletApplicationScopeMap.java ServletHeaderValuesMap.java ServletRequestScopeMap.java ServletSessionScopeMap.java On Tue, 30 Nov 2004 00:06:52 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: -1 Besides the fact that this change bundle breaks the ant clean dist command that is necessary for the current ngihtly build scripts to work I don't believe that's why the build broke. The problem is that, for some reason, the JSF jar files have disappeared from ibiblio. I don't know how to fix that. , it alters the semantics with changes like this: How does it change the semantics? All of 'public', 'static' and 'final' are redundant here, because this is an interface. -- Martin Cooper Index: Catalog.java === RCS file: /home/cvs/jakarta-commons/chain/src/java/org/apache/commons/chain/ Catalog.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- Catalog.java 25 Feb 2004 00:01:07 - 1.6 +++ Catalog.java 30 Nov 2004 05:52:22 - 1.7 @@ -37,7 +37,7 @@ * pA default context attribute for storing a default [EMAIL PROTECTED] Catalog}, * provided as a convenience only./p */ -public static final String CATALOG_KEY = org.apache.commons.chain.CATALOG; +String CATALOG_KEY = org.apache.commons.chain.CATALOG; /** Craig - 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: Cleanup questions from importing email
Craig, Joe Germuska (details below) was a sandbox committer for email: developer nameJoe Germuska/name idgermuska/id email[EMAIL PROTECTED]/email /developer Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction][resources] Gump Build Fixed
Hi guys, I move the gump project file from jakarta-commons-sandbox.xml to jakarta-commons.xml. You should be notified of a success/failure later today. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Exceptions
My take on this is that users of [email] are looking for a package that simplifies the JavaMail api. And one of the big simplifing aspects is that the Exceptions that they have to catch are minimized. Most users will probably not care *what* the exception was, only that there *was* an exception, and just pass it up the chain. For folks who actually have code to deal with the specific exception, then they are either going to use the JavaMail api directly without the extra layer of [email], or we should provide a way for them to retrieve the specific Exception. Hence that is why I propose that we have two types of exceptions: EmailException and RuntimeEmailException. For common exceptions, we throw an EmailException which is an extension of NestableException and wraps whatever the underlying JavaMail exception was. This provides a nice facade for people who don't care what the exception was, but allows folks who do to get the underlying exception. The other RuntimeEmailException will extend NestableRuntimeException and can be used for any runtime exceptions in the same manner as EmailException. For the case of the UEE, that would be another exception in the API to throw, which goes against the charter that: contains a set of Java classes providing a thin convenience layer over JavaMail. So, in that case, throw the approapriate EmailException and that will wrap the UEE. Mark, is it possible to use the 1.4 io stuff conditionally? I guess not, but we could think about maybe how we compile the jar? Our primary target is definitly 1.3 for now though. Eric -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 4:04 PM To: Commons dev list; Corey Scott Subject: [email] Exceptions The issue of exceptions has come up a few times, and heres a summary of my understanding of whats been said and agreed and disagreed about. The idea of throwing AddressException is favourable, but not at the cost of needing to throw UnsupportingEncodingException. When setting InternetAddress() this throws a UEE and AddressException. My position is that without 1.4's new io package there's no means of checking supported charsets on a given JVM. If the user enters a shady charset for a email address or name is there anything wrong with them having a UEE thrown? The lightest means of doing this in my opinion is just throw both, its consistent with the mailapi. It would work on all target JVMs. Of course you could just throw MessagingException for everything , oh thats what it does. But is this a useful and therefore good thing? Having a commons.mail.EmailException was suggested, but does that have any advantage over throwing AddressException and UEE? I'm not sure. I don't mind summitting the patches, i need to do this for a project I'm working on at present, so I need to do the work anyway. It makes sense to submit this to the effort but I don't mind either way. Mark - 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] Exceptions
Humm... I typically make all my unit tests throw Exception. It reduces
the length of each test, especially when all you are doing is logging that
it failed with a fail(ex.getMessage).
However, if you are actually TESTING that an exception gets thrown:
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
then I argue they should go in with whatever class we are testing, because
when someone adds a new method to the class, it will encourage them to add
the corresponding test case for any exeption. Or, put the exception test
into the test.
public void testSomething() throws Exception{
email.doSomethign();
snip/
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
}
That way everything stays together. If we aren't actually asserting the
exception, then we shouldn't bother testing it..
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 3:19 PM
To: Corey Scott
Cc: Jakarta Commons Developers List
Subject: Re: [email] Exceptions
My thoughts on the test cases are that they should throw exception,
and then have the exception testing separate. This would make the
cases shorter also, perhaps this is what you mean.
public void testFoo() throws Exception
{
Foo foo = new Foo();
foo.setBar(testvar);
}
For example, if for some reason the exception for setBar() was ever
changed the case could remain the same as before, and the only change
would need to be in the exception test case.
Mark
On Mon, 29 Nov 2004 21:59:44 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
I would prefer an Exception Test case per base class, especially for
the larger files. I know most of the tests I wrote, but I think that
if anything the files are too long and would be much more usable if
they were shorter and more focused. Does anyone have any objections
to gave more (but shorter) files?
-Corey
On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe [EMAIL PROTECTED] wrote:
I've created the exceptions and I'm now working through the
test cases.
If I summit a patch with the exception testing in a ExceptionTestCase
what's the likelyhood of this being patched? This isn't a question of
style its a question of maintainabilty and now, I'm faced with the
task of weeding out all these try catch statements.
Any objection to a patch with these exception tests moved into a
specialised test case?
Mark
On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe
[EMAIL PROTECTED] wrote:
Okay 2 commons.mail exceptions sounds like an improvement.
So the goal
is to minimise the catch statements the user needs to use, sound
reasonable. Throwing everything would mean 2 catches, so I
can see the
value in catching once.
I'll look into a way of having a 1.4+ build option in the
build files
for folk that don't give a gnat's winnit about 1.3 et al.
Anyone know the default behaviour for the
InternetAddress(email,name)
constructor? Does it adopt the charset from the parent email?
Mark
On Mon, 29 Nov 2004 11:11:06 +0100, Eric Pugh
[EMAIL PROTECTED] wrote:
My take on this is that users of [email] are looking for
a package that
simplifies the JavaMail api. And one of the big
simplifing aspects is that
the Exceptions that they have to catch are minimized.
Most users will
probably not care *what* the exception was, only that
there *was* an
exception, and just pass it up the chain. For folks who
actually have code
to deal with the specific exception, then they are either
going to use the
JavaMail api directly without the extra layer of [email],
or we should
provide a way for them to retrieve the specific Exception.
Hence that is why I propose that we have two types of exceptions:
EmailException and RuntimeEmailException. For common
exceptions, we throw
an EmailException which is an extension of
NestableException and wraps
whatever the underlying JavaMail exception was. This
provides a nice facade
for people who don't care what the exception was, but
allows folks who do to
get the underlying exception.
The other RuntimeEmailException will extend
NestableRuntimeException and can
be used for any runtime exceptions in the same manner as
EmailException.
For the case of the UEE, that would be another exception
in the API to
throw, which goes against the charter that:
contains a set of Java classes providing a thin
convenience layer over
JavaMail. So, in that case, throw the approapriate
EmailException and
that will wrap the UEE.
Mark, is it possible to use the 1.4 io stuff
conditionally? I guess not,
but we could think about
RE: [email] site cleanup
Mark, I think I did the right chmod. Can you just double check? Eric -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 5:08 PM To: Jakarta Commons Developers List Cc: [EMAIL PROTECTED] Subject: [email] site cleanup Eric, If you could change the group permissions recursively on the email site so that it can be updated by others that would be great. Afterwards, I'll be glad to run the site generation to cleanup the existing site. [EMAIL PROTECTED]:/www/jakarta.apache.org/commons/email ls -a -l total 390 drwxr-xr-x 8 epugh jakarta 1024 Nov 25 04:21 . drwxrwxr-x 50 mdiggory jakarta 2048 Nov 28 14:32 .. drwxr-xr-x 4 epugh jakarta512 Nov 25 04:18 apidocs -rw-r--r-- 1 epugh jakarta 26249 Nov 25 04:18 changelog-report.html -rw-r--r-- 1 epugh jakarta 16963 Nov 25 04:18 changes-report.html -rw-r--r-- 1 epugh jakarta736 Nov 25 04:18 changes.rss -rw-r--r-- 1 epugh jakarta 47015 Nov 25 04:18 checkstyle-report.html -rw-r--r-- 1 epugh jakarta 2348 Nov 25 04:18 checkstyle.rss -rw-r--r-- 1 epugh jakarta 13128 Nov 25 04:18 cvs-usage.html -rw-r--r-- 1 epugh jakarta 12762 Nov 25 04:18 dependencies.html -rw-r--r-- 1 epugh jakarta 11780 Nov 25 04:18 developer-activity-report.html -rw-r--r-- 1 epugh jakarta 11908 Nov 25 04:18 downloads.html -rw-r--r-- 1 epugh jakarta 20142 Nov 25 04:18 examples.html -rw-r--r-- 1 epugh jakarta 16455 Nov 25 04:18 file-activity-report.html drwxr-xr-x 3 epugh jakarta 2048 Nov 25 04:19 images -rw-r--r-- 1 epugh jakarta 13248 Nov 25 04:19 index.html -rw-r--r-- 1 epugh jakarta 11379 Nov 25 04:19 issue-tracking.html -rw-r--r-- 1 epugh jakarta 12091 Nov 25 04:19 javadoc-warnings-report.html -rw-r--r-- 1 epugh jakarta 11830 Nov 25 04:19 javadoc.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:20 jcoverage -rw-r--r-- 1 epugh jakarta 36976 Nov 25 04:20 junit-report.html -rw-r--r-- 1 epugh jakarta 22679 Nov 25 04:20 license.html -rw-r--r-- 1 epugh jakarta 12733 Nov 25 04:20 mail-lists.html -rw-r--r-- 1 epugh jakarta 14442 Nov 25 04:20 maven-reports.html -rw-r--r-- 1 epugh jakarta 12984 Nov 25 04:20 pmd-report.html -rw-r--r-- 1 epugh jakarta 13456 Nov 25 04:20 project-info.html drwxr-xr-x 2 epugh jakarta512 Nov 25 04:20 style -rw-r--r-- 1 epugh jakarta 17676 Nov 25 04:20 team-list.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref-test -Mark -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.org - 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] Exceptions
I've applied a stack of changes, including Mark's EmailException, to the
codebase. I don't really care much about how the unit tests look, as long
as the jcoverage keeps going up!
At this point, I think all the API changes are done, and my gut feeling is
that we should look to final testing, cut a Release Candidate and then roll
1.0. We should also start thinking about what the next version will entail.
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 5:25 PM
To: Corey Scott
Cc: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: Re: [email] Exceptions
Okay I'll take a look tommorrow and sumbit my patch with the test
cases in with the Other test methods.
Judging from you example, you agree that unexpected exceptions should
just get thrown and that exceptions should be tested independently to
normal tests, which all sounds good to me. Or am i wrong? If the
method isn't there to invoke an exception then if one happens then
surely just throw it, the fact that its unexpected will be evident by
virtue of the test failing due to errors.
Mark
On Tue, 30 Nov 2004 00:04:16 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
This is exactly what I was trying to say, just not so elegantly :-)
Eg. Tests for the HtmlEmail class should be in teh HtmlEmailTest class
or is this becomes too big and you want to separate the exceptions,
then there should be two classes HtmlEmailTest (for normal test cases)
and HtmlEmailExceptionTest
-Corey
On Mon, 29 Nov 2004 16:59:29 +0100, Eric Pugh [EMAIL PROTECTED] wrote:
Humm... I typically make all my unit tests throw Exception.
It reduces
the length of each test, especially when all you are doing is
logging that
it failed with a fail(ex.getMessage).
However, if you are actually TESTING that an exception gets thrown:
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
then I argue they should go in with whatever class we are
testing, because
when someone adds a new method to the class, it will
encourage them to add
the corresponding test case for any exeption. Or, put the
exception test
into the test.
public void testSomething() throws Exception{
email.doSomethign();
snip/
try {
email.doSomething();
fail(should have thrown ee);
}
catch (EmailException ee){
assertTrue(ee.getMessage().indexOf(myerror)-1)
}
}
That way everything stays together. If we aren't actually
asserting the
exception, then we shouldn't bother testing it..
Eric
-Original Message-
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 3:19 PM
To: Corey Scott
Cc: Jakarta Commons Developers List
Subject: Re: [email] Exceptions
My thoughts on the test cases are that they should throw exception,
and then have the exception testing separate. This would make the
cases shorter also, perhaps this is what you mean.
public void testFoo() throws Exception
{
Foo foo = new Foo();
foo.setBar(testvar);
}
For example, if for some reason the exception for setBar() was ever
changed the case could remain the same as before, and the
only change
would need to be in the exception test case.
Mark
On Mon, 29 Nov 2004 21:59:44 +0800, Corey Scott
[EMAIL PROTECTED] wrote:
I would prefer an Exception Test case per base class,
especially for
the larger files. I know most of the tests I wrote, but
I think that
if anything the files are too long and would be much more
usable if
they were shorter and more focused. Does anyone have any
objections
to gave more (but shorter) files?
-Corey
On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe
[EMAIL PROTECTED] wrote:
I've created the exceptions and I'm now working through the
test cases.
If I summit a patch with the exception testing in a
ExceptionTestCase
what's the likelyhood of this being patched? This isn't
a question of
style its a question of maintainabilty and now, I'm
faced with the
task of weeding out all these try catch statements.
Any objection to a patch with these exception tests moved into a
specialised test case?
Mark
On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe
[EMAIL PROTECTED] wrote:
Okay 2 commons.mail exceptions sounds like an improvement.
So the goal
is to minimise the catch statements the user needs to
use, sound
reasonable. Throwing everything would mean 2 catches, so I
can see the
value in catching once.
I'll look into a way of having a 1.4+ build option in the
build files
for folk
RE: [email] site cleanup
Okay, done.. I tried ls -l email and couldn't get it, I got every directory, but I think I did it correctly. Thanks for the handholding. -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 8:24 PM To: Jakarta Commons Developers List Subject: Re: [email] site cleanup You'll need to change the `email` directory as well drwxr-xr-x 8 epughjakarta 1024 Nov 25 04:21 email thnx again, Mark Eric Pugh wrote: Mark, I think I did the right chmod. Can you just double check? Eric -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 5:08 PM To: Jakarta Commons Developers List Cc: [EMAIL PROTECTED] Subject: [email] site cleanup Eric, If you could change the group permissions recursively on the email site so that it can be updated by others that would be great. Afterwards, I'll be glad to run the site generation to cleanup the existing site. [EMAIL PROTECTED]:/www/jakarta.apache.org/commons/email ls -a -l total 390 drwxr-xr-x 8 epugh jakarta 1024 Nov 25 04:21 . drwxrwxr-x 50 mdiggory jakarta 2048 Nov 28 14:32 .. drwxr-xr-x 4 epugh jakarta512 Nov 25 04:18 apidocs -rw-r--r-- 1 epugh jakarta 26249 Nov 25 04:18 changelog-report.html -rw-r--r-- 1 epugh jakarta 16963 Nov 25 04:18 changes-report.html -rw-r--r-- 1 epugh jakarta736 Nov 25 04:18 changes.rss -rw-r--r-- 1 epugh jakarta 47015 Nov 25 04:18 checkstyle-report.html -rw-r--r-- 1 epugh jakarta 2348 Nov 25 04:18 checkstyle.rss -rw-r--r-- 1 epugh jakarta 13128 Nov 25 04:18 cvs-usage.html -rw-r--r-- 1 epugh jakarta 12762 Nov 25 04:18 dependencies.html -rw-r--r-- 1 epugh jakarta 11780 Nov 25 04:18 developer-activity-report.html -rw-r--r-- 1 epugh jakarta 11908 Nov 25 04:18 downloads.html -rw-r--r-- 1 epugh jakarta 20142 Nov 25 04:18 examples.html -rw-r--r-- 1 epugh jakarta 16455 Nov 25 04:18 file-activity-report.html drwxr-xr-x 3 epugh jakarta 2048 Nov 25 04:19 images -rw-r--r-- 1 epugh jakarta 13248 Nov 25 04:19 index.html -rw-r--r-- 1 epugh jakarta 11379 Nov 25 04:19 issue-tracking.html -rw-r--r-- 1 epugh jakarta 12091 Nov 25 04:19 javadoc-warnings-report.html -rw-r--r-- 1 epugh jakarta 11830 Nov 25 04:19 javadoc.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:20 jcoverage -rw-r--r-- 1 epugh jakarta 36976 Nov 25 04:20 junit-report.html -rw-r--r-- 1 epugh jakarta 22679 Nov 25 04:20 license.html -rw-r--r-- 1 epugh jakarta 12733 Nov 25 04:20 mail-lists.html -rw-r--r-- 1 epugh jakarta 14442 Nov 25 04:20 maven-reports.html -rw-r--r-- 1 epugh jakarta 12984 Nov 25 04:20 pmd-report.html -rw-r--r-- 1 epugh jakarta 13456 Nov 25 04:20 project-info.html drwxr-xr-x 2 epugh jakarta512 Nov 25 04:20 style -rw-r--r-- 1 epugh jakarta 17676 Nov 25 04:20 team-list.html drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref drwxr-xr-x 3 epugh jakarta512 Nov 25 04:21 xref-test -Mark -- Mark Diggory Open Source Software Developer Apache Jakarta Project http://jakarta.apache.org - 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - 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] rm -r lib/*.jar
I did some fixes to the Maven Ant plugin to deal better with overrides. I'll take what you sort out in build.xml and then see if I can support it in the Maven Ant plugin. As long as Email is built primarily by Maven, we will always have problems keeping the Ant script up to date without automation (or lots of attention to detail!). Thanks for the assist.. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Saturday, November 27, 2004 8:05 AM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: [email] rm -r lib/*.jar We appreciate all the help we can get :-) -Corey On Fri, 26 Nov 2004 11:35:04 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: On Fri, 26 Nov 2004 11:14:28 +0100, Eric Pugh [EMAIL PROTECTED] wrote: But, it's not really a big deal. It's only a problem for the nightly build based on Ant, and as long as Gump is happy (which it should be as they are installed as packages) then it doesn't bother me. If the Ant script had properties to define the source URLs for these two JARs, I could point them at my local copies. The license on the JARs in question allows them to be distributed as *part* of a larger package, so my building my own copy into the nightlies is fine ... the license also says you cannot make them available *separately*, which is why having them in CVS doesn't work. Would you guys mind if I hand patched the build.xml file to see if I can get that to work? Eric Craig - 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] rm -r lib/*.jar
It's fine. Can you also do the same trick in jakarta-commons-sandbox/email/libs as well? As I sent in my email to the PMC, I thought the reason those jars are not on ibiblio is that you can't redistribute them via a website. But having them in CVS would be akin to having them in a war file, correct? You can crack open a war file and download the jar the same way you can can go into CVS and checkout just that jar. But, it's not really a big deal. It's only a problem for the nightly build based on Ant, and as long as Gump is happy (which it should be as they are installed as packages) then it doesn't bother me. Eric -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 9:47 PM To: Jakarta Commons Developers List Subject: [email] rm -r lib/*.jar Apologies for treading on people's toes here, but I wanted to get the problem solved quickly, even if it causes a bad build etc. Making sure we're good licence-wise is crucial. Craig raised the issue on the PMC list that the email component had the activation.jar and the javamail.jar in the cvs repository. We're allowed to ship them in distributions, but not to offer them separately (correct me if that's wrong somebody?). Having them in CVS is effectively offering them separately. I've rm-r'd them on the cvs server and modified the build.xml to do the same thing the project.xml does; attempt to grab them from ibiblio and fail. I used rm -r as opposed to cvs remove as they'd still be available with cvs remove. Sorry for not just waiting for the main email committers to read Craig's email from this morning. Given the time of year I'd hate for it to turn out that the 2 or 3 people most likely to fix it are in the US and out late at thanksgiving dinners. Feel free to flame :) Hen - 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: [general] Updating the Commons common web site
This looks better, more consistent! -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 5:16 PM To: Jakarta Commons Developers List Subject: Re: [general] Updating the Commons common web site I ended up updating the site while I was testing ssh keys on my workstation. please review the site and make sure its what you wanted to see updated. -Mark Mark R. Diggory wrote: Martin Cooper wrote: On Thu, 25 Nov 2004 22:17:04 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: I'd verify that if you upload the tar.gz file to minotaur, tar -zxvf it and see if it expands properly. Theres no requirement in the site:deploy method that the file open in Winzip. Yes, I realise that. However, the .tar.gz file is 45 bytes long. I really, really doubt that it contains all of the files needed for the web site... ;-) First, it will only contain the top level site. When I use Maven 1.0 I get a tar ball 179 kb containing all the top level html pages. `maven site:deploy` will publish the tar to the site on minotaur appropriately, you do not have to upload it by hand. There are chances that with newer versions of Maven, that the site build is breaking. I'm sure that works if you can ever get your keys or whatever it is set up so that ssh doesn't want to ask for a password. I have never managed to get that working, and nobody has been able to explain to be - in plain English - what I need to do to get it working. Sounds like your trying to do the build on a Windoz box. I'm always frustrated by this as well, its a problem with the cmd shell and Java, not so much Maven. Reguardless, eventually I setup keys to handle the damn problem. The best option I've found is to use a *nix box to do the build. Regardless, even if Maven managed to upload the 45 bytes, I still don't think we'd have the site updated properly. ;-) true, which version of Maven are you using. Granted I havn't tested the build on anything newer than 1.0 the docs folder is old and I believe the build.xml file in the top level dir is there because Craig uses it to do nightly builds. I wouldn't attempt building the site using this file, you end up creating a mess. OK. Do you have any suggestions on how to get the Maven build in commons-build to create the right .tar.gz for uploading / deploying? You might try setting arguments to the scp/ssh executable to include your username/passwd http://maven.apache.org/reference/plugins/site/properties.html I'll hold off on updating the site, why don't you try to get maven to handle your credentials. -Mark Martin Cooper wrote: The wiki page on promoting projects indicates that certain files need to be updated for the Commons common pages, but doesn't indicate how to build those pages. I've been trying to figure it out, but my attempts have so far failed. Here's what I tried: 1) The Maven build in commons-build seems to generate the right HTML pages. However, the resulting .tar.gz file doesn't contain those pages (and in fact, WinZip thinks it's corrupt). So attempting to deploy from there doesn't work. 2) The 'docs' target in the build file at the top level of Commons fails, because it's looking for ./site.vsl, which doesn't appear anywhere in the jakarta-commons repo. Also, just looking at the build file, it references ../../anakia-project.xml, while that file seems to be present as ./anakia-project.xml. Someone must know how this is supposed to work, since I see that the entries for Email and Transaction now show up in the right place. Can someone enlighten me as to the correct process (and let me know which of the two approaches above are supposed to work, if any, so that I can try to fix them or remove them)? Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - 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 Chain 1.0
While I didn't use the approach that Mailreader-chain used, I found it very *key* to selling me on Chain. So make sure the docs all point to the example in struts-sandbox. Eric -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 11:59 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release Chain 1.0 Does the head include the apps subdirectory? I just checked-in the Mailreader-Chain application to the Struts sandbox, since we'll be using Chain there soon. We could delete MailReader before the 1.0.0 release, but I don't want to do anything to spoil the vote. The other application, Agility, is just a stub at this point. The end-game here would be to show using Chain from a plain-vanilla servlet application. -Ted. On Sun, 21 Nov 2004 15:01:02 -0800 (PST), Martin Cooper wrote: I believe Chain is now sufficiently complete and stable to warrant an official 1.0 release. There are no outstanding bug reports, and the component is already in use in a number of projects. The plan is to release HEAD as Commons Chain 1.0 on completion of a successful vote. I will be the release manager. --- [ ] +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 own +1. -- Martin Cooper - To unsubscribe, e-mail: commons-dev- [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][gump] Currently email is failing in gump
Okay, the change was made. Can you possible remove the older dumbster.jar file as an installed package? Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 9:23 AM To: [EMAIL PROTECTED] Subject: Re: [email][gump] Currently email is failing in gump On Wed, 24 Nov 2004, Eric Pugh [EMAIL PROTECTED] wrote: I'll take a look at trying to get dumbster to build in gump from source. When Stefano installed dumbster on brutus he did so because the source was not available from a public repository. I think he already had the dependencies and Ant invocations correct (just no source tree), just look through older revisions of the dumbster.xml file. 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: 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.java 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]
Cleanup questions from importing email
Hi all, A couple questions about updating the site... 1) Is updating the main commons site automated or not? 2) in jakarta-commons/BUILD_DOCS.txt are some instructions, but they appear to be just to build the main page, correct? I think, but am not sure, that they are out of date, and have been replaced with just running maven site from commons-build? 3) The ASF logo on the top left of the commons site seems to have gone missing, this is an error right? 4) Once I generate the site into /jakarta-commons/commons-build/target/docs then I need to copy the content to jakarta-commons/docs and commit it. What about though the extra files generated by maven that aren't in jakarta-commons/docs. Should they just come over as well. 5) Should the maven site goal copy the new content for you into jakarta-commons/docs? 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. I'll update the wiki based on the feedback I get. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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.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: Bug report normalization
Adding more documentation would be nice for how to submit bugs. There are lots of unenforced rules in commons, like putting the component name in emails. While there are other ways that Emmanuel could have solved the problem, at least now it is resolved. And as we can see by the number of who manages bugzilla that the ideas for changing templates etc will probably remain just that, ideas. While I was surprised by the 300 plus emails, I appreciate Emmanuel going in and trying to clean up/ organize the bug tracker. For me, it really highlighted how MANY bugs we have. It seems like while we are supposed to take a collective ownership role over the various components, it seems like we don't. It looks, just judging by the number of open bugs, that quite a few components have lost their champions. Would this be a good time, now that quite a few components have been promoted etc, to try and do some cleaning of house and fix the bugs? Maybe have each committer take a couple of issues and try and get them to a closed status. Either via won't fix or fixing them? Maybe make next week Bug Week and someone (maybe me) could send out daily stats on how we are doing? Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 6:03 PM To: Jakarta Commons Developers List Subject: Re: Bug report normalization Martin Cooper wrote: I'm sure this has done wonders for the utility of the mailing list archives... I'm not trying to justify myself but the mail archives are already spammed by the CVS commits and the GUMP reports... Reading the archive is definitely not the best way to follow the discussions on the list for an external user. If you really had to do this, it would have been a much better idea to request that the mailer for Bugzilla changes was turned off while you did it. Good idea but this would have affected the other Apache projects using Bugzilla. Maybe deleting the assign to field for the jakarta commons bugs only before the changes and restoring it after would have worked. Who knows how many poor individuals have been spammed with off-list notifications just because they were kind enough to submit bug reports? Worse is the fact that these changes do nothing to solve the problem going forward. Most people will still submit bug reports without the component in the subject. The real solution would be to modify the template used for sending out the messages in the first place, so that the component name is included. Of course, if we do this now, the component name would be included in the subject twice... Good point, maybe we could update the jakarta bug page (http://jakarta.apache.org/site/bugs.html) or put a similar page at the jakarta-commons level explaining the prefered form for bug reports (component name in brackets, test case appreciated, etc...) Emmanuel Bourg - 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][gump] Currently email is failing in gump
This is precisely why the gump folks hate installing a packaged jar instead of building from CVS each jar. Gump has installed dumbster version 1.3, and we are now using 1.5, which has some API changes. (Typo's were fixed). We are NOT using the build-gump.xml, I'll remove it now prior to leaving sandbox. I'll take a look at trying to get dumbster to build in gump from source. If you get motivated, email me what you think the gump script should be.. lots of other SF.net hosted projects are built this way.. I won't get to it till tomarrow however.. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 8:19 PM To: Jakarta Commons Developers List Subject: [email][gump] Currently email is failing in gump [email] is currently failing in gump, it complains about some dumbster methods. Now I took a look at it (read I havent a clue re: gump) and noticed that the build-gump.xml file is 2 years old. Does this mean its not in use? I run the maven gump goal and get a completely different output from this file. Conclusion, I am extremely confused and if anyone could point me in the right direction in regard to how to diagnose and fix the problem, I would greatly appreciate it. Also, I am not sure it is relevant or not, but the email gump build report says dumbster 1.5 and the gump report (common) says 1.3. 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: [VOTE] Release Chain 1.0
We had a similar discussion over in [configuration] prior to 1.0 over having the Configuration interface extend Map. It was great because you could do all sorts of cool tricks with passing configurations into things expecting Maps and still have the code work. Or, an existing application that dealt with a Map of configuration parameters would work seamlessly with the Map derived configuration. However, at the end of it, we felt like it ended up polluting Configuration, adding extra methods that didn't always map to the underlying implementation. So we ended up keeping Configuration the way it was and adding a MapConfiguration that did extend Map. Could a similar approach work for Context? Provide a standard Context and then a MapContext sub interface that exposes the Map interface? In my use of Chain I haven't had a situation where I needed the extra Map provided methods like keySet or entrySet. But, if I did, I could just cast to MapContext and then get them.. The other reason I wouldn't mind having Context NOT extend Map is that when I implement my own Context, I don't want user's directly putting and getting stuff into the context via the Map put and get methods. I want them to use my accessors ONLY. At any rate, I've been using Chain for a couple days now in my project, and am very happy to be replacing my own code with Chain! Eric -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, November 22, 2004 10:14 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Release Chain 1.0 On Tue, 23 Nov 2004 09:37:27 +1300, Simon Kitching [EMAIL PROTECTED] wrote: Hi Martin, On Mon, 2004-11-22 at 20:39, Martin Cooper wrote: This sounds like an enhancement request to me. Are you really suggesting that Chain should not be released until your specific enhancement is endorsed and incorporated into the component? I'm afraid I, for one, can't sign up for that. I think Matt's comment was entirely reasonable. The whole point of a 1.0 release is to freeze the API. If the API isn't right, then people certainly should speak up *before* the API freeze. You're right, of course. Of course it is better to speak up well before then if possible, but a release proposal is bound to prompt people to get around to voicing that concern they have had kicking around in the back of their mind for a while. Anyone raising the prospect of a release should be expecting this sort of thing. I was (over)reacting to exactly that. Chain was promoted out of the sandbox almost 6 months ago, so seeing such a fundamental change being proposed at this point was a bit like a bolt from the blue. Matt, I apologise for jumping down your throat. It looks to me, as an outsider, like the concensus is that the existing interface *is* ok, but as a commons committer I hope that everyone will give it serious consideration, and not ignore it as too late. It is perfectly valid to change APIs before 1.0 (keeping compatibility is *desirable* but not mandatory). It's certainly better than being stuck with the wrong API post-1.0. Agreed. I have first hand experience of dealing with a poor API being exposed in a release... -- Martin Cooper Regards, Simon - 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] nightly builds
Where are you looking.. I see them here: http://cvs.apache.org/builds/jakarta-commons/nightly/commons-email/?C=M;O=D (linked from the commons homepage) Eric -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 10:21 AM To: [EMAIL PROTECTED] Subject: [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Email] nightly builds
I have just committed the update build.xml file. It works great on my local machine. Craig, you may be interested in this: http://jira.codehaus.org/browse/MPANT-7. I added a fix to the Maven Ant plugin so that included jar's aren't downloaded when the build.xml is generated by Maven. This allows us to use a completely Maven generated Ant file for Email. Eric -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 6:13 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: [Email] nightly builds It looks like the binary distribution builds are failing -- which would likely happen if you've added a dependency that my script doesn't know about. Alas, I'm on the road (and therefore can't reach my desktop system at home that is running these builds behind a firewall) until I get back tonight. But I'll look at it then. Craig On Tue, 23 Nov 2004 17:12:56 +0100, Eric Pugh [EMAIL PROTECTED] wrote: Where are you looking.. I see them here: http://cvs.apache.org/builds/jakarta-commons/nightly/commons-email /?C=M;O=D (linked from the commons homepage) Eric -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 10:21 AM To: [EMAIL PROTECTED] Subject: [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] - 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]
[RESULT][VOTE] Promote Email to Commons Proper
With the following votes the Commons community has decided to promote Commons Email from the sandbox: Commons Committers +1 robert burrell donkin [EMAIL PROTECTED] +1 Henri Yandell [EMAIL PROTECTED] +1 Shapira, Yoav [EMAIL PROTECTED] +1 Matthias Wessendorf [EMAIL PROTECTED] +1 Eric Pugh [EMAIL PROTECTED] Commons Sandbox Committers +1 Joe Germuska [EMAIL PROTECTED] The voting thread can be found here: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] pache.orgby=threadfrom=938115 If I missed anyone's +/- votes, please speak up. I'll also need someone with the right bugzilla magic to add the [email] component to the drop down of components. Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Is there a split method based on case?
It seems like it might also help flesh out WordUtils.. Would just a method that splits be enough, or is there any reason to get fance and insert spaces etc...? -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Thursday, November 18, 2004 4:40 AM To: Jakarta Commons Developers List Subject: Re: [lang] Is there a split method based on case? I also had to recently do this, for the same reasons :-) -Corey On Thu, 18 Nov 2004 00:26:16 + (GMT), Stephen Colebourne [EMAIL PROTECTED] wrote: FYI, I recently had to write this same method to take resource keys and make more human readable sentences. So, maybe there is space for it in lang. Stephen --- Gary Gregory [EMAIL PROTECTED] wrote: Hello, This sounds like a job for regular expression substitution: replace all uppercase chars with a space followed by that upper case char. See the ORO project: http://jakarta.apache.org/oro/index.html Gary -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 17, 2004 3:11 AM To: Commons-Dev Subject: [lang] Is there a split method based on case? Hi all, I am converting some classnames to user friendly names. So I have a class call my.companies.own.SpecialStep and I can use the substringAfterLast(my.companies.own.SpecialStep,.) to return SpecialStep. I want to convert this to Special Step. Any ideas on how to do this using commons-lang? If I had AnotherSpecialStep, I'd want to split it up so I got Another Special Step. Would this be a good idea for commons-lang's WordUtils? 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] - 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
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? Eric -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 3:05 PM To: Jakarta Commons Developers List Subject: Re: [VOTE] Promote Email to Commons Proper It'd be pretty easy to have James use the Null mailet as the first (and only step) in its processing logic. This would cause James to spool the incoming messages to disk, and then always discard them. That would be a much heavier weight solution though. We use something slightly like this, at least informally. There's a tool called Postal (http://www.coker.com.au/postal/) that does SMTP and POP benchmarking, and that has an SMTP sink. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] Corey Scott wrote: Serge, [Extract from the website http://quintanasoft.com/dumbster/] The Dumbster is a very simple fake SMTP server designed for unit and system testing applications that send email messages. It responds to all standard SMTP commands but does not deliver messages to the user. The messages are stored within the Dumbster for later extraction and verification. The Dumbster slots itself very easily into your testing strategy. As long as your application talks to an email server using SMTP then the Dumbster can be used to test the application with no code changes. [End extract] We have been using it to allow us to test send mails and do some rudimentary verification of the sent mails in our jUnit tests. - 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]
[lang] Is there a split method based on case?
Hi all, I am converting some classnames to user friendly names. So I have a class call my.companies.own.SpecialStep and I can use the substringAfterLast(my.companies.own.SpecialStep,.) to return SpecialStep. I want to convert this to Special Step. Any ideas on how to do this using commons-lang? If I had AnotherSpecialStep, I'd want to split it up so I got Another Special Step. Would this be a good idea for commons-lang's WordUtils? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Website has been updated
Right now, anything that gets deployed into the Apache dist directory gets rsynced over to ibiblio. However, for things like -SNAPSHOT releases, they really shouldn't be going to Ibiblio b/c they aren't really released. I think the commons-email SNAPSHOT was moved when Maven project and IBiblio were first being set up. We should point people to the nightlies that are generated instead. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 6:49 AM To: Jakarta Commons Developers List Subject: Re: [email] Website has been updated Eric, Do you know why the commons-email SNAPSHOT.jar is very old on the maven repo? Do we have to do something to keep this up to date? 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: [email] Handling bounces (was Re: DO NOT REPLY [Bug 18968] - [email] Support SMTP Envelope From (bounce address))
Joe, Can you add your change to /xdocs/changes.xml? Also, you may want to add yourself to project.xml as well :-) Eric -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Sunday, November 14, 2004 9:18 PM To: Jakarta Commons Developers List Subject: [email] Handling bounces (was Re: DO NOT REPLY [Bug 18968] - [email] Support SMTP Envelope From (bounce address)) I updated Email.java and added some notes at the bottom of xdocs/examples.xml. I couldn't figure out any way to have Dumbster simulate a bounce, but I did write a trivial Java app that sent a message with and without setting the bounce address value and confirmed that it did what I intended it to do. I haven't yet got karma for any Commons-proper projects, but I'd be happy to be on STATUS and continue to try to help keep email going after it graduates from the sandbox. Joe I am happy to have you apply this fix, I think I understand better. The one thing I would ask is that you put a bit of documentation into either the javadocs, or even better, into /xdocs describing this behavior. I agree that is shouldn't be a system property. System properties often have a habit of causing nasty head scratching bugs as you wonder why the bounce isn't working properly! Since we are moving to promote from commons-sandbox, are you also a commons committer? Can I list you on the STATUS document? -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - 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: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions
So, we are agreed that we should have an EmailException that should be thrown? And that will wrap any underlying exception? EmailException should extend NestableException. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 6:18 AM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be thrown as messagingExceptions I also like these ideas and am happy to help you implement them if you would like. However there is one thing we may want to be aware of. I dont think that the setCharset causes the UnsupportedCharsetException to be throw, I believe that it doesn't check it and therefore allows for any value to be set. As we are trying to keep email small and maintainable, I dont think it is a good idea to try to added verfication to our classes. That said, I believe that the only value I came accross during testing that did throw this exception was the setName part of the addresses. Therefore the unsupported charset exception is thrown for all of the setFrom, addTo, addCc, addBcc, etc functions only at the moment. I hope this helps, 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]
[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]
RE: [VOTE] Promote Email to Commons Proper
The code originally came from Turbine, back in the Turbine 2.2 time frame. It then pretty much sat in the sandbox. Turbine 3 picked it up, and therefore Scarab, built on Turbine 3, uses it. Because we didn't want to add yet another unreleased component to Turbine 2.x, we haven't removed the original code. The plan is to move to commons-email once a 1.0 is released. ERic -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 4:51 PM To: Jakarta Commons Developers List Subject: RE: [VOTE] Promote Email to Commons Proper Hi, - It has good unit test coverage. It has also been tested in real world email applications (Turbine 2.3, 2.4, 3.0, Scarab). Is it relied upon by these packages, out of curiosity? Or was it tested and not used subsequently? +1 from me. Good proposal. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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
And LGPL ruins Eric's day.. Again.. When will Eric learn? He promises that this is the last time he'll look at a library without verifying the license first. So, enough with the third person. I wouldn't be surprised in the author picked LGPL because it look like a good middle of the road license. It does to me as well. Can you give me more details on what dual use means in the Apache friendly we can use it in email way? I did some searchs and found quite a few rather painful bits of information [1],[2], but nothing specific on what exactly dual licensing entails? And, which licenses can be dual licensed. This [3] article seemed to suggest that SpamAssassin was both ASL and LGPL at the same time? I am willing to approach Jason Kitche, the developer of Dumbster about either dual licensing or maybe granting us some sort of special license, but would like to have my facts in a row. Eric [1] http://www.apache.org/licenses/GPL-compatibility.html [2] http://www.dwheeler.com/essays/gpl-compatible.html [3] http://builder.com.com/5100-6372_14-5378447.html -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 10:17 PM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: [VOTE] Promote Email to Commons Proper Damn, I need to Wiki this :) Basically, LGPL is a license written for the C programming language. While we all agree that its intent is to allow people to freely use the library, its wording means that the actual application to a language other than C is up for debate. A lot of this comes down to whether the term 'linking' means 'import' in Java or not. Early vs Late linking languages etc. Anyways, legal advice given to the ASF is not to be tied to an LGPL license as the LGPL is feasibly as viral as GPL. This isn't just some not-invented-here view the ASF have. Lawrence Rosen's latest book on open-source licensing seems to repeat the view. This means we cannot have LGPL'd jars in the CVS repository, that we cannot modify previously LGPL'd code and that we cannot import LGPL'd code in our import statements. The same applies for GPL (to answer Joe's question that yes, GPL is worse). I'm hoping that as the months go by next year we'll be able to import LGPL'd code in our code. GPL will still be out of the question, as would LGPL in CVS or modifying LGPL; but use of JFreeCharts, Hibernate and other libraries would be possible. So, yep. Dumbster's license seems to be a problem. One path is to explain this to the author and ask if they can dual-license it under something like BSD or ASL 2.0. Hen On Mon, 15 Nov 2004 23:04:11 +0100, Mark Lowe [EMAIL PROTECTED] wrote: A little bit of a digression but I'm reading through the LGPL blurb.. Can you give a bit more detail on this problem? Just as a matter or curiosity. Mark On Mon, 15 Nov 2004 21:00:16 +, robert burrell donkin [EMAIL PROTECTED] wrote: On 15 Nov 2004, at 11:10, Eric Pugh wrote: snip (2) DEENDENCIES The Email component is dependent upon the following external components for development and use: snip * Dumbster Fake SMTP (Version 1.0.3 or later) - for unit tests only, not required for deployment i hate to do this to what is a good proposal but... isn't dumbster LGPL'd...? BaseEmailTestCase imports LGPL'd code and IIRC that's still problematic. (FSF refuse to clarify the situation with regard to java.) - 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: [email] ByteArrayDataSource
It seems like byte[] would be simpler right? Save a layer of translation? Of course, that might just move the translation inwards.. Please file a bug so we don't forget about this... Eric -Original Message- From: Scott [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 11:17 PM To: Jakarta Commons Developers List Subject: Re: [email] ByteArrayDataSource Hi, I use it to attach dynamically generated content (which often ends up as a byte[]) to an email. The attach() methods in MultipartEmail and the EmailAttachment class want either a File, URL, or DataSource. The ByteArrayDataSource class saves someone the time of implementing their own DataSource for this purpose. Of course, an attach() method that accepts a byte[] would work well also. Scott Eric Pugh wrote: That is quite possible! Can you explain the use case for ByteArrayDataSource? It seemed like a terrible hack, but maybe it was a terribly cool idea? -Original Message- From: Scott [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 8:58 PM To: Commons-Dev Subject: [email] ByteArrayDataSource Hi, I noticted that the ByteArrayDataSource class was removed from commons-email. I found it to be a useful addition to commons-email...has it moved to a different commons project? The Turbine javadoc for this class says that org.apache.turbine.util.mail.ByteArrayDataSource is deprecated and that org.apache.commons.mail.ByteArrayDataSource should be used instead. Is it possible that the class remained deprecated when moved from Turbine to commons-email, and that its removal was accidental? Thanks, Scott - 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/configuration/src/java/org/apache/commons/configuration HierarchicalConfiguration.java
Welcome aboard Oliver!
Should we go through the bug list, clean it out and maybe release 1.0.1?
Build on the momentum of getting 1.0 out the door? It would also allow us
to have a version released with no deprecated methods...
Eric
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 13, 2004 5:03 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-commons/configuration/src/java/org/apache/commons/configuration
HierarchicalConfiguration.java
oheger 2004/11/13 09:02:51
Modified:configuration/src/java/org/apache/commons/configuration
HierarchicalConfiguration.java
Log:
Fix for Bug 31745
Revision ChangesPath
1.13 +36 -2
jakarta-commons/configuration/src/java/org/apache/commons/configur
ation/HierarchicalConfiguration.java
Index: HierarchicalConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/common
s/configuration/HierarchicalConfiguration.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- HierarchicalConfiguration.java 18 Oct 2004 10:19:26 - 1.12
+++ HierarchicalConfiguration.java 13 Nov 2004 17:02:51 - 1.13
@@ -387,7 +387,7 @@
*/
public Iterator getKeys(String prefix)
{
-DefinedKeysVisitor visitor = new DefinedKeysVisitor();
+DefinedKeysVisitor visitor = new DefinedKeysVisitor(prefix);
List nodes = fetchNodeList(prefix);
ConfigurationKey key = new ConfigurationKey();
@@ -990,6 +990,9 @@
{
/** Stores the list to be filled.*/
private Set keyList;
+
+/** Stores a prefix for the keys.*/
+private String prefix;
/**
* Default constructor.
@@ -998,6 +1001,18 @@
{
keyList = new HashSet();
}
+
+/**
+ * Creates a new codeDefinedKeysVisitor/code
instance and sets the
+ * prefix for the keys to fetch.
+ *
+ * @param prefix the prefix
+ */
+public DefinedKeysVisitor(String prefix)
+{
+this();
+this.prefix = prefix;
+}
/**
* Returns the list with all defined keys.
@@ -1020,7 +1035,26 @@
{
if (node.getValue() != null key != null)
{
+addKey(key);
+}
+}
+
+/**
+ * Adds the specified key to the internal list.
+ *
+ * @param key the key to add
+ */
+protected void addKey(ConfigurationKey key)
+{
+if(prefix == null)
+{
keyList.add(key.toString());
+}
+else
+{
+StringBuffer buf = new StringBuffer(prefix);
+buf.append('.').append(key);
+keyList.add(buf.toString());
}
}
}
-
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/configuration/src/java/org/apache/commons/configuration HierarchicalConfiguration.java
I would like to add a save() method to HierarchicalXMLConfiguration (Bug 31130), and I have a solution for 31797 (optional configurations). For the latter documentation could be updated, too. Which other issues should be addresed? Maybe 30858, this could confuse users. There was recently a posting on the user list of somebody who got a NPE when loading a file based configuration and the specified file does not exist. I would like to check this; in this case a ConfigurationException should be thrown. Agreed, missing files should throw ConfigurationException. However, if we add 31797, then it wouldn't. I would like to see 31797 as I think it would help the usability for lots of people. I am not going to finish my JNDIConfiguration setProperty stuff, I got screwed up in it and frustrated, so I ended up working around it. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] Website has been updated
Hey all, Just wanted to let you know I updated the website. Check out that 97% code coverage! We should take a spin through the current examples and make sure they are up to snuff. I *think* this is the last step before I can start a thread for promotion out of sandbox. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[chain] evaluating to use, contrast to pipeline?
Hi all, Just checking out [chain], was thinking of replacing my own CoR implementation. The one thing that I have, that chain doesnt, is a visitor object. Now, I may be mixing up my GoF patterns here, but what I have are a series of steps that are ordered. I have a visitor who goes from one to the other. At each step, there is the option to continue or to stop. The visitor provides a place to collect up things like messages back to the user. In [chain], instead of a visitor, I would have a well known context property that would fulfill that role, correct? I could even subclass Context to have a typesafe .getVisitor() or .getMessagesHolder() to put my messages in right? I was also looking at [pipeline] in sandbox, and was trying to grok the difference. What it seemed to boil down to is that in a pipeline you go from A - Z without ever stopping. But, in [chain] you may go from A - Z, but if certain conditions occur, you may stop midway at J, correct? Which brings me to my last question.. Why does returning false from a command signify continue? Why wasn't it return true means keep going? Eric Pugh PS, anyone mind if I update dependencies in the Maven build? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [chain] evaluating to use, contrast to pipeline?
Thanks.. I think that for the level of usage I envision, the flexiblity of [chain] (and relative maturity) solves the problem, even though [pipeline] may in a larger sense be more appropriate for my use case. My usecase, processing data, seems to fit into exactly what [pipeline] does. In fact, I call it a pipeline. However, in my own implementation, a specific valve may shut off execution of future valves, similar to how a command in the [chain] may not pass on control to the next element in the chain. So, from that standpoint, [chain] is more appropriate. I'm looking forward to using [chain] and see what I can help out on. I'll be using it triggered from a Quartz process, so I'll be looking at agility a bit, but it seems like my needs are even simpler then that: Put context in at one end. Get context out at other end. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Aren't we all fighting the same battles?
I think you actually have to narrow your criteria. Within jakarta commons we try to focus on one component approach versus multiple component approach, even though that doesn't always happen. And, in many ways, jakarta commons has been VERY sucessful in providing reusable components. Just look at the list of dependees in Gump for typical components. Or the number of other OSS sites that say These are my util classes, but you might as well use commons-lang or commons- something else. At a bigger level, everybody has different ways and thoughts on how to set things up. That is why projects like Spring or Keel exist. They attempt to provide the glue *between* all the other approaches. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Oliver Heger as Committer
I'd like to announce that Oliver Heger has been voted in as a committer on the Jakarta Commons project. His contributions towards [configuration] have been many, and I look forward to his future contributions to the Jakarta Commons project as a whole. Votes: +1 Eric Pugh [EMAIL PROTECTED] Shapira, Yoav [EMAIL PROTECTED] Emmanuel Bourg [EMAIL PROTECTED] Henning P. Schmiedehausen [EMAIL PROTECTED] Noel J. Bergman [EMAIL PROTECTED] Dirk Verbeeck [EMAIL PROTECTED] robert burrell donkin [EMAIL PROTECTED] No -1 votes. Congratulations Oliver! Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] release
Technically, we shouldn't release until exiting commons-sandbox. I'll go ahead and post a feeler to commons-dev about whether we are ready or not. However, we could I suppose do a snapshot...? Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 8:07 PM To: Jakarta Commons Developers List Subject: Re: [email] release There are two answers: (Long answer) We want to get the unit tests finalized and then we need to get the promoted to commons-proper. (short answer) asap :-) -Corey On Wed, 3 Nov 2004 10:37:46 +0100, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi, When do you plan to release an 1.0 version? or provides an 1.0-SNAPSHOT on ibiblio repo? Emmanuel - 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] dumbster *nix
Mark, Maybe you can clear something up for me.. As far as I know, with JavaMail, I still have to have *some* SMTP server running somewhere to send emails. Are you saying that if I include smtp.jar, that acts as my SMTP server? I don't have a problem factoring out the email smtp stuff into the MailSession.. How about MailSession or MailServer? Anything ending in *Utils becomes a code smell eventually as crap gets tossed in! If you still need an SMTP server running externally, then we should make the sending email tests optional. some sort of config value. I believe in Maven you can easily hand in junit system properties[1]. Alternaively, are there other options that work better? I don't want to include an elephant to swat a fly however. I found these [2],[3] Eric [1] http://maven.apache.org/reference/plugins/test/properties.html [2] http://www.ericdaugherty.com/java/mailserver/gettingstarted.html [3] http://james.apache.org/ -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, November 04, 2004 11:14 AM To: Jakarta Commons Developers List; Corey Scott; [EMAIL PROTECTED] Subject: [email] dumbster *nix I've started a new thread as I think it will be more useful as a separate dialogue. I've just tried Corey's unix test (and added the patched jar), and have the same problems. Only very quickly so could be something that i've overlooked. What i cant work out is how the dumbster tests passed when i built as root yesterday and now i cant. I've also tried changing the ports (i entered in bugzilla, to get some of the issues comming up on these threads logged someplace). Jason the dumpster guy has been in touch, hopefully they'll be a dumpster in CVS so any efforts can get patched back into the project. Despite some progress with dumbster in terms of possiblities, how about a MailSessionUtil in with the unit tests. The idea being that the mailapi smtp stuff can be used for now, but dumbster can be added when progress is made. Corey I added the 1.3.1 dumbster to my maven repo and added the test to the commons mail, I cant see why the test wouldn't succeed (Same mail session problem), who you expect it to under these conditions? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[general][email] Time for Commons Email to exist Sandbox?
Hi all, While not calling for a formal vote, I wanted to gather feedback on any issues that would bar allows commons-email to exit the sandbox. For those of you not familiar with it, commons-email is an attempt to provide a lightweight simple library for sending emails using the JavaMail library. Text, HTML, and attachement type emails are supported. This code was originally written for Turbine, and is therefore quite mature. Since then it has been langushing in Sandbox until some new contributors have started submitting patches. I feel that this code is very close to being ready for a 1.0, and all the remains is some polishing of Ant script and promotion out of the Sandbox. The only issue I can raise is that while there are two Emeritus committers, John McNally and Jon Stevens, I am the only active Commons committer working on [email]. However, we have some active contributors, specifically Mark Lowe and Corey Scott who have provided unit tests and testing. I think that getting [email] out of the sandbox will allow it to grow. Please send me your feedback, and, assuming the perspective is postive, I'll call for a formal VOTE promotion later this week. I have updated the docs showing the increased code coverage etc: http://jakarta.apache.org/commons/sandbox/email/ Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general][email] Time for Commons Email to exist Sandbox?
I think on that front, we are ready. We are tiding up a unit test and figuring out the best ant build script. So, if we move out of sandbox, I think 1.0 would be days away from being VOTE'd on... -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Thursday, November 04, 2004 8:29 PM To: Jakarta Commons Developers List Subject: Re: [general][email] Time for Commons Email to exist Sandbox? Main criteria are community and readiness for 1.0. Getting a 1.0 immediately after promotion is actually really quite important. Stephen - Original Message - From: Eric Pugh [EMAIL PROTECTED] While not calling for a formal vote, I wanted to gather feedback on any issues that would bar allows commons-email to exit the sandbox. For those of you not familiar with it, commons-email is an attempt to provide a lightweight simple library for sending emails using the JavaMail library. Text, HTML, and attachement type emails are supported. This code was originally written for Turbine, and is therefore quite mature. Since then it has been langushing in Sandbox until some new contributors have started submitting patches. I feel that this code is very close to being ready for a 1.0, and all the remains is some polishing of Ant script and promotion out of the Sandbox. The only issue I can raise is that while there are two Emeritus committers, John McNally and Jon Stevens, I am the only active Commons committer working on [email]. However, we have some active contributors, specifically Mark Lowe and Corey Scott who have provided unit tests and testing. I think that getting [email] out of the sandbox will allow it to grow. Please send me your feedback, and, assuming the perspective is postive, I'll call for a formal VOTE promotion later this week. I have updated the docs showing the increased code coverage etc: http://jakarta.apache.org/commons/sandbox/email/ 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general][email] Time for Commons Email to exist Sandbox?
It tanks on the download of the javamail jars. I am thinking of just putting a /lib/javamail.jar and then having maven jar override map it, and hopefully the Ant plugin will pick it up, or just tweak the plugin afterwords to point to it. Eric -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Thursday, November 04, 2004 10:20 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: Re: [general][email] Time for Commons Email to exist Sandbox? On Thu, 4 Nov 2004 21:48:00 +0100, Eric Pugh [EMAIL PROTECTED] wrote: I think on that front, we are ready. We are tiding up a unit test and figuring out the best ant build script. So, if we move out of sandbox, I think 1.0 would be days away from being VOTE'd on... I probably missed some discussion on this, but what needs to be figured out about an Ant build script? Can you not simply use the one generated by Maven? -- Martin Cooper -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Thursday, November 04, 2004 8:29 PM To: Jakarta Commons Developers List Subject: Re: [general][email] Time for Commons Email to exist Sandbox? Main criteria are community and readiness for 1.0. Getting a 1.0 immediately after promotion is actually really quite important. Stephen - Original Message - From: Eric Pugh [EMAIL PROTECTED] While not calling for a formal vote, I wanted to gather feedback on any issues that would bar allows commons-email to exit the sandbox. For those of you not familiar with it, commons-email is an attempt to provide a lightweight simple library for sending emails using the JavaMail library. Text, HTML, and attachement type emails are supported. This code was originally written for Turbine, and is therefore quite mature. Since then it has been langushing in Sandbox until some new contributors have started submitting patches. I feel that this code is very close to being ready for a 1.0, and all the remains is some polishing of Ant script and promotion out of the Sandbox. The only issue I can raise is that while there are two Emeritus committers, John McNally and Jon Stevens, I am the only active Commons committer working on [email]. However, we have some active contributors, specifically Mark Lowe and Corey Scott who have provided unit tests and testing. I think that getting [email] out of the sandbox will allow it to grow. Please send me your feedback, and, assuming the perspective is postive, I'll call for a formal VOTE promotion later this week. I have updated the docs showing the increased code coverage etc: http://jakarta.apache.org/commons/sandbox/email/ 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] - 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: Steps prior to graduating from Sandbox
Maybe I should start another thread, but what do you think of the current state of [email]. We currently have a high level of unit testing, and it is building under Gump nicely. We are working on resolving the Ant/Maven build issues. I'd like to put out a feeler for graduating from sandbox before calling for a vote. See what else we need. My biggest concern is that I am the only active committer. On the other hand, I don't see that the codebase in [email] can mature anymore then it has already! Eric -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 9:11 PM To: Jakarta Commons Developers List Subject: Re: Steps prior to graduating from Sandbox in theory, all that's required is that a component satisfies the requirements to be a commons component and passes a vote. (the sandbox is free for people to play in but some sandbox projects should graduate to somewhere other than the commons.) in practice, the question is what the consensus amongst commons committers . willingness and preparedness for an initial release. this does not need to be a 1.0, sometimes an API needs time to mature or there are major features missing and in those cases a 0.x release might be more appropriate. the aim should be to create an initial release immediately after promotion. a healthy community of developers and users, as well as committers. - robert On 2 Nov 2004, at 12:11, Oliver Zeigermann wrote: Unrelated, but do you know what would be the steps for a project to be graduated from the sandbox? Oliver On Tue, 2 Nov 2004 12:34:27 +0100, Eric Pugh [EMAIL PROTECTED] wrote: Hi all, I started updating the Status.html doc. I wanted to make sure we have a consensus on steps prior to proposing to graduate from the sandbox: 1) Remove commons-validator. 2) Verify unit tests (dumbster) run on *NIX boxes 3) Documentation enhancements? Does this look good? 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] - 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: Steps prior to graduating from Sandbox
Okay.. If dumbster doesn't work on *nix, then maybe we need to make it more configurable about when to run it.. Can do stuff like only run on windows or something. Mark, As far as the SF site, you'll want to setup an ID! You'll soon discover that tons of stuff in the OSS world is there.. :-) Also, in terms of support, he is probably preferring posts through the forum so that other unix types may see yoru bug and chime in, or learn from your difficulties! Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 1:01 PM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: Steps prior to graduating from Sandbox Mark, I have been trying to get this to work on my Redhat box, after quite a bit of time the conclusion is it doesnt. I have created a Maven build script for dumbster and the maven test goal doesnt run with the unit test that come with the dumbster. I am going to try to fiddle with the dumbster source and see what I can come up with but at this stage I am not hopefull. -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: Steps prior to graduating from Sandbox
We could do something like.. The thing is that dumbster (not dumpster funnily enough :-) ) is meant to make our testing lives easier, not harder.. Dumbster is only used in the unit tests so.. ARgh. Eric -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 2:45 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: RE: Steps prior to graduating from Sandbox Hi, Maybe a 1.0 release doesn't have dumpster support, and a 1.1 release does ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 7:49 AM To: Jakarta Commons Developers List; Corey Scott Subject: RE: Steps prior to graduating from Sandbox Okay.. If dumbster doesn't work on *nix, then maybe we need to make it more configurable about when to run it.. Can do stuff like only run on windows or something. Mark, As far as the SF site, you'll want to setup an ID! You'll soon discover that tons of stuff in the OSS world is there.. :-) Also, in terms of support, he is probably preferring posts through the forum so that other unix types may see yoru bug and chime in, or learn from your difficulties! Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 1:01 PM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: Steps prior to graduating from Sandbox Mark, I have been trying to get this to work on my Redhat box, after quite a bit of time the conclusion is it doesnt. I have created a Maven build script for dumbster and the maven test goal doesnt run with the unit test that come with the dumbster. I am going to try to fiddle with the dumbster source and see what I can come up with but at this stage I am not hopefull. -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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Steps prior to graduating from Sandbox
I guess we should try and take steps to make dumbster the default option, but easy to switch. I think that means reading in all the test values from a properties file or something. I agree that too much time has been shot on this.. I'll have to have a think on how we can most easily have our cake and eat it too... -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 4:58 PM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: Steps prior to graduating from Sandbox I agree with Mark, although I havent quite given up yet. As an appendix to my previous mail, the dumbster unit tests work on Redhat, albeit slowly. I am going to continue to fiddle a little more, but am quickly running out of patience. That said, I do have a question for you all. Has anyone had any experience problems with the java.net.ServerSocket on unix? Cause as far as I can figure the problem is either this or the fact that is opens threads to do its work (although I think this is quite unlikely. Thanks for any help, Corey On Wed, 3 Nov 2004 15:54:43 +0100, Mark Lowe [EMAIL PROTECTED] wrote: Well dumpster doesn't work on *nix. That means in my book it doesn't work. I've got the source but as there appears to be nothing in CVS its hard to know if thats this current version or not. I registered with SF but this apparently doesn't allow me to enter bugs, which is pretty shit. With a dumbster not working on sensible platforms, I cant have any hope of submitting any patches I need, and not being able to run the test cases makes using commons email too risky. I may as well write my own mail api wrappers rather than washing out time on SF registrations and other such self mutilation exercises. I'm happy to send patches that use the smtp.jar to test, but cant afford to get bogged down in the dumpster business any longer. Its introduced more problems than it solves. And the tortured way that SF want endless registrations, is not inviting me to work on it, there's no dumbster in CVS so dumbster can byte me as far as i'm concerned. I want to work on commons email, not dumbster but I cant while this dependency is there. Mark On Wed, 3 Nov 2004 15:12:02 +0100, Eric Pugh [EMAIL PROTECTED] wrote: We could do something like.. The thing is that dumbster (not dumpster funnily enough :-) ) is meant to make our testing lives easier, not harder.. Dumbster is only used in the unit tests so.. ARgh. Eric -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 2:45 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: RE: Steps prior to graduating from Sandbox Hi, Maybe a 1.0 release doesn't have dumpster support, and a 1.1 release does ;) Yoav Shapira http://www.yoavshapira.com -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 7:49 AM To: Jakarta Commons Developers List; Corey Scott Subject: RE: Steps prior to graduating from Sandbox Okay.. If dumbster doesn't work on *nix, then maybe we need to make it more configurable about when to run it.. Can do stuff like only run on windows or something. Mark, As far as the SF site, you'll want to setup an ID! You'll soon discover that tons of stuff in the OSS world is there.. :-) Also, in terms of support, he is probably preferring posts through the forum so that other unix types may see yoru bug and chime in, or learn from your difficulties! Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 1:01 PM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: Steps prior to graduating from Sandbox Mark, I have been trying to get this to work on my Redhat box, after quite a bit of time the conclusion is it doesnt. I have created a Maven build script for dumbster and the maven test goal doesnt run with the unit test that come with the dumbster. I am going to try to fiddle with the dumbster source and see what I can come up with but at this stage I am not hopefull. -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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged
RE: Maven Jelly Tags Email
I think that we need a 1.0 release of email first, otherwise we are just adding another un released dependency. However, I do think it's a good idea when we get the 1.0. One thing is, does it help/simplify/add to the Jelly Email tags? Or just add another layer of complexity? Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 5:18 AM To: Jakarta Commons Developers List Subject: Maven Jelly Tags Email Is anyone interested/upset if I propose that we change this to utilise the Commons Sandbox Email project? I happy to do the bulk of the work and add basic junit tests as required. Is this a good idea or bad? Open to opinions. -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]
