RE: [codec] JIRA

> How has bugzilla been an impediment? A lot of people have complained about the performance. Many people have said that they do not like working with it, and don't. No one has wanted to invest the effort in bugzilla. Be that as it may, using Jira is a choice. > More importantly, how does movi

RE: [codec] [vote] JIRA

> I agree with all of what you are saying, but all of these problems can be > attacked with current technology and I am skeptical that adding new > technology will make a huge difference. Of course I may be wrong. Since the Directory project had long ago decided to use Jira, and was waiting for it

Re: [codec] [vote] JIRA

Phil Steitz wrote: What exactly does Jira have to do with release management and site publishing? I am asking out of ignorance here. I thought Jira was an issue tracker. Issue tracking is central to cutting quality releases, and communicating direction. Jira is more than issue tracking, IMO

Re: [codec] [vote] JIRA

Phil Steitz wrote: What exactly does Jira have to do with release management and site publishing? I am asking out of ignorance here. I thought Jira was an issue tracker. It *is* an issue tracker, so what it does very cleanly is associate bug fixes with releases and provide a generated roadmap

Re: [codec] [vote] JIRA

Tim O'Brien wrote: +1 What are the 4 or 5 pressing issues in Codec? Is anyone paying attention to Latka lately? All we seem to have for collaboration is the dev mailing list, we all get a weekly report of the open bugs from Bugzilla, but does anyone ever bother to read that monstrosity? I th

Re: [codec] [vote] JIRA

Tim O'Brien wrote: If you'd like to vote -1 on this product because someday, someone will lament the lack of an OS issue tracker. I only ask you to focus on the fact that there are a very few active committers who spend large amounts of time regularly doing things like release management, site

Re: [collections] RC1 Maven site for review

Phil Steitz wrote: I like this approach. While you're at it, a "default" logo like the ones that you have been putting together using gimp (with the text somehow "dynamic," i.e. editable) would a nice thing to make available. It is in CVS already. In the spirit of OS projects helping other OS

[codec] [vote] JIRA

+1 What are the 4 or 5 pressing issues in Codec? Is anyone paying attention to Latka lately? All we seem to have for collaboration is the dev mailing list, we all get a weekly report of the open bugs from Bugzilla, but does anyone ever bother to read that monstrosity? I think that moving th

RE: [codec] JIRA

--- "Noel J. Bergman" <[EMAIL PROTECTED]> wrote: > Gregory, > > > here is what I am worried about[:] OS projects like ours use Clover > and > JIRA > > and who knows what other NON-OS projects in the future. Clover rocks, > JIRA > > is pretty and all. Users and developers like us learn these syste

Re: [collections] RC1 Maven site for review

Tim O'Brien wrote: On Mon, 12 Jan 2004, Gary Gregory wrote: The site http://cvs.apache.org/~tobrien/docs/ is indeed consistent with the other links but, for me, battleship grey is not the most attractive background color. A red font color for the headings (call me crazy ;-) is a bit unusual since

RE: [PROPOSAL] Jakarta Commons moving to JIRA

> The main apache projects that are going to use JIRA at apache > appear to be: AltRMI, Jelly, Geronimo, Phoenix. Those are actually the ones that were ALREADY using Jira. A lot of projects are going to be moving, including Directory, Depot, jUDDI, infrastructure, James (so we expect), etc. The

RE: [PROPOSAL] Jakarta Commons moving to JIRA

> > I am curious about that one too, but at this point it seems > > like a "fait accomplis". How is it a fait accomplis if projects are being offered an opportunity to move? Several of the Commons projects/components are indicating that they would like to, one moved long ago (Jelly), and a few pe

Re: [codec] multipart encoders/decoders

Brett Henderson wrote: (b) Encoders/Decoders that actually work by passing thier content through streaming to manage larger amounts of data efficently. Data for which the length is probibly already known (Files). An interface which supports handing objects and Streams manages this: Can yo

RE: [codec] JIRA

Gregory, > here is what I am worried about[:] OS projects like ours use Clover and JIRA > and who knows what other NON-OS projects in the future. Clover rocks, JIRA > is pretty and all. Users and developers like us learn these systems, new > users and developers do NOT learn the OS Bugzilla and ot

RE: [PROPOSAL] Jakarta Commons moving to JIRA

On Tue, 2004-01-13 at 16:02, Phil Steitz wrote: > --- Gary Gregory <[EMAIL PROTECTED]> wrote: > > > What is the motivation for this migration exactly ? > > > > I am curious about that one too, but at this point it seems like a "fait > > accomplis". > > > > Is it? I don't remember seeing a vote

RE: [PROPOSAL] Jakarta Commons moving to JIRA

The current bugzilla afaik will not be upgraded could be a nice reason... Pier has stated that he will not upgrade bugzilla.. and for me upgrading my own boxes is a bit different than upgrading the apache installation. Besides that, I started liking JIRA a lot when using it on codehaus. Mvgr, Mart

DO NOT REPLY [Bug 18815] - [collections] Decorators are not serializable.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 24762] - [collections] CollectionWrapper should implement Serializable

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: [PROPOSAL] Jakarta Commons moving to JIRA

--- Gary Gregory <[EMAIL PROTECTED]> wrote: > > What is the motivation for this migration exactly ? > > I am curious about that one too, but at this point it seems like a "fait > accomplis". > Is it? I don't remember seeing a vote anywhere. In any case, I am -0, mostly for the reasons that an

RE: [codec] multipart encoders/decoders

> > > There are obviously advantages to having a single unified framework > > and if possible it would be the ideal result. Unfortunately > I have run > > into performance disadvantages so far. I haven't tried it > for a while > > but in the past my base 64 conversion has not been as fast as

DO NOT REPLY [Bug 26072] - [dbcp] Null pointer exception being thrown in SQLNestedException

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: [codec] multipart encoders/decoders

> Everyone will be getting tired of my emails soon ... No way, this is what where are here to talk about! ;-) Gary

RE: [codec] multipart encoders/decoders

> It would be interesting to compare performance between the Sun provided > MD5 and codec. FYI, the [codec] MD5 and SHA support in DigestUtils are just exception swallowing APIs on top on java.security.MessageDigest. Gary

RE: [codec] multipart encoders/decoders

> Here are a few good rules of thumb: > > 1. Commons exists as an effort to encourage code reuse. The > Streamable > framework presented was interesting, but I'd like us to find > an existing > streamable Base64 implementation inside of the ASF codebase. I have no problems with this but so f

RE: [codec] multipart encoders/decoders

> [snip] > > 1. Commons exists as an effort to encourage code reuse. The > > Streamable framework presented was interesting, but I'd like us to > > find an existing streamable Base64 implementation inside of the ASF > > codebase. > > Not for Base64 but Ant has: > > o MD5 and SHA checksum comp

RE: [PROPOSAL] Jakarta Commons moving to JIRA

> What is the motivation for this migration exactly ? I am curious about that one too, but at this point it seems like a "fait accomplis". Gary

RE: [codec] multipart encoders/decoders

> There are obviously advantages to having a single unified > framework and if possible it would be the ideal result. > Unfortunately I have run into performance disadvantages so far. > I haven't tried it for a while but in the past my base 64 > conversion has not been as fast as the existing codec

[jelly] JellyContext.newJellyContext side-effect

Hello. I've tried jelly in my in-house tool. It works well. While Embedding jelly into my tool, I noticed that JellyContext.newJellyContext() puts a value to its parameter. public JellyContext newJellyContext(Map newVariables) { // : should allow this new context to //

Re: [PROPOSAL] Jakarta Commons moving to JIRA

I don't think I have a weight in the decision but my preference goes to Bugzilla. JIRA looks nice but I don't see the need for a migration, Bugzilla has all the features we need (and it could be upgraded to the latest version to benefit from the improvements especially in the management of atta

RE: [codec] multipart encoders/decoders

> It is accomplished under "jakarta-commons-sandbox/codec-multipart". > > > (2) Can we agree on /what/ streamable codecs are (sorry but > I like to > > point out the obvious when starting something like this). Recognize > > the current impls alternatives. > > > > Yes sorry, I think there are

RE: [codec] multipart encoders/decoders

> (3) Should the Producer/Consumer framework submitted be > retrofitted into the current [codec] Encoder/Decoder > framework? Personally, I like the specificity of "Encoder" > and "Decoder" for interfaces. This means the current i/f > would be expanded. I'm not terribly attached to Producer an

RE: [codec] Streamable Codec Framework

> I suspect we are going to need something along the lines of a > "Streamable Encoder/Decoder" for the Multipart stuff. If we look at > HttpClients MultipartPostMethod, there is a framework for basically > joining multiple sources (files, strings, byte arrays) > together into an > OutputStream

Re: [configuration] unit test clean up

Craig your mail program is haunted, it replies on its own with no text added ;) Craig R. McClanahan wrote: Quoting Emmanuel Bourg <[EMAIL PROTECTED]>: Hi, here is a patch removing useless constructors, suite() and main() methods from the JUnit tests. It does a bit of code reformatting as wel

Re: [configuration] unit test clean up

Quoting Emmanuel Bourg <[EMAIL PROTECTED]>: > Hi, here is a patch removing useless constructors, suite() and main() > methods from the JUnit tests. It does a bit of code reformatting as > well. Any committer around to apply it please ? :) > > Emmanuel Bourg > > ---

[beanutils] {Constructor,Method}Utils: addressing primitive widening

all... i'm taking my first tour through the beanutils library. when i stumbled across ConstructorUtils and MethodUtils, it reminded me a lot of some code i wrote for a java rag article a while back. the article's here: http://www.adtmag.com/java/article.asp?id=4276&mon=8&yr=2001 and the m

Re: [codec] multipart encoders/decoders

Doesn't James lean pretty heavily on the javax.mail... API for encoding/decoding of messages (possibly multipart)? This leads us back to our earlier discussion. -M. Mark R. Diggory wrote: True, but I hope we consider some consistency of interface... "whole hog" is kinda scary. -M. Tim O'Bri

RE: [PROPOSAL] Jakarta Commons moving to JIRA

> -Original Message- > From: Simon Kitching [mailto:[EMAIL PROTECTED] > Sent: Monday, January 12, 2004 15:19 > To: Jakarta Commons Developers List > Subject: Re: [PROPOSAL] Jakarta Commons moving to JIRA > > I'm -0 on moving Digester (the project I mostly contribute to). > > It's purely o

RE: [PROPOSAL] Jakarta Commons moving to JIRA

> What about jakarta-commons-sandbox projects? Note that there is potential > for a name overlap problem, e.g. jakarta-commons [myproject] and > a jakarta-commons-sandbox [myproject] That is something we would have to address when naming the project. Personally, unless a sandbox project is relate

Re: [codec] multipart encoders/decoders

True, but I hope we consider some consistency of interface... "whole hog" is kinda scary. -M. Tim O'Brien wrote: On Mon, 12 Jan 2004, Noel J. Bergman wrote: James has code for implementing some of the RFC mandated stream encodings, too. Noel, this is in line with codec's history. Not neces

Re: [PROPOSAL] Jakarta Commons moving to JIRA

--- Simon Kitching <[EMAIL PROTECTED]> wrote: > I'm -0 on moving Digester (the project I mostly contribute to). > > It's purely on philosophical grounds. While it's kind of the JIRA team > to grant free use of their product I would prefer to stay with something > free. I'm not opposed to commerci

cvs commit: jakarta-commons-sandbox/email/src/java/org/apache/commons/mail Email.java

jmcnally2004/01/12 15:25:39 Modified:email/src/java/org/apache/commons/mail Email.java Log: Modified setFrom, addTo, addCc, and addReplyTo to use the charset if given, so that the names will be properly encoded. Patch created by Ed Korthof. Revision ChangesPath 1.14

Re: [PROPOSAL] Jakarta Commons moving to JIRA

I'm -0 on moving Digester (the project I mostly contribute to). It's purely on philosophical grounds. While it's kind of the JIRA team to grant free use of their product I would prefer to stay with something free. I'm not opposed to commercial products but bug/issue tracking is a core development

Re: [PROPOSAL] Jakarta Commons moving to JIRA

What about jakarta-commons-sandbox projects? Note that there is potential for a name overlap problem, e.g. jakarta-commons [myproject] and a jakarta-commons-sandbox [myproject], although I do not believe this is currently the case. michael On Mon, 12 Jan 2004, Noel J. Bergman wrote: > Guys

RE: [collections] RC1 Maven site for review

On Mon, 12 Jan 2004, Gary Gregory wrote: > The site http://cvs.apache.org/~tobrien/docs/ is indeed consistent with the > other links but, for me, battleship grey is not the most attractive > background color. A red font color for the headings (call me crazy ;-) is a > bit unusual since I kind of t

RE: [codec] multipart encoders/decoders

On Mon, 12 Jan 2004, Noel J. Bergman wrote: > James has code for implementing some of the RFC mandated stream encodings, > too. Noel, this is in line with codec's history. Not necessarily an innovator but an aggregator of code that already exists within the ASF. Just trying to reduce the dupl

cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestHttpConnectionManager.java

olegk 2004/01/12 15:03:12 Modified:httpclient/src/java/org/apache/commons/httpclient HttpMethodDirector.java httpclient/src/test/org/apache/commons/httpclient TestHttpConnectionManager.java Log: PR #25370 (exception dur

RE: [collections] RC1 Maven site for review

Hello, A suggestion: I would break up the sentence: "The JavaDoc API documents are available online for the current release 3.0, the previous version 2.1, and the latest CVS." Into an or a little table. Gary > -Original Message- > From: Tim O'Brien [mailto:[EMAIL PROTECTED] > Sent: Sund

RE: [collections] RC1 Maven site for review

The site http://cvs.apache.org/~tobrien/docs/ is indeed consistent with the other links but, for me, battleship grey is not the most attractive background color. A red font color for the headings (call me crazy ;-) is a bit unusual since I kind of think of red as "error" or "alert" or "attention! a

Re: [PROPOSAL] Jakarta Commons moving to JIRA

Hmm, I suspect that MATH would be at home there. Lets move it there (if there is no objection). -Mark Noel J. Bergman wrote: Guys, There are separate requests on the table to move BETWIXT, CLI, CODEC, JEXL and CONFIGURATION from Bugzilla to JIRA. JELLY is already there. Are there any other Jak

RE: [collections] RC1 Maven site for review

> -Original Message- > From: Tim O'Brien [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 11, 2004 17:29 > To: Jakarta Commons Developers List > Subject: Re: [collections] RC1 Maven site for review > > +1 for removing the distracting list of components from the left nav and > replacing it

RE: [collections] RC1 Maven site for review

> The other bad thing about including the commons navigation is that it > bumps the Project Info and Project Reports to the bottom. This could be > considered more of a limitation of Maven, I guess. That is a pet peeve of mine as well, always having to scroll down to the bottom of the page to cli

[PROPOSAL] Jakarta Commons moving to JIRA

Guys, There are separate requests on the table to move BETWIXT, CLI, CODEC, JEXL and CONFIGURATION from Bugzilla to JIRA. JELLY is already there. Are there any other Jakarta Commons projects that want to migrate? Are there any that do NOT want to leave bugzilla? Right now, each "project" is a

RE: [collections] rc1 build [WAS: [collections] Version 3.0 - The final stretch]

Hello, Perhaps this could be fixed before the release? Gary > -Original Message- > From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > Sent: Monday, December 29, 2003 14:48 > To: Jakarta Commons Developers List > Subject: Re: [collections] Version 3.0 - The final stretch > > I have bee

cvs commit: jakarta-commons-sandbox/codec-multipart/src/test/org/apache/commons/codec/multipart MultipartTest.java

mdiggory2004/01/12 14:24:42 Modified:codec-multipart/src/test/org/apache/commons/codec/multipart MultipartTest.java Log: make sure file is still removed even if test fails. Revision ChangesPath 1.3 +103 -104 jakarta-commons-sandbox/codec-mu

cvs commit: jakarta-commons-sandbox/codec-multipart/src/test/org/apache/commons/codec/multipart result.txt MultipartTest.java

mdiggory2004/01/12 14:20:05 Modified:codec-multipart/src/test/org/apache/commons/codec/multipart MultipartTest.java Added: codec-multipart/src/test/org/apache/commons/codec/multipart result.txt Log: and actual test that works.

cvs commit: jakarta-commons-sandbox/codec-multipart/src/java/org/apache/commons/codec/multipart MultipartCodecFactory.java

mdiggory2004/01/12 14:19:47 Modified:codec-multipart/src/java/org/apache/commons/codec/multipart MultipartCodecFactory.java Log: newInstance would be reserved for the actuall factory. Revision ChangesPath 1.2 +5 -5 jakarta-commons-sandb

cvs commit: jakarta-commons-sandbox/codec-multipart/src/java/org - New directory

mdiggory2004/01/12 13:42:32 jakarta-commons-sandbox/codec-multipart/src/java/org - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/codec-multipart/src/test/org/apache/commons/codec - New directory

mdiggory2004/01/12 13:42:33 jakarta-commons-sandbox/codec-multipart/src/test/org/apache/commons/codec - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/codec-multipart/src/test/org/apache/commons/codec/multipart - New directory

mdiggory2004/01/12 13:42:33 jakarta-commons-sandbox/codec-multipart/src/test/org/apache/commons/codec/multipart - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/codec-multipart/src/java/org/apache/commons/codec/multipart/util - New directory

mdiggory2004/01/12 13:42:32 jakarta-commons-sandbox/codec-multipart/src/java/org/apache/commons/codec/multipart/util - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROT

cvs commit: jakarta-commons-sandbox/codec-multipart/src/java/org/apache/commons/codec/multipart - New directory

mdiggory2004/01/12 13:42:32 jakarta-commons-sandbox/codec-multipart/src/java/org/apache/commons/codec/multipart - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/codec-multipart/src/test/org/apache/commons - New directory

mdiggory2004/01/12 13:42:33 jakarta-commons-sandbox/codec-multipart/src/test/org/apache/commons - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/codec-multipart/src/java/org/apache/commons - New directory

mdiggory2004/01/12 13:42:32 jakarta-commons-sandbox/codec-multipart/src/java/org/apache/commons - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/codec-multipart/src/java/org/apache/commons/codec/multipart/spi - New directory

mdiggory2004/01/12 13:42:32 jakarta-commons-sandbox/codec-multipart/src/java/org/apache/commons/codec/multipart/spi - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTE

cvs commit: jakarta-commons-sandbox/codec-multipart/src/java/org/apache/commons/codec - New directory

mdiggory2004/01/12 13:42:32 jakarta-commons-sandbox/codec-multipart/src/java/org/apache/commons/codec - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/codec-multipart/src/java - New directory

mdiggory2004/01/12 13:42:32 jakarta-commons-sandbox/codec-multipart/src/java - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/codec-multipart/src/java/org/apache - New directory

mdiggory2004/01/12 13:42:32 jakarta-commons-sandbox/codec-multipart/src/java/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/codec-multipart/src - New directory

mdiggory2004/01/12 13:42:32 jakarta-commons-sandbox/codec-multipart/src - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections Bag.java

scolebourne2004/01/12 13:41:41 Modified:collections/src/java/org/apache/commons/collections Bag.java Log: Javadoc tidy Revision ChangesPath 1.14 +6 -6 jakarta-commons/collections/src/java/org/apache/commons/collections/Bag.java Index: Bag.java ==

cvs commit: jakarta-commons-sandbox/codec-multipart - New directory

mdiggory2004/01/12 13:41:18 jakarta-commons-sandbox/codec-multipart - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: [collections] RC1 Maven site for review

From: "Tim O'Brien" <[EMAIL PROTECTED]> > On Mon, 12 Jan 2004, Stephen Colebourne wrote: > > > It looks good in these colours, but the left nav font is larger, so the > > javadoc lines wrap. They probably just don't need indenting so much, and > > maybe a minimum width for the column. > > > > Howev

Re: Bugzilla Admin request

Could someone with access add a new component "configuration" under the program "commons" in Bugzilla? Would Jakarta Commons like to migrate into Jira? We're in the process (literally in the process) of bringing it live tonight. Jelly is already in there, and we can import from Bugzilla selecti

RE: [codec] multipart encoders/decoders

James has code for implementing some of the RFC mandated stream encodings, too. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss TextInput.java

rdonkin 2004/01/12 12:33:34 Added: betwixt/src/test/org/apache/commons/betwixt/examples/rss TextInput.java Log: RSS Example for tutorial (based on the Digester classes). The idea is that maven will create nice coloured source which I can link from the words

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss TestRSS.java

rdonkin 2004/01/12 12:33:01 Added: betwixt/src/test/org/apache/commons/betwixt/examples/rss TestRSS.java Log: RSS Example for tutorial (based on the Digester classes). The idea is that maven will create nice coloured source which I can link from the words.

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss RSSApplication.java

rdonkin 2004/01/12 12:32:37 Added: betwixt/src/test/org/apache/commons/betwixt/examples/rss RSSApplication.java Log: RSS Example for tutorial (based on the Digester classes). The idea is that maven will create nice coloured source which I can link from the

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss rss-example.xml

rdonkin 2004/01/12 12:32:10 Added: betwixt/src/test/org/apache/commons/betwixt/examples/rss rss-example.xml Log: RSS Example for tutorial (based on the Digester classes). The idea is that maven will create nice coloured source which I can link from the word

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss Image.java

rdonkin 2004/01/12 12:31:50 Added: betwixt/src/test/org/apache/commons/betwixt/examples/rss Image.java Log: RSS Example for tutorial (based on the Digester classes). The idea is that maven will create nice coloured source which I can link from the words.

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss package.html

rdonkin 2004/01/12 12:30:47 Added: betwixt/src/test/org/apache/commons/betwixt/examples/rss package.html Log: RSS Example for tutorial (based on the Digester classes). The idea is that maven will create nice coloured source which I can link from the words.

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss Item.java

rdonkin 2004/01/12 12:30:18 Added: betwixt/src/test/org/apache/commons/betwixt/examples/rss Item.java Log: RSS Example for tutorial (based on the Digester classes). The idea is that maven will create nice coloured source which I can link from the words.

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss Image.betwixt

rdonkin 2004/01/12 12:29:54 Added: betwixt/src/test/org/apache/commons/betwixt/examples/rss Image.betwixt Log: RSS Example for tutorial (based on the Digester classes). The idea is that maven will create nice coloured source which I can link from the words.

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss Channel.java

rdonkin 2004/01/12 12:29:27 Added: betwixt/src/test/org/apache/commons/betwixt/examples/rss Channel.java Log: RSS Example for tutorial (based on the Digester classes). The idea is that maven will create nice coloured source which I can link from the words.

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss Channel.betwixt

rdonkin 2004/01/12 12:29:08 Added: betwixt/src/test/org/apache/commons/betwixt/examples/rss Channel.betwixt Log: RSS Example for tutorial (based on the Digester classes). The idea is that maven will create nice coloured source which I can link from the word

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss rss-0.91.dtd

rdonkin 2004/01/12 12:28:45 Added: betwixt/src/test/org/apache/commons/betwixt/examples/rss rss-0.91.dtd Log: RSS Example for tutorial (based on the Digester classes). The idea is that maven will create nice coloured source which I can link from the words.

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss - New directory

rdonkin 2004/01/12 12:27:12 jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples/rss - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples - New directory

rdonkin 2004/01/12 12:27:00 jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/examples - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/betwixt/xdocs/guide tutorial.xml

rdonkin 2004/01/12 12:26:48 Added: betwixt/xdocs/guide tutorial.xml Log: Start of a small tutorial on RSS. We're hopefully going to be taking a look at using Betwixt meta data to generate some mappings in JaxME and this is a good place for the JaxME team to start learning. R

DO NOT REPLY [Bug 26072] New: - Null pointer exception being thrown in SLQNestedException

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: [PATCH] Re: [jexl] - checking for unresolved variables

On Mon, 2004-01-12 at 16:28, Geir Magnusson Jr wrote: > To be clear, I *really* don't think it's a good idea to break usage. That sounds reasonable. It's a judgement call on when it's a good time to break backwards compatibility and I don't know enough about Jexl. > Now, I certainly agree that

RE: [collections] Time for 3.0 RC1?

+1 -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, January 10, 2004 11:24 AM To: Jakarta Commons Developers List Subject: [collections] Time for 3.0 RC1? I reckon its time, as everything now seems quiet. Stephen ---

RE: [codec] multipart encoders/decoders

> -Original Message- > From: Tim O'Brien [mailto:[EMAIL PROTECTED] > Sent: Monday, January 12, 2004 11:06 > To: Jakarta Commons Developers List > Subject: Re: [codec] multipart encoders/decoders > [snip] > 1. Commons exists as an effort to encourage code reuse. The Streamable > framework

RE: [codec] multipart encoders/decoders

How about the following? (0) [codec] is now stable, in CVS and as a released 1.2. I am working now and then to get better unit test code coverage (clover), improving Javadocs, small things like that, and bug fixes of course, we just fixed an important URLCodec one in fact. (1) Yes, open a new san

Re: [codec] JIRA

Gary Gregory wrote: > [...] > I say $X and "no there is no OS alternatives, there use to be, but they died a long time again 'cuz some companies got really clever and offered their stuff for free to OS projects". > > [...] Good point. ---

Re: [codec] multipart encoders/decoders

On Mon, 12 Jan 2004, Mark R. Diggory wrote: > (3) work directly in the codec project? Mark, please feel free to add this to the codec HEAD in commons proper. Here are a few good rules of thumb: 1. Commons exists as an effort to encourage code reuse. The Streamable framework presented was in

RE: [codec] JIRA

On Mon, 12 Jan 2004, Gary Gregory wrote: > Personally, I do not care. Gary, no need to feel bad about raising the issue. I've had the same reservations, OS projects should try to encourage other OS projects. On the other hand, although Jira is commercial Atlassian is a very "open" company bo

RE: [codec] JIRA

Personally, I do not care. In the long term, here is what I am worried about (keep the tomates at bay SVP ;-), I 'm just talkin' here: OS projects like ours use Clover and JIRA and who knows what other NON-OS projects in the future. Clover rocks, JIRA is pretty and all. Users and developers like u

[codec] multipart encoders/decoders

If we want eventually add multipart encoders/decoders to codec, should we: (1) reopen the codec sandbox, (2) start a new sandbox project, or (3) work directly in the codec project? I currently have extracted the multipart post encoding from the HttpClient multipart post code and am working on an

Re: [jexl] - checking for unresolved variables

Getting to this thread a few days late. Will read. Initial comments - you need to be sure that you don't get fooled by a sequence of expressions that will resolve ok - IOW, an assignment a = b; w/ 'b' in the context should result in 'OK' for an unresolved check even though a isn't in the c

Re: [PATCH] Re: [jexl] - checking for unresolved variables

On Jan 11, 2004, at 3:28 PM, peter royal wrote: On Jan 11, 2004, at 2:54 PM, Bill Horsman wrote: On Sun, 2004-01-11 at 20:46, peter royal wrote: So if implement the Map interface (or expose it) then you run the risk of another class just calling get() instead of getVar() and bypassing my strict

Re: Bugzilla Admin request

On Jan 12, 2004, at 6:47 AM, peter royal wrote: On Jan 11, 2004, at 11:58 PM, Noel J. Bergman wrote: Tim O'Brien wrote: Could someone with access add a new component "configuration" under the program "commons" in Bugzilla? Would Jakarta Commons like to migrate into Jira? We're in the process (l

  1   2   >