[
https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Pugh updated SANDBOX-183:
--
Attachment: myzip2.zip
Fixed most of Mario's style concerns.
Did not address the memory issue yet
[
https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Pugh updated SANDBOX-183:
--
I fixed the style concerns, but did not fix the allocation size issue yet.
Should not be hard to do
: Compress
Affects Versions: Nightly Builds
Reporter: Will Pugh
Fix For: Nightly Builds
Attachments: myzip.zip
Compress should be able to modify existing ZipFiles.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact
[
https://issues.apache.org/jira/browse/SANDBOX-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Pugh updated SANDBOX-183:
--
Attachment: myzip.zip
Compress should allow for writing to Zip Files
Since, MethodUtils is not going to be in the same package as whatever
class you are calling a method on, I don't think you going to be allowed
to call a package, protected or private methods in that class?
--Will
Henri Yandell wrote:
JIRA reports are good - we've a big backlog in
Torsten Curdt wrote:
On 10/25/06, James Carman [EMAIL PROTECTED] wrote:
For someone who uses Commons Collections a lot in their applications,
this
is going to be quite a pain if I want to upgrade. Yes, I realize that
there's such a thing as find and replace, but the fact that I have to do
I'm not sure we're optimizing for the right thing by changing the
package names and creating parralel forks for Generic Collections.
Generics have done a pretty good job of dealing with backwards
compatibility. It feels like we will make the upgrade path for the vast
majority of people more
Stephen Colebourne wrote:
The problem is erasure. The JDK wipes all knowledge of the type that you
connect to the collection. Thus
ListString list = new ArrayList();
if (list instanceof ListInteger) {
}
fails to compile as the String type is erased.
In order to preserve backwards
We could also mash together collections and generics to get
commons-collagen
I'm sure there are some great puns we could pull out of that. . .
--Will
Mario Ivankovits wrote:
Hi!
collections5 ? (don't like collgenerics)
I think we should try not to put the technology into the
Lang
Type: Improvement
Reporter: Will Pugh
Attachments: addRangeToJoin.patch
Currently join, takes an array of objects, adn joins them using a character or
string as a separator.
The problem is that there are many instances where I have an array, but I only
want to join part
[ http://issues.apache.org/jira/browse/LANG-268?page=all ]
Will Pugh updated LANG-268:
---
Attachment: addRangeToJoin.patch
A patch with the new methods as well as new unit tests
StringUtils.join should allow you to pass a range for it (so it only joins
Hmm.
Factories have always seemed most useful to me when they are
encapsulating the creation of some configurable resource. In practice,
it seems like configurable most often means pulling a string from some
attribute or properties file, and using that to choose implementation.
If the type
.
ArchiverFactory.ZIP
--Will
Sandy McArthur wrote:
On 5/12/06, will pugh [EMAIL PROTECTED] wrote:
Hmm.
Factories have always seemed most useful to me when they are
encapsulating the creation of some configurable resource. In practice,
it seems like configurable most often means pulling a string
Sandy McArthur wrote:
On 4/30/06, will pugh [EMAIL PROTECTED] wrote:
1) You often change method names based on the parameter types, e.g.
Archiver.addFile + Archiver.addFileName, setUnpackDestinationName +
setUnpackDestinationFile, etc. It seems more conventional and less
chaotic to give
is
that this helps folks build factories, but that it is perfectly
acceptable and encouraged to create any of the archivers via 'new'. Is
that correct?
Thanks,
--Will
Sandy McArthur wrote:
On 5/1/06, will pugh [EMAIL PROTECTED] wrote:
Sandy McArthur wrote:
On 4/30/06, will pugh
? I'm assuming this is meant
to help people build their own factories? but the common case for
creating an Archiver is still to create using 'new'. Is this right?
--Will
Sandy McArthur wrote:
On 5/1/06, will pugh [EMAIL PROTECTED] wrote:
Sandy McArthur wrote:
On 4/30/06, will pugh
Overall, I like the interfaces, but I've got a few issues:
0) Update is mentioned in the Javadoc at the beginning of Archiver, but
is not implemented.
1) You often change method names based on the parameter types, e.g.
Archiver.addFile + Archiver.addFileName, setUnpackDestinationName +
and parameter conventions from
some of the commons-io methods I use alot.
--Will
will pugh wrote:
Overall, I like the interfaces, but I've got a few issues:
0) Update is mentioned in the Javadoc at the beginning of Archiver,
but is not implemented.
1) You often change method names based
Yeah. Probably should have documented a little more to start off with.
I sent it off early because I wanted to see if folks were interested in
the functionality first. I wrote up a bunch of JavaDoc for some of the
bigger classes. It's not perfect, but hopefully it will make it much
easier
I think the appropriate processes for getting contributed code are the
ones outlined:
http://incubator.apache.org/ip-clearance/index.html
Using some of the forms linked to from:
http://www.apache.org/licenses/#grants
This process is predicated on there being a community for the code to
Cool.
I'd love to see your code, although I don't think we should merge until
we get the code contributed. It looks like contributing code gets a bit
harder when there are more than one person involved in writing it.
--Will
C. Grobmeier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash:
Hi All,
I am interested in contributing code to commons. I wrote a
ModifiableZip class, that basically implements all the methods on
ZipFile, but provides new methods for adding, removing and modifying
entries in an existing zip file.
The basics work, but it is still a bit rough around the
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.
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
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
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
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
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
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
--
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
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
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
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
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
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.
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
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
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]
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
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
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
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
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,
, 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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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:
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
[ ] -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]
.
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
/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
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,
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
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
.
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
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,
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
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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,
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();
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
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:
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
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,
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,
: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
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
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
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
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
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,
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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]
1 - 100 of 331 matches
Mail list logo