Re: [VOTE] Release Commons Transaction 1.2
(rising from the ether) +1, looks good to me. Tim On 3/7/07, Daniel Florey [EMAIL PROTECTED] wrote: Go for it! +1 Daniel -- Forwarded message -- From: Oliver Zeigermann [EMAIL PROTECTED] Date: 04.03.2007 17:19 Subject: [VOTE] Release Commons Transaction 1.2 To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Folks! Every now and then I make a new approach to finally release commons transaction 1.2. I have created a branch for the 1.2 version now TRANSACTION_1_2_RELEASE_BRANCH and a release tag TRANSACTION_1_2_RELEASE And have put up the rc4 to http://people.apache.org/~ozeigermann/tx-1.2rc4/ for inspection. This includes the distributions and a preview of the site updated for 1.2. To release 1.2 final based on that release candidate here is my +1 Cheers Oliver -- -- Tim O'Brien Phone: (847) 863-7045 Fax: (866) 314-3323 SkypeIn: (347) 410-9085 Skype: tmobrien AIM: TimNinja
[codec] invalid source tarball on www.apache.org/dist
This file http://www.apache.org/dist/jakarta/commons/codec/source/commons-codec-1.3-src.tar.gz doesn't have the appropriate commons-codec-1.3/ directory in front of each entry. When you unpack it in a directory, it just throws the contents of the source distro into the current directory. So, to fix this, I propose re-releasing this one file. I wasn't the release manager for the 1.3 release, but I'd be happy enough to repackage just this release from source, sign and seal it. Does anyone have any objections to replacing the 1.3 source release with a file that follows the convention? Tim O'Brien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Messenger] Abandonware?
All source has been moved to SVN: try http://svn.apache.org/repos/asf/jakarta/commons [EMAIL PROTECTED] wrote: Hi, Has Messenger been abandoned? I can't seem to get the source - couldn't get at CVS. I realize that it is only a sandbox project. Also, CodeHaus also has a project named Messenger also contributed to by James Strachan. Seems like a useful project. Is anyone using it? Can anyone recommend it? Thanks, Bub - 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]
[all][sandbox] removing promoted components
AFAIK, promotion from the sandbox is now just an svn move. This doesn't help us with components that were promoted before the svn migration. Does anyone have any objections to svn rm-ing the following directories. This is just a start.. /jakarta/commons/sandbox/betwixt /jakarta/commons/sandbox/codec /jakarta/commons/sandbox/digester /jakarta/commons/sandbox/el /jakarta/commons/sandbox/jelly /jakarta/commons/sandbox/math Also, seems like we could move the tags in /jakarta/commons/sandbox/configuration/tags over to /jakarta/commons/proper/configuration/tags - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][sandbox] removing promoted components
Emmanuel Bourg wrote: Tim O'Brien wrote: Also, seems like we could move the tags in /jakarta/commons/sandbox/configuration/tags over to /jakarta/commons/proper/configuration/tags No problem as long as we preserve the history of the work done on [configuration] when it was in the sandbox. History is all there after an svn rm (that's the good thing about svn vs. cvs), you can still backtrack to a revision that has the releases. I'll svn rm configuration Tim O'Brien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][sandbox] removing promoted components
Simon Kitching wrote: On Mon, 2005-07-04 at 23:53 +0200, Thomas Dudziak wrote: On 7/4/05, Tim O'Brien [EMAIL PROTECTED] wrote: AFAIK, promotion from the sandbox is now just an svn move. This doesn't help us with components that were promoted before the svn migration. Does anyone have any objections to svn rm-ing the following directories. This is just a start.. /jakarta/commons/sandbox/betwixt /jakarta/commons/sandbox/codec /jakarta/commons/sandbox/digester /jakarta/commons/sandbox/el /jakarta/commons/sandbox/jelly /jakarta/commons/sandbox/math Also, seems like we could move the tags in /jakarta/commons/sandbox/configuration/tags over to /jakarta/commons/proper/configuration/tags While you're at it, you could also remove commons-sql (migrated to db.apache.org/ddlutils) :-) +1 on removing Digester sandbox stuff. done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][sandbox] removing promoted components
Thomas Dudziak wrote: On 7/4/05, Tim O'Brien [EMAIL PROTECTED] wrote: AFAIK, promotion from the sandbox is now just an svn move. This doesn't help us with components that were promoted before the svn migration. Does anyone have any objections to svn rm-ing the following directories. This is just a start.. /jakarta/commons/sandbox/betwixt /jakarta/commons/sandbox/codec /jakarta/commons/sandbox/digester /jakarta/commons/sandbox/el /jakarta/commons/sandbox/jelly /jakarta/commons/sandbox/math Also, seems like we could move the tags in /jakarta/commons/sandbox/configuration/tags over to /jakarta/commons/proper/configuration/tags While you're at it, you could also remove commons-sql (migrated to db.apache.org/ddlutils) :-) Alright, sandbox/sql removed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[io] Using PathableClassLoader for
This test case [1] needs a transient class loader, and without it it is really not testing the functionality of ClassLoaderObjectInputStream. Anyone have any objection to trying to use the PathableClassLoader that Simon Kitching just checked in for logging? [1] http://svn.apache.org/repos/asf/jakarta/commons/proper/io/trunk/src/test /org/apache/commons/io/input/ClassLoaderObjectInputStreamTest.java - Tim O'Brien [EMAIL PROTECTED] (847) 863-7045 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VOTE: FeedParser move to Commons Proper...
I'm +1 for the following reason: It does make sense that feedparser would be a higher level subproject of Jakarta and not a commons component, but it doesn't make sense to promote a 3 person community to subproject status just yet. I think feedparser should follow the path of commons math and httpclient. Stay on the commons-dev mailing lists, and when the community grows start thinking about migrating out of the commons. +1 To promote feedparser out of commons at this point might create the possibility for another BCEL. Tim O'Brien -Original Message- From: Kevin A. Burton [mailto:[EMAIL PROTECTED] Sent: Friday, February 04, 2005 1:18 PM To: Jakarta Commons Developers List Subject: Re: VOTE: FeedParser move to Commons Proper... Dion Gillard wrote: Dirk, from what I can see feedparser seems more like a top level java project than a commons one. Maybe it should go straight from the sandbox to jakarta? What I'm worried about this is that we might be a bit early for a top level java project. We only have 3 developers and we haven't done a release yet (because we're prevented from doing one). Maybe its time for the incubator but I'm a bit nervous about that since it seems REALLY complicated from my perspective. Maybe its easier now... My current goal of moving from the sandbox to the commons was to do a release and just get more developers. Then in a couple months we can look at the situation again. Is there a pattern of projects moving from the commons to a top level jakarta project? I just want to do whats easy and conventional for now ;) 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: subeclipse
-Original Message- From: Steve Cohen [mailto:[EMAIL PROTECTED] (he doesn't see synchronize as a must-have, I won't take subeclipse seriously until it has it - but nonetheless says the release version will have it) +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] correction was RE: [ALL] Checking Out Trunk Of All Commons Packages
If you were following both commons-dev and commons-user you would've seen that we already did this on Thursday :-). Please use trunks-proper and trunks-sandbox as they already contain the files migrated from the jakarta-commons and jakarta-commons-sandbox modules. Various builds will fail if you try to build without these files. The correct commands follow: svn checkout http://svn.apache.org/respos/asf/jakarta/commons/trunks-proper jakarta-commons and svn checkout http://svn.apache.org/respos/asf/jakarta/commons/trunks-sandbox jakarta-commons-sandbox Tim O'Brien -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Sunday, January 30, 2005 12:33 AM To: Jakarta Commons Developers List; Jakarta Commons Users List Subject: [ALL] Checking Out Trunk Of All Commons Packages Martin Cooper took advantage of an ability of Subversion (after being pointed at it by Tim O'Brien -- thanks Tim and Martin!) to use the svn:externals capability to create a pseudo-directory of the trunk subdirectory for each Struts subproject. I've implemented the same technique for Commons Proper and Commons Sandbox packages. To check out the trunk (in CVS terms, the HEAD) branch of each Commons Proper and Commons Sandbox package, execute the following commands: mkdir /path/to/jakarta/commons/proper cd /path/to/jakarta/commons/proper svn checkout http://svn.apache.org/respos/asf/jakarta/commons/proper/current mkdir /path/to/jakarta/commons/sandbox cd /path/to/jakarta/commons/sandbox svn checkout http://svn.apache.org/respos/asf/jakarta/commons/sandbox/current A couple of notes: * You can, of course, customize the /path/to/jakarta/commons part of the paths above. * Commons committers should use https in place of http in the above URLs, so that you'll be able to do commits. Craig McClanahan - 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]
Removing Graduated Components from trunks-sandbox was RE: svn commit: r149149 - jakarta/commons/trunks-sandbox
I agree with this commit. I think once a component has graduated it should no longer be a part of the sandbox, but we might need to make some exceptions for things like CLI. I believe CLI2 was developed in the sandbox eventhough CLI was in proper. Anyone else have any strong feelings here? Someone had mentioned that it would be valuable to preserve history by copying sandbox tags and branches to an archives directory for each component at the same level as branches and tags? Anyone? Tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, January 30, 2005 2:07 PM To: [EMAIL PROTECTED] Subject: svn commit: r149149 - jakarta/commons/trunks-sandbox Author: dirkv Date: Sun Jan 30 12:06:37 2005 New Revision: 149149 URL: http://svn.apache.org/viewcvs?view=revrev=149149 Log: update svn:externals Modified: jakarta/commons/trunks-sandbox/ (props changed) Propchange: jakarta/commons/trunks-sandbox/ -- --- svn:externals (original) +++ svn:externals Sun Jan 30 12:06:37 2005 @@ -1,69 +1,35 @@ -amend https://svn.apache.org/repos/asf/jakarta/commons/sandbox/amend /trunk -armi https://svn.apache.org/repos/asf/jakarta/commons/sandbox/armi/ trunk -attributes https://svn.apache.org/repos/asf/jakarta/commons/sandbox/attri butes/trunk -betwixt https://svn.apache.org/repos/asf/jakarta/commons/sandbox/betwi xt/trunk -bzip2 https://svn.apache.org/repos/asf/jakarta/commons/sandbox/bzip2 /trunk +commons-build https://svn.apache.org/repos/asf/jakarta/commons/proper/common s-build/trunk cache https://svn.apache.org/repos/asf/jakarta/commons/sandbox/cache /trunk cadastre https://svn.apache.org/repos/asf/jakarta/commons/sandbox/cadas tre/trunk -chain https://svn.apache.org/repos/asf/jakarta/commons/sandbox/chain /trunk -cjan https://svn.apache.org/repos/asf/jakarta/commons/sandbox/cjan/ trunk clazz https://svn.apache.org/repos/asf/jakarta/commons/sandbox/clazz /trunk cli https://svn.apache.org/repos/asf/jakarta/commons/sandbox/cli/t runk -codec https://svn.apache.org/repos/asf/jakarta/commons/sandbox/codec/trunk codec-multipart https://svn.apache.org/repos/asf/jakarta/commons/sandbox/codec -multipart/trunk compress https://svn.apache.org/repos/asf/jakarta/commons/sandbox/compr ess/trunk -configuration https://svn.apache.org/repos/asf/jakarta/commons/sandbox/confi guration/trunk contract https://svn.apache.org/repos/asf/jakarta/commons/sandbox/contr act/trunk convert https://svn.apache.org/repos/asf/jakarta/commons/sandbox/conve rt/trunk -daemon https://svn.apache.org/repos/asf/jakarta/commons/sandbox/daemo n/trunk -dbutils https://svn.apache.org/repos/asf/jakarta/commons/sandbox/dbuti ls/trunk -digester https://svn.apache.org/repos/asf/jakarta/commons/sandbox/diges ter/trunk -discovery https://svn.apache.org/repos/asf/jakarta/commons/sandbox/disco very/trunk -el https://svn.apache.org/repos/asf/jakarta/commons/sandbox/el/trunk email https://svn.apache.org/repos/asf/jakarta/commons/sandbox/email /trunk events https://svn.apache.org/repos/asf/jakarta/commons/sandbox/event s/trunk feedparser https://svn.apache.org/repos/asf/jakarta/commons/sandbox/feedp arser/trunk -fileupload https://svn.apache.org/repos/asf/jakarta/commons/sandbox/fileu pload/trunk filters https://svn.apache.org/repos/asf/jakarta/commons/sandbox/filte rs/trunk functor https://svn.apache.org/repos/asf/jakarta/commons/sandbox/funct or/trunk grant https://svn.apache.org/repos/asf/jakarta/commons/sandbox/grant /trunk -graph https://svn.apache.org/repos/asf/jakarta/commons/sandbox/graph /trunk graph2 https://svn.apache.org/repos/asf/jakarta/commons/sandbox/graph 2/trunk http https://svn.apache.org/repos/asf/jakarta/commons/sandbox/http/ trunk i18n https://svn.apache.org/repos/asf/jakarta/commons/sandbox/i18n/ trunk id https://svn.apache.org/repos/asf/jakarta/commons/sandbox/id/trunk javaflow https://svn.apache.org/repos/asf/jakarta/commons/sandbox/javaf low/trunk jci
New svnmailer was RE: svn commit: r149149 - jakarta/commons/trunks-sandbox
If you are not following the infrastructure list, note that this is the first email notification of a change to a Subversion property. Justin Erenkrantz just installed svnmailer (http://opensource.perlig.de/svnmailer/doc-1.0/) this afternoon. Tim O'Brien -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, January 30, 2005 2:07 PM To: [EMAIL PROTECTED] Subject: svn commit: r149149 - jakarta/commons/trunks-sandbox Author: dirkv Date: Sun Jan 30 12:06:37 2005 New Revision: 149149 URL: http://svn.apache.org/viewcvs?view=revrev=149149 Log: update svn:externals Modified: jakarta/commons/trunks-sandbox/ (props changed) Propchange: jakarta/commons/trunks-sandbox/ -- --- svn:externals (original) +++ svn:externals Sun Jan 30 12:06:37 2005 @@ -1,69 +1,35 @@ -amend https://svn.apache.org/repos/asf/jakarta/commons/sandbox/amend /trunk -armi https://svn.apache.org/repos/asf/jakarta/commons/sandbox/armi/ trunk -attributes https://svn.apache.org/repos/asf/jakarta/commons/sandbox/attri butes/trunk -betwixt https://svn.apache.org/repos/asf/jakarta/commons/sandbox/betwi xt/trunk -bzip2 https://svn.apache.org/repos/asf/jakarta/commons/sandbox/bzip2 /trunk +commons-build https://svn.apache.org/repos/asf/jakarta/commons/proper/common s-build/trunk cache https://svn.apache.org/repos/asf/jakarta/commons/sandbox/cache /trunk cadastre https://svn.apache.org/repos/asf/jakarta/commons/sandbox/cadas tre/trunk -chain https://svn.apache.org/repos/asf/jakarta/commons/sandbox/chain /trunk -cjan https://svn.apache.org/repos/asf/jakarta/commons/sandbox/cjan/ trunk clazz https://svn.apache.org/repos/asf/jakarta/commons/sandbox/clazz /trunk cli https://svn.apache.org/repos/asf/jakarta/commons/sandbox/cli/t runk -codec https://svn.apache.org/repos/asf/jakarta/commons/sandbox/codec/trunk codec-multipart https://svn.apache.org/repos/asf/jakarta/commons/sandbox/codec -multipart/trunk compress https://svn.apache.org/repos/asf/jakarta/commons/sandbox/compr ess/trunk -configuration https://svn.apache.org/repos/asf/jakarta/commons/sandbox/confi guration/trunk contract https://svn.apache.org/repos/asf/jakarta/commons/sandbox/contr act/trunk convert https://svn.apache.org/repos/asf/jakarta/commons/sandbox/conve rt/trunk -daemon https://svn.apache.org/repos/asf/jakarta/commons/sandbox/daemo n/trunk -dbutils https://svn.apache.org/repos/asf/jakarta/commons/sandbox/dbuti ls/trunk -digester https://svn.apache.org/repos/asf/jakarta/commons/sandbox/diges ter/trunk -discovery https://svn.apache.org/repos/asf/jakarta/commons/sandbox/disco very/trunk -el https://svn.apache.org/repos/asf/jakarta/commons/sandbox/el/trunk email https://svn.apache.org/repos/asf/jakarta/commons/sandbox/email /trunk events https://svn.apache.org/repos/asf/jakarta/commons/sandbox/event s/trunk feedparser https://svn.apache.org/repos/asf/jakarta/commons/sandbox/feedp arser/trunk -fileupload https://svn.apache.org/repos/asf/jakarta/commons/sandbox/fileu pload/trunk filters https://svn.apache.org/repos/asf/jakarta/commons/sandbox/filte rs/trunk functor https://svn.apache.org/repos/asf/jakarta/commons/sandbox/funct or/trunk grant https://svn.apache.org/repos/asf/jakarta/commons/sandbox/grant /trunk -graph https://svn.apache.org/repos/asf/jakarta/commons/sandbox/graph /trunk graph2 https://svn.apache.org/repos/asf/jakarta/commons/sandbox/graph 2/trunk http https://svn.apache.org/repos/asf/jakarta/commons/sandbox/http/ trunk i18n https://svn.apache.org/repos/asf/jakarta/commons/sandbox/i18n/ trunk id https://svn.apache.org/repos/asf/jakarta/commons/sandbox/id/trunk javaflow https://svn.apache.org/repos/asf/jakarta/commons/sandbox/javaf low/trunk jci https://svn.apache.org/repos/asf/jakarta/commons/sandbox/jci/t runk -jdbc2pool https://svn.apache.org/repos/asf/jakarta/commons/sandbox/jdbc2 pool/trunk -jelly https://svn.apache.org/repos/asf
RE: [all] correction was RE: [ALL] Checking Out Trunk Of All Commons Packages
Understood, same problem with spam filters. We can eventually move these to current, but when we do, let's gets docs updated and do an svn move. -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Sunday, January 30, 2005 3:24 PM To: Jakarta Commons Users List Cc: Jakarta Commons Developers List Subject: Re: [all] correction was RE: [ALL] Checking Out Trunk Of All Commons Packages I try to follow these lists, but Gmail's spam filter ate these and I didn't see them :-(. Glad to see someone had already done this. Craig On Sun, 30 Jan 2005 14:45:34 -0500, Tim O'Brien [EMAIL PROTECTED] wrote: If you were following both commons-dev and commons-user you would've seen that we already did this on Thursday :-). Please use trunks-proper and trunks-sandbox as they already contain the files migrated from the jakarta-commons and jakarta-commons-sandbox modules. Various builds will fail if you try to build without these files. The correct commands follow: svn checkout http://svn.apache.org/respos/asf/jakarta/commons/trunks-proper jakarta-commons and svn checkout http://svn.apache.org/respos/asf/jakarta/commons/trunks-sandbox jakarta-commons-sandbox Tim O'Brien -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Sunday, January 30, 2005 12:33 AM To: Jakarta Commons Developers List; Jakarta Commons Users List Subject: [ALL] Checking Out Trunk Of All Commons Packages Martin Cooper took advantage of an ability of Subversion (after being pointed at it by Tim O'Brien -- thanks Tim and Martin!) to use the svn:externals capability to create a pseudo-directory of the trunk subdirectory for each Struts subproject. I've implemented the same technique for Commons Proper and Commons Sandbox packages. To check out the trunk (in CVS terms, the HEAD) branch of each Commons Proper and Commons Sandbox package, execute the following commands: mkdir /path/to/jakarta/commons/proper cd /path/to/jakarta/commons/proper svn checkout http://svn.apache.org/respos/asf/jakarta/commons/proper/current mkdir /path/to/jakarta/commons/sandbox cd /path/to/jakarta/commons/sandbox svn checkout http://svn.apache.org/respos/asf/jakarta/commons/sandbox/current A couple of notes: * You can, of course, customize the /path/to/jakarta/commons part of the paths above. * Commons committers should use https in place of http in the above URLs, so that you'll be able to do commits. Craig McClanahan - 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: svn commit: r149171 - in jakarta/commons: proper/commons-build/trunk/ sandbox/cli/trunk/ sandbox/codec-multipart/trunk/ sandbox/compress/trunk/ sandbox/compress/trunk/xdocs/ sandbox/contract/trunk/ sandbox/contract/trunk/xdocs/ sandbox/convert/trunk/
Can't think of a general solution that doesn't involve a complete break from what we do. What you've done is optimize the system for people checking out trunks-proper or trunk-sandbox which (IMO) is the way to go. What I was saying was that, if you wanted to work with a specific branch or tag of a specific component you would start by checking out the trunks-proper, then cd to the component directory and svn switch to the tag or branch. That way, you are still referencing commons-build as ../commons-build. Right now we reference ../commons-build - a completely *insane* idea would be to move that dependency up one level. A component directory could, itself, have an svn:externals property which referenced commons-build. This way, instead of depending on sibling directories, every component could be treated as an isolated build. I think that this concept would only work if we separated all of the commons site content from commons-build, and had commons-build only contain content that must be referenced from all projects. The other possibility this brings up is the ability to have older tags of component reference specific versions of commons-build. That solutions isn't necessarily pretty, but it would solve the problem for people who checkout trunks-proper and inidividual components. But, I'll be the first to admit it is heavy on the svn:externals property. Tim -Original Message- From: Dirk Verbeeck [mailto:[EMAIL PROTECTED] Sent: Sunday, January 30, 2005 4:52 PM To: Jakarta Commons Developers List Subject: Re: svn commit: r149171 - in jakarta/commons: proper/commons-build/trunk/ sandbox/cli/trunk/ sandbox/codec-multipart/trunk/ sandbox/compress/trunk/ sandbox/compress/trunk/xdocs/ sandbox/contract/trunk/ sandbox/contract/trunk/xdocs/ sandbox/convert/trunk/ I know this is only a small improvement from the previous situation. If you do an individual checkout you still have to make sure you have the correct path to a commons-build directory. Is there a better way to include global information? -- Dirk Tim O'Brien wrote: Innovative use of svn:externals, but it does also mean that the only way to build a project with maven is to do so using the trunks-proper or trunk-sandbox directory. This is fine, as long as people know to use svn switch when they want to build an old tag: So, if you want to build an old tag, and you have a checked out the trunks-proper, you'll need to switch to the tag before you do such a thing. The only question this then raises is, if you were to then do an svn update from the trunks-proper directory, would the svn:externals pointing to trunk switch you back to the trunk? Tim - 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: svn commit: r149171 - in jakarta/commons: proper/commons-build/trunk/ sandbox/cli/trunk/ sandbox/codec-multipart/trunk/ sandbox/compress/trunk/ sandbox/compress/trunk/xdocs/ sandbox/contract/trunk/ sandbox/contract/trunk/xdocs/ sandbox/convert/trunk/
Dirk, one more thing, I'd be +1 on svn mv https://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build https://svn.apache.org/repos/asf/jakarta/commons/commons-build As commons-build is relied upon by proper and sandbox components alike, and it is something we could consider shared among them both. This was something we couldn't do with CVS because commons and sandbox were two separate modules. But, that being said, I'm wondering if anyone else has any good reason for not doing this. tim -Original Message- From: Dirk Verbeeck [mailto:[EMAIL PROTECTED] Sent: Sunday, January 30, 2005 4:52 PM To: Jakarta Commons Developers List Subject: Re: svn commit: r149171 - in jakarta/commons: proper/commons-build/trunk/ sandbox/cli/trunk/ sandbox/codec-multipart/trunk/ sandbox/compress/trunk/ sandbox/compress/trunk/xdocs/ sandbox/contract/trunk/ sandbox/contract/trunk/xdocs/ sandbox/convert/trunk/ I know this is only a small improvement from the previous situation. If you do an individual checkout you still have to make sure you have the correct path to a commons-build directory. Is there a better way to include global information? -- Dirk Tim O'Brien wrote: Innovative use of svn:externals, but it does also mean that the only way to build a project with maven is to do so using the trunks-proper or trunk-sandbox directory. This is fine, as long as people know to use svn switch when they want to build an old tag: So, if you want to build an old tag, and you have a checked out the trunks-proper, you'll need to switch to the tag before you do such a thing. The only question this then raises is, if you were to then do an svn update from the trunks-proper directory, would the svn:externals pointing to trunk switch you back to the trunk? Tim - 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: Removing Graduated Components from trunks-sandbox
-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 30, 2005 7:54 PM
To: Jakarta Commons Developers List
Subject: Re: Removing Graduated Components from trunks-sandbox
On Sun, 2005-01-30 at 15:10 -0500, Tim O'Brien wrote:
I agree with this commit.
I think once a component has graduated it should no longer
be a part
of the sandbox, but we might need to make some exceptions
for things
like CLI. I believe CLI2 was developed in the sandbox
eventhough CLI
was in proper.
Anyone else have any strong feelings here?
Someone had mentioned that it would be valuable to preserve
history by
copying sandbox tags and branches to an archives
directory for each
component at the same level as branches and tags? Anyone?
Hmm.. you are proposing that when something gets promoted
from sandbox, that the original sandbox code for {project}
should be moved into this dir?
commons/proper/{project}/archives
Well, I do agree that code that has been promoted from
sandbox should be removed from the sandbox, leaving the
sandbox with only active
projects. However I can't see what else would ever live in
that archives directory; if there is to be a directory
whose only contents will be the old sandbox stuff (including
its own tags, branches, etc), then perhaps
commons/proper/{project}/sandbox-promoted might be a better
name than 'archive'?
I'd imagine that a promotion from sandbox to proper would be
accomplished with an svn mv (component disappears from sandbox,
history moves to proper). History from the sandbox is preserved in this
case, trunks, tags, and branches. I think what we're trying to find an
answer for what happens to the components currently in the sandbox - for
promotions that happened prior to the SVN migration,
commons/proper/{project}/sandbox-promoted sounds like a good solution.
Alternatively, archives of promoted stuff could be stored
externally to the related projects, eg
commons/sandbox-promoted/{project} or
commons/sandbox/promoted/{project}.
I'd be -0.50 to creating another sibling to sandbox or proper.
Because I'm assuming all new promotions would happen with an svn mv.
If a sandbox project should be declared dead, then I think
it also should be moved, to commons/sandbox-dormant (or
commons/sandbox/dormant) or similar. Given this, it might
make more sense to put promoted projects in
commons/sandbox-promoted/{project} than to put them under
the standard project dir.
I'm for commons/sandbox/dormant - some dormant projects have been
revived and have proven useful, but I also think that it is wise to
differentiate between projects actively in the sandbox and projects
suffering from persistent lack of interest. Maybe now that it is so
much easier to just move stuff around we could formalize this with
something like: sandbox projects lacking sufficient interest may be
moved to a dormant directory commons/sandbox/dormant (not linked from
trunks-sandbox). Projects in commons/sandbox/dormant showing a
persistence lack of interest will be svn rm after n months.
Tim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Removing Graduated Components from trunks-sandbox
Right, good point, +1 on commons/sandbox/dormant and commons/proper/dormant. And, components moved to dormant are removed from the svn:externals property of their respective trunks directory. Tim -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Sunday, January 30, 2005 9:09 PM To: Jakarta Commons Developers List Cc: [EMAIL PROTECTED] Subject: Re: Removing Graduated Components from trunks-sandbox On Sun, 30 Jan 2005 21:41:36 -0500, Tim O'Brien [EMAIL PROTECTED] wrote: I'm for commons/sandbox/dormant - some dormant projects have been revived and have proven useful, but I also think that it is wise to differentiate between projects actively in the sandbox and projects suffering from persistent lack of interest. Maybe now that it is so much easier to just move stuff around we could formalize this with something like: sandbox projects lacking sufficient interest may be moved to a dormant directory commons/sandbox/dormant (not linked from trunks-sandbox). Projects in commons/sandbox/dormant showing a persistence lack of interest will be svn rm after n months. IMHO dormant makes sense, but not necessarily under sandbox -- it seems equally possible that a Commons Proper package could go dormant. We should consider either a proper/dormant and a sandbox/dormant structure, or a dormant on the same level as proper and sandbox. +1 on using svn move to put things there, from now on. Tim 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]
RE: Missing components in sandbox?
On Windows, using Eclipse 3.1 with Subclipse 0.9.25 (Dec '05), if you go to SVN Repository browsing and add https://svn.apache.org/repos/asf/jakarta/commons; you will get an error: svn: PROPFIND of '/repos/asf': Server certificate verification failed: issuer is not trusted (https://svn.apache.org) svn doesn't ship with a list of CAs, so you need to accept this permanently for this to work. On Windows, svn is configured to look in C:\Documents and Settings\user\Application Data\Subversion for keys you've accepted. The windows command-line puts a k Another issues to be aware of with Subclipse: Even though you may have read that commits don't cross svn:externals boundaries, they do in Subclipse: http://subclipse.tigris.org/servlets/ReadMsg?list=usersmsgNo=1843 -Original Message- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Friday, January 28, 2005 7:02 AM To: Jakarta Commons Developers List Subject: Re: Missing components in sandbox? The components seem to be in SVN, but I did a checkout like svn co https://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbox jakarta-commons-sandbox as suggested by Tim and now I seem to have the proper components checked out. Am I doing anything wrong? Oliver On Fri, 28 Jan 2005 13:48:49 +0100, Oliver Zeigermann [EMAIL PROTECTED] wrote: Is this only me or are there some components missing in the SVN sandbox version? Where is e.g. xmlio, i18n and contract? 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: SVN migration and LICENSE
My fault, I saw LICENSE.txt and LICENSE and just copied LICENSE.txt, I will copy LICENSE.txt to LICENSE and commit. Tim -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Fri 1/28/2005 9:49 AM To: commons-dev@jakarta.apache.org Subject: SVN migration and LICENSE Hi, during the migration to SVN the file LICENSE went away. This is not too much of a problem, but a few build files want to copy the file and now fail (commons-launcher and commons-threading fail in the current JDK 1.5 Gump run on Brutus beacuse of this, there may be more). 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]
[all] svn migration starting
jakarta-commons and jakarta-commons-sandbox are now locked. The svn migration is proceeding, and we can expect at least 2-3 hours of downtime. I'll update the list when the migration is finished. Tim O'Brien
RE: [all][VOTE][Results] commons svn migration
So, I disappeared and left Justin and Henri fending for themsevles, but it looks like the migration end is in sight. Immediately after the migration, I will create current and add svn:externals for proper, I'll also capture the few files missed by the conversion script. Tim -Original Message- From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 7:15 PM To: Jakarta Commons Developers List Subject: Re: [all][VOTE][Results] commons svn migration --On Wednesday, January 26, 2005 9:43 PM -0500 Phil Steitz [EMAIL PROTECTED] wrote: Committers who have not used ASF svn yet will have to run svnpasswd to get set up, right? Correct. Please see: http://www.apache.org/dev/version-control.html#https-svn HTH. -- justin - 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]
[all] svn migration completed
The SVN migration is finished. First, I take repsonsibility for the dramatic underestimation of 2-3 hours, it took more like 10 hours from start to finish. Justin Erenkrantz and Henri deserve the bulk of your gratitude, they stuck around and made sure the conversion scripts and karma worked properly. Thanks should also to Martin for providing feedback and guidance. Whatever you do, don't checkout /jakarta/commons as you will be checking out a copy of every tag, trunk, and branch and it will take forever and a day. *Instead*, check out individual components, or (more likely) check out trunks-proper or trunks-sandbox: svn co https://svn.apache.org/repos/asf/jakarta/commons/trunks-proper jakarta-commons svn co https://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbox jakarta-commons-sandbox Both of these commands checkout a directory with an svn:externals property set. After executing these commands you'll end up with the same content you would get if you had checked out jakarta-commons or jakarta-commons-sandbox from CVS. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] svn stuff to do and discuss
Some of these things need volunteers, some need discussion: 1. project.xml files need to be updated to reflect the fact that repositories are in SVN. 2. gump project descriptors need to be updated. 3. Should we svn rm components from the sandbox which have been promoted? 4. Should we svn rm components from the sandbox which have become inactive? 5. Does svn affect the way we build the commons site? 6. Much like we have a trunks-proper and trunks-sandbox, would it make any sense to also have a released-proper? Instead of pointing to trunk, svn:externals in this directory would point to the current release tag for each component? 7. I believe jakarta-commons and jakarta-commons-sandbox had different entries in the avail file. Do we want one entry for /jakarta/commons? (More subversive suggestion: Do we want one avail for /jakarta ;=) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all][VOTE][Results] commons svn migration
More than 72 hours have passed for this vote, I think everyone has had ample opportunity to weigh in. We need to do this when Justin is free, and that happens to be Thursday morning or afternoon. Most other conversions are simple one shot conversions, but commons is really more of a series of conversions - each component is converted separately, combined, and then dumped to a dump which we can then import into the ASF repository. It takes 3-4 hours, so when I confirm with Justin, I'll send a note to commons-dev with the time we'll lock the CVS repository. Henri, what, if anything, do we need to do to migrate karma? Vote Summary follows: The original vote message: This is a vote thread for migrating commons to SVN. If this vote passes, I'll contact Justin and schedule the least disruptive migration time possible. Vote: 16 +1s, 4 +0s, 5 -0s, 0 -1s +0 Emmanuel Bourg +1 Don Brown +0 Steve Cohen (+0.75) -0 Stephen Colebourne (-0.9) +1 Martin Cooper +1 Torsten Curdt +1 Mark Diggory +1 Mauro Franceschini +1 Joe Germuska -0 Dion Gillard -0 Hans Glide +1 David Graham -0 Gary Gregory +0 Oliver Heger +1 Ted Husted +0 Mario Ivankovits +1 Jerome Jar +1 Oleg Kalnichevski +1 Paul Libbrecht +1 Alex Karasulu +1 Simon Kitching -0 Peter Royal +1 Phil Steitz +1 Rory Winston +1 Henri Yandell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all][VOTE] svn migration
Alright a sufficient amount of time has passed for public comments and testing. This is a vote thread for migrating commons to SVN. If this vote passes, I'll contact Justin and schedule the least disruptive migration time possible. Tim O'Brien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all][poll] svn conversion
-Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 7:12 PM To: Jakarta Commons Developers List Subject: Re: [all][poll] svn conversion I can checkout using the command line, but not with subclipse. Its late here, so I'm not able to follow much up. Subclipse does want to know where the repository root is though, I'm guesing https://svn.apache.org/repos/test ? (My problem is that I get no structure visible on the SVN repository exploring view) That's because the test repository uses a self-signed certificate. This is not a problem with the real Apache SVN repository. If you want to use a repository served with a self-signed cert with Subclipse, try to access the repository from the command-line and then accept the certificate permanently. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jelly] the .project and .classpath files
Windows - Preferences... Then in the tree menu of configuration panels, choose: Java - Build Path - Classpath Variables Create a new variable MAVEN_REPO, point it at ~/.maven/repository Tim O'Brien [EMAIL PROTECTED] -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] How do you substitute the MAVEN_REPO variable in the paths? If I what I remember still serves, you set a path variable MAVEN_REPO in your Eclipse configuration (in the dependencies section). Sorry, I can't point you to anything directly. - Brett Hans - 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]
[all][poll] svn conversion
Alright folks, it looks like svn has stabilized. Let's have a poll here: any more opinions on the svn conversion? Has everyone had ample time to test? Tim O'Brien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] current dir in SVN test repository (externals)
Paul, Try this repository, https://brahe.discursive.com/svn/commons-test/jakarta/commons/proper/jelly/ The same process was used to generate this that was used to generate the structure of the ASF test repository exception this one has history. This was an export from two weeks ago. Tim -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Friday, January 14, 2005 3:12 AM To: Jakarta Commons Developers List Subject: Re: [all] current dir in SVN test repository (externals) Fine with that but I think it would be nice to have a test at history, at least for one project... paul Le 13 janv. 05, à 19:11, Tim O'Brien a écrit : Paul, I can add Jelly to this mix as well. Let me know if you want me to and I'll put it on my stack. I can assure you that jelly made it into the full conversion. What you are looking at isn't a product of svnadmin load, I performed the migration to a subversion repository, then I exported the current version of all files and added them to the ASF test repository. I did this to same time and minimize the time it took to get something into the test repository. Justin's recommendation was a subset of the entire project without history. Tim -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Thu 1/13/2005 5:33 AM To: Jakarta Commons Developers List Subject: Re: [all] current dir in SVN test repository (externals) Any reason this doesn't exist ? svn co https://svn.apache.org/repos/test/jakarta/commons/proper/jelly/ or this svn co https://svn.apache.org/repos/test/jakarta/commons/current/jelly/ Jelly seems to be nowhere :-( ... for some reasons https://svn.apache.org/repos/test/jakarta/commons/ seems to contain only projects till c... (neither when browsed nor when checked out) paul Le 11 janv. 05, à 15:00, Tim O'Brien a écrit : svn co https://svn.apache.org/repos/test/jakarta/commons/current/ You will get the current trunk for proper components. - 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: [all] current dir in SVN test repository (externals)
Paul, I can add Jelly to this mix as well. Let me know if you want me to and I'll put it on my stack. I can assure you that jelly made it into the full conversion. What you are looking at isn't a product of svnadmin load, I performed the migration to a subversion repository, then I exported the current version of all files and added them to the ASF test repository. I did this to same time and minimize the time it took to get something into the test repository. Justin's recommendation was a subset of the entire project without history. Tim -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Thu 1/13/2005 5:33 AM To: Jakarta Commons Developers List Subject: Re: [all] current dir in SVN test repository (externals) Any reason this doesn't exist ? svn co https://svn.apache.org/repos/test/jakarta/commons/proper/jelly/ or this svn co https://svn.apache.org/repos/test/jakarta/commons/current/jelly/ Jelly seems to be nowhere :-( ... for some reasons https://svn.apache.org/repos/test/jakarta/commons/ seems to contain only projects till c... (neither when browsed nor when checked out) paul Le 11 janv. 05, à 15:00, Tim O'Brien a écrit : svn co https://svn.apache.org/repos/test/jakarta/commons/current/ You will get the current trunk for proper components. - 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]
[all] SVN conversion test repository
A selection of components from commons proper and the sandbox are now available for you to experiment with on ASF hardware. The URL for the ASF test repository is https://svn.apache.org/repos/test Commons is under jakarta/commons A selection of components is available for both the proper and the sandbox. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] current dir in SVN test repository (externals)
I've set the svn:externals properties on the current subdirectory, if you do this: svn co https://svn.apache.org/repos/test/jakarta/commons/current/ You will get the current trunk for proper components. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Jakarta Commons Wiki] New: SigningReleases
-Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] 2) A real maven expert (Brett ;) could probably figure out how to automate almost everything in a way that could be reused across all maven-built projects. Including the signing, hashing and verification in the maven build would be great. I agree with Robert that this probably belongs in the maven community. I am willing to help in any case, either working on plugins to get things to work or documenting how to use maven to cut releases. Ah, a release plugin that would be a good thing! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [svn] progress?
I'm ready for it. I have a bash script that does the migration which takes some time to execute. I'll ping Justin and create test repository on ASF hardware. Then we can discuss the final steps. Tim -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, January 03, 2005 9:26 PM To: Jakarta Commons Developers List Subject: Re: [svn] progress? And upon sending that I remembered that Tim is out for holiday stuff until tomorrow; so the status is that things are on hold until tomorrow. There's a test svn repo; but it's his own and not an official asf one so I won't push that now. Hen On Mon, 3 Jan 2005 22:23:57 -0500, Henri Yandell [EMAIL PROTECTED] wrote: also.ping? On Sun, 2 Jan 2005 13:12:39 +, robert burrell donkin [EMAIL PROTECTED] wrote: ping? - 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: [svn] progress?
Alright, I heard back, infrastructure would like to perform the migration and call it done. Does anyone have any objections to the structure of the last migration, and does anyone have any objections to starting a vote thread on this. Infrastructure (Justin) can do this on Friday. Tim O'Brien -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, January 03, 2005 9:26 PM To: Jakarta Commons Developers List Subject: Re: [svn] progress? And upon sending that I remembered that Tim is out for holiday stuff until tomorrow; so the status is that things are on hold until tomorrow. There's a test svn repo; but it's his own and not an official asf one so I won't push that now. Hen On Mon, 3 Jan 2005 22:23:57 -0500, Henri Yandell [EMAIL PROTECTED] wrote: also.ping? On Sun, 2 Jan 2005 13:12:39 +, robert burrell donkin [EMAIL PROTECTED] wrote: ping? - 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 Results] Moving commons-sql to db.apache.org (repost)
* Ask Infrastructure for creation of a project space (SVN space, mailing lists, etc.) in db.apache.org, including giving commit rights to all db.apache.org committers (if that is possible) * Migrate the repository to the new location (e.g. cvs2svn etc.) - perhaps infrastructure can do this ? How about waiting until Commons is in SVN and then we can just svn move it? Give infrastructure at least a week for this. Has the DB TLP started moving to SVN yet? Also, anyone who has previously performed a commit on the commons-sql project should probably be given the option to retain that level of access. tim
Svn migration - subclipse, scheduling, binaries
So, three issues to know about re: svn: 0. Subclipse: If you use Subclipse - know tha the test repository uses a self-signed cert, you may need to hit the test repository with svn command-line and permanently accept the cert from my machine before you can use subclipse. I was able to checkout the current from Subclipse, so it does honor svn:externals. 1. Scheduling: If we go forward with this migration, we need to do this when everyone is available both so we can migrate successfully and so that we can have a proper 72 hour vote window. Doing this right before a holiday weekend is not the best idea, and I think we could use some more time to work out other issues like security and site publishing. The earliest I can see is a vote thread next week starting on the 27th or 28th, ending on the 30th. That leaves us with the posssibility of a five to six hour migration on new years' eve or day which might work out well. Was thinking this qualifies again as a release majority vote. (To address Torsten's question of waiting to commit until the SVN migration is done, I'd say don't wait for this. Adding another component doesn't create any more work, and I know I wouldn't want to slow down that work at all. Plus, this migration isn't a guaranteed thing.) 2. Binary Files: If you keep jars or other binaries in CVS and these binaries were not added with -kb, the cvs2svn process may have mangled you binaries. I don't think this is going to be a big problem, as most of the well used commons components do not version jars. Just be aware of this issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Svn migration - subclipse, scheduling, binaries
Yes, the intent isn't to leave anyone behind. I just noticed that infrastructure changes don't have a section in the guideline proposal: http://jakarta.apache.org/site/proposal.html#decisions/items From: Henri Yandell well. Was thinking this qualifies again as a release majority vote. At first I thought that it should be consensus, ie) no -1's, but I'm seeing your thinking now. We have two types of -1; firstly there's a -1 because I like CVS and want to stay there; secondly there's a -1 because I can't use SVN in the way I need to. The former should be treated as a majority vote, while the latter should be treated as a consensus vote. So I'm +1 to a release majority vote with the acceptance that we're not going to leave anyone behind. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Enterprise Common Logging... dare we say 2.0?
Robert, we've got some issues to work through and infrastructure wants to wait until at least next week. Don't delay anything on account of the svn migration. From what I see, the transition should be seemless - just a few hours downtime. So, commit away. Tim From: robert burrell donkin commons appears to be in the process of migrating to subversion. i feel an urge to code but it'd be better to take a branch or three to further the discussion in code. so for the moment, i don't think we'll see any commits for a while yet. certainly, i wouldn't feel comfortable with any as yet.
RE: Jakarta Commons Structure rehashed
-Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] I think we're trying to find a compromise that satisfies both. As long as someone can come up with a way to do the equivalent of the '*' URL I mentioned above, I'd be happy with A + that script / tool / method. Add, externals definitions to that list. Assume that /jakarta/commons/proper/current is just a directory with externals to every trunk for components in commons proper, and /jakarta/commons/sandbox/current is just a directory with externals to every trunk for sandbox components. I could also see someone wanted to checkout only the current production release of every component, we could similarly have a /jakarta/commons/proper/production which would contain externals pointing to the latest official release tag. See section 7.3 External Definitions of Version Control with Subversion by Collins-Sussman, Fitzpatrick, and Pilato. You can read that book on Safari or online for free here: http://svnbook.red-bean.com/. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Simulation of proposed svn repository
I took a tgz of both the jakarta-commons and jakarta-commons-sandbox modules and wrote two bash scripts to perform the migration from CVS to SVN with the proposed structure. The scripts ran for about five hours, and the final results are here: (The following svn repository is hosted on my own machine. I pay for bandwidth consumed, so don't do anything like checkout the entire repository with all tags and branches. If I see this happening, I'll take the thing down.) https://brahe.discursive.com/svn/commons-test This repository has the structure discussed, minus the few files in jakarta-commons and jakarta-commons-sandbox. For the people concerned about not being able to check out trunks. An example of using svn:externals is here https://brahe.discursive.com/svn/commons-test/jakarta/commons/current . To keep bandwidth down, the current directory only contains externals to digester, beanutils, and codec. If you check this directory out, you'll get the trunk of these three components. Please read the README file in this directory for some important instructions. I did this for the sake of discussion, have at it. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Oh, and...Simulation of proposed svn repository
If any commons committer needs to commit to this to test an idea, write me an email at [EMAIL PROTECTED] If I recognize your email as that of a commons regular, I'll give you a login. If I don't, I won't. -Original Message- From: Tim O'Brien [mailto:[EMAIL PROTECTED] Sent: Sunday, December 19, 2004 10:22 PM To: Jakarta Commons Developers List Subject: Simulation of proposed svn repository I took a tgz of both the jakarta-commons and jakarta-commons-sandbox modules and wrote two bash scripts to perform the migration from CVS to SVN with the proposed structure. The scripts ran for about five hours, and the final results are here: (The following svn repository is hosted on my own machine. I pay for bandwidth consumed, so don't do anything like checkout the entire repository with all tags and branches. If I see this happening, I'll take the thing down.) https://brahe.discursive.com/svn/commons-test This repository has the structure discussed, minus the few files in jakarta-commons and jakarta-commons-sandbox. For the people concerned about not being able to check out trunks. An example of using svn:externals is here https://brahe.discursive.com/svn/commons-test/jakarta/commons/ current . To keep bandwidth down, the current directory only contains externals to digester, beanutils, and codec. If you check this directory out, you'll get the trunk of these three components. Please read the README file in this directory for some important instructions. I did this for the sake of discussion, have at it. Tim - 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: Jakarta Commons Structure rehashed
Another reason for Option A other than those already listed is that it is consistent with what other projects have already started to adopt (that I've seen), and that goes a long way to ease of use in itself. That's my feeling as well. Even though we could use Option B, I'm more comfortable using what has become an accepted practice. And, I'd expect future tools like subclipse to start looking for trunk, tags, and branches. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Commons Structure rehashed
Not following this one, this implies that ASF has one trunk.Even though copies are cheap I wouldn't want to create a copy of the entire SVN tree for every release. I think you may have mean to propose that we have one trunk in commons. If commons components were frequently released as a group, this may make sense, but commons components have wildly varied release cycles. -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Saturday, December 18, 2004 5:10 AM To: Jakarta Commons Developers List Subject: Re: Jakarta Commons Structure rehashed Henri Yandell wrote: And yet option A is going to be impossible (?) to check out as one whole blob. And what about this option ? Let say option C : trunk/ jakarta/ commons/ digester/ beanutils/ tags/ branches/ Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Commons Structure rehashed
-Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] And yet option A is going to be impossible (?) to check out as one whole blob. We could store two scripts (sh and bat) at the /jakarta/commons level that would only grab the trunks of every component. So, I'd forsee the process as svn co -N http://etc/jakarta/commons cd commons ./get-trunks.sh Or, we could rely on symlinks, but I'm unsure how win clients would handle this. I wonder if there's any magic coming from the SVN guys that'll let us do option B and yet provide a link of some kind to automatically be able to check out all the trunks in one go. Hen On Fri, 17 Dec 2004 14:01:53 -0700, Kris Nuttycombe [EMAIL PROTECTED] wrote: Option A makes the projects look a lot more atomic, which seems like a good idea when one contemplates what will be necessary when promoting projects from the sandbox. Kris Tim O'Brien wrote: I don't think we ever settled this question. Which SVN structure are we interested in? ** Option A: jakarta/ commons/ digester/ trunk/ tags/ branches/ beanutils/ trunk/ tags/ branches/ OR ** Option B: jakarta/ commons/ trunk/ digester/ beanutils/ tags/ digester/ beanutils/ branches/ digester/ beanutils/ -- = Kris Nuttycombe Associate Scientist Geospatial Data Services Group CIRES, National Geophysical Data Center/NOAA (303) 497-6337 [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]
[all] svn migration proposal
The first step to moving to SVN is telling infrastructure exactly what we need. The process is as follows: 1. We tell infrastructure what we need (and volunteer to help) 2. jakarta-commons and jakarta-commons-sandbox are migrated to a test repository 3. If we are happy with what we have after a few days, we can perform the migration to the real repository and lock the CVS module. I have some experience with cvs2svn, but the instructions at http://www.apache.org/dev simply call for a set of instructions which I've included below. Because we have an involved migration process I'll volunteer to help infrastructure. Please review the conversion instructions here: http://wiki.apache.org/jakarta-commons/SubversionConversion
[all] svn conversion instructions for infrastructure
The first step to moving to SVN is telling infrastructure exactly what we need. The process is as follows: 1. We tell infrastructure what we need (and volunteer to help) 2. jakarta-commons and jakarta-commons-sandbox are migrated to a test repository 3. If we are happy with what we have after a few days, we can perform the migration to the real repository and lock the CVS module. I have some experience with cvs2svn, but the instructions at http://www.apache.org/dev simply call for a set of instructions which I've included below. Because we have an involved migration process I'll volunteer to help infrastructure. Please review the conversion instructions here: http://wiki.apache.org/jakarta-commons/SubversionConversion - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta Commons Structure rehashed
-Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Saturday, December 18, 2004 11:12 PM To: Jakarta Commons Developers List Subject: RE: Jakarta Commons Structure rehashed I also prefer the flatter layout: jakarta/commons/tags/ /branches /trunk We don't version Commons as a single component, and I don't know that we want to force everyone to always take every single component. Someone wanting to build all of Commons is not the norm. Agreed, we also don't want to go through the acrobatics of maintaining a jakarta/commons/tags directory with hundreds of subdirectories. Think about just how many tags we have in commons and then contemplate a single directory with every component_name-tag combination, that's going to get silly very fast. Likewise for branches. Each component in commons proper is a component digester has a trunk, it gets tagged, and branches independently of latka. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Commons Structure rehashed
I don't think we ever settled this question. Which SVN structure are we interested in? ** Option A: jakarta/ commons/ digester/ trunk/ tags/ branches/ beanutils/ trunk/ tags/ branches/ OR ** Option B: jakarta/ commons/ trunk/ digester/ beanutils/ tags/ digester/ beanutils/ branches/ digester/ beanutils/
RE: [Vote] Moving commons-sql to db.apache.org (repost)
+1 for commons-sql to db.apache.org And, I'd be +1 for moving commons-dbutils to db.apache.org -Original Message- From: Thomas Dudziak [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 2:33 PM To: [EMAIL PROTECTED]; Jakarta Project Management Committee List; [EMAIL PROTECTED] Subject: [Vote] Moving commons-sql to db.apache.org (repost) (This is a repost from a vote that I started earlier today, but where I did not include commons-dev. This omission has been pointed out to me, and I agree that including commons-dev is important, so I repost the vote hereby) Hi all, I'd like to start a cross-vote (Jakarta PMC and commons-dev, DB PMC) about moving the jakarta sandbox project commons-sql (http://jakarta.apache.org/commons/sandbox/sql/) over to db.apache.org, for instance into the currently vacant db-commons space (http://db.apache.org/commons/). The reasons why we want to move commons-sql, are twofold: * The two active committers (Martin Kalén and myself) are DB comitters, but not comitters to another Jakarta project. As a result we would rather not subscribe to commons-dev/commons-user because very few mails there deal with commons-sql (one or two per month). Also, db-commons already has all setup'd (mailing lists, CVS space etc.), not to mention that the exposure of the project would be much greater. * No other Jakarta project that I'm aware of, uses commons-sql. In contrast, OJB will do so (beginning with the upcoming 1.1 version), and so it would be good to provide access to the commons-sql repository to the OJB comitters. The same might also be true for Torque as commons-sql's functionality overlaps in some parts with Torque functionality, which opens up an opportunity to combine this functionality into a base component which both OJB and Torque could use. Please post your opinion until next wednesday, the 15th of december, and please reply to all recipients. Votes cast so far: +1 Brian McCallister +1 Henri Yandell (though with objections regarding moving it into db-commons, http://db.apache.org/commons) +1 Henning Schmiedehausen regards, Thomas Dudziak PS: I'm not sure if this is the correct procedure, but I thought a vote is at least a good way to get the ball rolling, so to speak. If there is a defined way to handle movement of projects, then please let me know. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Volunteer for SVN migration management? Was: Migrate to SVN?
+/-0 for giving site tags, branches, and trunk. It might be nice to have the site built from site/tags/PRODUCTION so we could have some sort of a release cycle for the site, but (OTOH) it might be nice to keep it simple and just have content under site. Anyone? Tim -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Saturday, November 27, 2004 11:56 AM To: Jakarta Commons Developers List; Martin Cooper Subject: Re: Volunteer for SVN migration management? Was: Migrate to SVN? From a Jakarta level view, I really want to push for: jakarta/subproject/whatever... Other than that, I'll work with anything :) (Which I just noticed Velocity haven't done, so will see if I can get them to change). On Fri, 26 Nov 2004 21:52:22 -0800, Martin Cooper [EMAIL PROTECTED] wrote: On Sat, 27 Nov 2004 00:35:14 -0500, Tim O'Brien [EMAIL PROTECTED] wrote: Martin, I'm available if you need help. Thanks, I appreciate that. One thing to flesh out is structure - here are some proposals: Summarising my preferred versions of your alternatives, we might have: jakarta/ commons/ proper/ ... digester/ branches/ tags/ trunk/ ... site/ branches/ tags/ trunk/ sandbox/ ... bzip2/ branches/ tags/ trunk/ ... This gives each component its own branches and tags, which makes more sense to me than having Commons-wide tagging and branching. As mentioned, it also makes 'site' its own thing, rather than pretending that it's a component. Comments? -- Martin Cooper Commons Proper Components 1. /jakarta/commons/digester/[tags|branches|trunk] 2. /jakarta/commons/proper/digester/[tags|branches|trunk] Commons Sandbox Components (just using bzip2 because it is there) 1. /jakarta/commons-sandbox/bzip2/[tags|branches|trunk] 2. /jakarta/commons/sandbox/bzip2/[tags|branches|trunk] Anybody have other options? I look at the existing velocity project, and part of me just wishes they had combined all velocity related modules under a velocity directory. If everything commons where under a commons directory, then we could have a separate directory for the commons site - something like /jakarta/commons/site. site would then not be a sibling to a real project. Tim 2 cents O'Brien -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 11:11 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: Volunteer for SVN migration management? Was: Migrate to SVN? On Fri, 26 Nov 2004 13:31:27 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Do we have a volunteer to organise the move of Commons to SVN? Sure, I'll step up, unless someone else has a strong desire to do it. (which is probably some combination of: vote, plan, liaise with infra) Yep, I expect I'll be doing all three at once. ;-) -- Martin Cooper Hen On Fri, 26 Nov 2004 10:54:37 -0500, Phil Steitz [EMAIL PROTECTED] wrote: +1 from me as well -- seems to make sense to move as a group. Phil Alex Karasulu wrote: +1 Noel J. Bergman wrote: 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. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel --- -- 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
RE: Migrate to SVN?
If I might add one more, the process of promoting components from sandbox to proper will be easier with svn move or copy. One thing I'd like to see going forward is that a component is moved out of the sandbox upon promotion. I know it is just an empty directory, but digester and codec still appear here: http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/. Also, I don't want to ever see waiting for bayard's lock in /blah/blah (not singling Henri out) I would like to forget ever knowing about cvs lock files. (http://www.network-theory.co.uk/docs/cvsmanual/cvs_88.html) Tim -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 11:05 PM To: Jakarta Commons Developers List Subject: RE: Migrate to SVN? Can you comment on the admin-side advantages of svn ? Elimination of the need for shell accounts, and the ability to shift load from the core infrastructure team to the PMCs. Trivial project movement. And since we sometimes have to ... cough ... help recover from people playing around with ,v files, I would not discount the issue of refactoring not creating any issues for infrastructure. Those are a few off-hand. --- Noel - 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: Volunteer for SVN migration management? Was: Migrate to SVN?
Martin, I'm available if you need help. One thing to flesh out is structure - here are some proposals: Commons Proper Components 1. /jakarta/commons/digester/[tags|branches|trunk] 2. /jakarta/commons/proper/digester/[tags|branches|trunk] Commons Sandbox Components (just using bzip2 because it is there) 1. /jakarta/commons-sandbox/bzip2/[tags|branches|trunk] 2. /jakarta/commons/sandbox/bzip2/[tags|branches|trunk] Anybody have other options? I look at the existing velocity project, and part of me just wishes they had combined all velocity related modules under a velocity directory. If everything commons where under a commons directory, then we could have a separate directory for the commons site - something like /jakarta/commons/site. site would then not be a sibling to a real project. Tim 2 cents O'Brien -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 11:11 PM To: Jakarta Commons Developers List; Henri Yandell Subject: Re: Volunteer for SVN migration management? Was: Migrate to SVN? On Fri, 26 Nov 2004 13:31:27 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Do we have a volunteer to organise the move of Commons to SVN? Sure, I'll step up, unless someone else has a strong desire to do it. (which is probably some combination of: vote, plan, liaise with infra) Yep, I expect I'll be doing all three at once. ;-) -- Martin Cooper Hen On Fri, 26 Nov 2004 10:54:37 -0500, Phil Steitz [EMAIL PROTECTED] wrote: +1 from me as well -- seems to make sense to move as a group. Phil Alex Karasulu wrote: +1 Noel J. Bergman wrote: 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. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel --- -- 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] - 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: [io] Filename prefixes
Stephen, What happens to getExtension() when there is no . character? Also, what is there are multiple ., are you thinking name.substring( name.lastIndexOf( . ) + 1 )? What does getPrefix() return on Unix? Nothing? Tim -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Sunday, November 21, 2004 7:18 PM To: Jakarta Commons Developers List Subject: Re: [io] Filename prefixes Basically it looks like we'll need: getPrefix() - C:\ getPath() - dev\project getFullPath() - C:\dev\project getName() - file.txt getExtension() - txt (input C:\dev\project\file.txt) Normalize/catPath can then use the other methods to stitch together a result. Naming: catPath() should be renamed to concat() getFullPath()/getPath() - are these logical names? Stephen - Original Message - From: Martin Cooper [EMAIL PROTECTED] On Mon, 22 Nov 2004 01:03:28 -, Stephen Colebourne [EMAIL PROTECTED] wrote: In order to write the normalize() method properly, I realised that we have to deal with filename prefixes properly. The point being that you can't .. up into a filename prefix. Here's the javadoc for the method I'm writing. Does this cover the cases? Looks good to me. I can't think of any other options, at least for Windows and Unix. -- Martin Cooper /** * Returns the length of the filename prefix, such as codeC://code or code~//code. * p * This method will handle a file in either Unix or Windows format. * The prefix includes the first slash in the full filename. * pre * Windows: * a\b\c.txt -- -- relative * \a\b\c.txt -- \ -- drive relative * C:\a\b\c.txt-- C:\ -- absolute * \\server\a\b\c.txt -- \\server\ -- UNC * * Unix: * a/b/c.txt -- -- relative * /a/b/c.txt -- / -- absolute * ~/a/b/c.txt -- ~/-- current user relative * ~user/a/b/c.txt -- ~user/-- named user relative * /pre * * @param filename the filename to find the prefix in, null returns -1 * @return the length of the prefix, -1 if invalid or null */ Stephen - 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: Moving from Bugzilla to JIRA
Henri, When commons moves to Jira, I would also recommend a project per component strategy. commons-digester, commons-betwixt, etc. This would make release management much easier. Tim O'Brien From: Serge Knystautas Sent: Fri 9/3/2004 12:57 PM To: Jakarta Commons Developers List Subject: Re: Moving from Bugzilla to JIRA Henri Yandell wrote: The following is an example of a Commons like project in Jira. I encourage anyone who's not used Jira to go have a look at this link and get a feel for how easy it is to use, compared to the mess that is our bugzilla installation. http://issues.osjava.org:8080/jira/secure/BrowseProject.jspa?id=10010 As I have modelled each Commons-like component as a Component in Jira, it's hard to know how many there actually are. You also can't have separate versions for different components. Henri, We would not map Jakarta Commons this way. Every JIRA project is a piece of code that is releasable, because as you suggest, a project has its own versions, components, changelog, and roadmap. Look at some of the Avalon/Merlin breakdowns to see how they each have their own JIRA project to get a feel for how this works. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] [vote] Release 1.0-RC1
Out of nowhere, Tim votes... - [X] +1 Go ahead and release 1.0-RC1 [ ] +0 [ ] -0 [ ] -1 Don't release 1.0-RC1, because... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] [codec] Release 1.3-RC1
- [X] +1 Go ahead and release 1.3-RC1 [ ] +0 [ ] -0 [ ] -1 Don't release 1.3-RC1, 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: [configuration] DOM vs DOM4J
I think a good solution is to do what Log4J has done with there distribution. Include a number of contrib classes in the distribution. I agree with the sentiment to get rid of Dom4JConfiguration, as I think it would make it easier to address some larger issues with the API - like why does this thing only load resources from the system classloader? From: Maarten Coene [mailto:[EMAIL PROTECTED] Sent: Wed 6/23/2004 5:30 AM To: Jakarta Commons Developers List Subject: Re: [configuration] DOM vs DOM4J And what about donating the code to the dom4j project if you decide to remove it? Maarten Eric Pugh wrote: It'll be in CVS if we come up with a reason to reimplement it... Eric -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 9:19 AM To: Jakarta Commons Developers List Subject: RE: [configuration] DOM vs DOM4J Emmanuel Bourg wrote on Tuesday, June 22, 2004 5:06 PM: Jörg Schaible wrote: Taking Paul's comment into account, there seems not to be a real sufficient solution. DOCConfiguration is quite nice for JDK = 1.4, since no additional dependency is generated. Therefore I vote in first place for the DOMConfiguration, but it might be good to have DOM4JConfiguration in e.g. commons-configuration-optional around and the possibility to tell the core to use this implementation. Comments? DOMConfiguration is even nice for JDK 1.3 since most server environnements under this version provide the standard XML APIs. I don't think [configuration] is performance critical enough to justify the use of an additional dependency, and there are other possible optimizations if a better implementation is really needed (for example the properties could be stored only once in the BaseConfiguration and the DOM parser could be dropped for a SAX parser). I tend to prefer a complete removal of the DOM4J classes to cut down the maintenance burden. Fine with me. -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] Committer rights for Brett Porter
+0, never worked with Brett so it would feel right +1'ing, but offering a +0 if it helps. Tim -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Sunday, June 13, 2004 12:41 PM To: Jakarta Commons Developers List Subject: RE: [VOTE] Committer rights for Brett Porter +1 --- Noel - 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] PropertiesConfiguration vs. DOM.*Configuration
DOM4JConfiguration and DOMConfiguration each have two constructors which take a parameter. One takes a File and the other takes a resource name as a String. PropertiesConfiguration has one constructor which takes a parameter, and it is a String representing a file name. Anyone have any objections to bringing PropertiesConfiguration into sync with the two XMLConfiguration implementations? In other words, PropertiesConfiguration should have a constructor which takes a File and a constructor which takes a String resource name. Alternatively, why not have all Configuration implementations just take a Reader? Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/jexl/xdocs navigation.xml
Good catch, I just fixed it. -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 09, 2004 12:54 AM To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta-commons/jexl/xdocs navigation.xml On 9 Jun 2004 03:29:17 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: tobrien 2004/06/08 20:29:17 Modified:jexl/xdocs navigation.xml Log: Modifed the Maven navigation to be in line with http://wiki.apache.org/jakarta-commons/CreatingStandardWebPresence. The menu now contains a reference to top-menus and bottom-menus. Revision ChangesPath 1.3 +30 -25jakarta-commons/jexl/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons/jexl/xdocs/navigation.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- navigation.xml4 Jun 2004 22:31:17 - 1.2 +++ navigation.xml9 Jun 2004 03:29:17 - 1.3 @@ -1,30 +1,35 @@ ?xml version=1.0 encoding=ISO-8859-1? + !-- - Copyright 2002,2004 The Apache Software Foundation. - - Licensed under the Apache License, Version 2.0 (the License); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - + Copyright 2003-2004 The Apache Software Foundation Did you really mean to remove 2002 as a year for the copyright? - 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] [collections] Release 3.1 RC1
- [ X ] +1 Go ahead and release 3.1-RC1 [ ] +0 [ ] -0 [ ] -1 Don't release 3.1-RC1, because... - Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][digester] approve 1.6.0 release plan
+1 on the release plan in Wiki Tim -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 09, 2004 4:55 PM To: Jakarta Commons Developers List Subject: [VOTE][digester] approve 1.6.0 release plan this is a vote to approve the 1.6.0 release plan (http://wiki.apache.org/jakarta-commons/ Digester_2f1_2e6_2e0ReleasePlan) and myself as release manager for this release. i'll give this one 24 hours to run (before creating the tag). here's my +1 - 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]
[jexl] A plan for a 1.0 release
Is there anyone out there with a release plan for JEXL 1.0? If not, is there any object to the development of one? Tim O'Brien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [id] util package
-Original Message- From: Rob Oxspring [mailto:[EMAIL PROTECTED] Personally, I'd favour a single jar with an optional dependancy but its just another option in the cut'n'paste vs deep depencanies compromise - pleasing everyone is always going to be a struggle. Copying that many classes from [codec] to avoid a Runtime dependency doesn't seem worth the effort. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] Instead of source and binary - one distribution
We make releases both source and binary, but why not just start cutting one release? I can understand why a product like HTTPD would be distributed without source, but the commons community consists of developers. Can anyone think of any good reason to preserve the current release structure. My apologizes in advance if this starts an endless flame war. I have a knack for that. - Tim O'Brien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] Instead of source and binary - one distribution
-Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, June 04, 2004 4:45 PM To: Jakarta Commons Developers List Subject: RE: [all] Instead of source and binary - one distribution -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Friday, June 04, 2004 2:34 PM To: Jakarta Commons Developers List Subject: Re: [all] Instead of source and binary - one distribution --- Tim O'Brien [EMAIL PROTECTED] wrote: We make releases both source and binary, but why not just start cutting one release? I can understand why a product like HTTPD would be distributed without source, but the commons community consists of developers. Can anyone think of any good reason to preserve the current release structure. Even though we distribute to developers, most of them probably don't care about the source. They care about adding the jar to their project and looking at the javadocs. I just downloaded codec for use in one of my projects and would have immmediately thrown away the source if it was included. IMO, it's a waste of Apache's bandwidth to distribute files users are just going to delete. +1. I am firmly against throwing everything into a single distribution. I thought we just had this discussion a few weeks ago, anyway... Alright, issue is put to bed, sorry for the duplication. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang Validate.java
-Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 01, 2004 5:24 PM To: Jakarta Commons Developers List Subject: Re: [lang] Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang Validate.java I'm confused -- why shouldn't a class in [lang] have dependencies to other classes in [lang]? Isn't this taking things too far?? Its part of [lang] being broad and shallow. In effect, [lang] is a loose grouping of APIs in a similar vein. As such it should be easily broken into many parts. ie. a user should be able to come along and take one class (wherever possible) and paste it into their own CVS/project. Think of it as a single class jar file. [lang] just provides a home for it without needing the additional jar packaging. Stephen I can't say I agree with this POV, but I do think that it needs a more formal fleshing out than a Re: thread for a CVS commit. I can see the benefit of reducing dependencies among different projects, but I don't see a good rationale for not having Validate use StringUtils and/or ArrayUtils. I'm not of the opinion that we should increase the effort of maintaining common components because there are people who cut/paste code into separate projects. Respectfully, Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] ComplexFormat changes
I'm sorry for the delayed response (I'm on the road this week), I looked at the patch and I agree with your implementation. +1 I had looked at this but had thrown my hands in the air in resignaion, thanks for stepping up to the plate. - Tim O'Brien [EMAIL PROTECTED] (847) 863-7045 On Thu, 27 May 2004 [EMAIL PROTECTED] wrote: Has anyone read my latest comment regarding the ComplexFormat issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=29000? I never saw a message come across the mailing list. Anyway, I was waiting for some feedback before I proceeded. Brent Worden http://www.brent.worden.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: [lang] StopWatch stop vs. split?
State management would be valuable: I made it a Bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=29163 Tim -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, May 23, 2004 3:45 PM To: Jakarta Commons Developers List Subject: Re: [lang] StopWatch stop vs. split? Yep. They're meant to mimic the stopwatch I had as a kid :) Split would set the time, but let the stopwatch carry on working wheras stop would set the time and stop the watch continuing. The implementation ended up being the same. The only thing I can think of is to throw Exceptions if people try to call split or stop again. Hen On Wed, 19 May 2004, matthew.hawthorne wrote: Gary Gregory wrote: The StopWatch method stop and split do the same thing. Why have both? It's confusing. After taking a look at the javadocs, I don't think that they're supposed to do the same thing, they've just been coded that way. It seems that stop() is supposed to reset the start time, and split() isn't. Maybe adding a startTime = -1 to the stop() method would fix this? - 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/math/src/test/org/apache/commons/math/stat/univariate ListUnivariateImpl.java
Agreed, ( but ListUnivariateImpl is somewhat of a throw-away test fixture ). In general, I agree that tests should not swallow exceptions. I've just commit'd a change in the same vein. -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Saturday, May 22, 2004 8:41 PM To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta- commons/math/src/test/org/apache/commons/math/stat/univariate ListUnivariateImpl.java We should also fix the swallowing behavior -- i.e., a test case should never swallow an exception and just dump a stack trace. If the test case throws an unexpected exception, the test should fail. I have been fixing these by changing the test method signature to throws Exception. This also eliminates the need to import MathException everywhere. - 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/math/src/test/org/apache/commons/math/stat/univariate ListUnivariateImpl.java
Apologies for the nasty auto-generated CVS comments. Ick. Upgraded to a
new machine, and forgot to tweak Eclipse. It may be time to return to
Emacs
Tim
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 22, 2004 7:34 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-
commons/math/src/test/org/apache/commons/math/stat/univariate
ListUnivariateImpl.java
tobrien 2004/05/22 17:33:41
Modified:math/src/test/org/apache/commons/math/distribution
GammaDistributionTest.java
ExponentialDistributionTest.java
FDistributionTest.java
math/src/test/org/apache/commons/math/util
BeanTransformerTest.java
DefaultTransformerTest.java
math/src/test/org/apache/commons/math/stat/univariate
ListUnivariateImpl.java
Log:
Got rid of a number of those pesky Auto-generated catch block comments
from test code.
PR:
Obtained from:
Submitted by:
Reviewed by:
CVS: ---
---
CVS: PR:
CVS: If this change addresses a PR in the problem report tracking
CVS: database, then enter the PR number(s) here.
CVS: Obtained from:
CVS: If this change has been taken from another system, such as NCSA,
CVS: then name the system in this line, otherwise delete it.
CVS: Submitted by:
CVS: If this code has been contributed to Apache by someone else;
i.e.,
CVS: they sent us a patch or a new module, then include their
name/email
CVS: address here. If this is your work then delete this line.
CVS: Reviewed by:
CVS: If we are doing pre-commit code reviews and someone else has
CVS: reviewed your changes, include their name(s) here.
CVS: If you have not had it reviewed then delete this line.
Revision ChangesPath
1.15 +1 -3 jakarta-
commons/math/src/test/org/apache/commons/math/distribution/GammaDistributi
onTest.java
Index: GammaDistributionTest.java
===
RCS file: /home/cvs/jakarta-
commons/math/src/test/org/apache/commons/math/distribution/GammaDistributi
onTest.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- GammaDistributionTest.java 21 Feb 2004 21:35:17 - 1.14
+++ GammaDistributionTest.java 23 May 2004 00:33:40 - 1.15
@@ -52,7 +52,6 @@
.cumulativeProbability(x);
assertEquals(probability for + x, expected, actual, 10e-
4);
} catch (MathException e) {
-// TODO Auto-generated catch block
e.printStackTrace();
}
}
@@ -66,7 +65,6 @@
.inverseCumulativeProbability(p);
assertEquals(critical value for + p, expected, actual,
10e-4);
} catch (MathException e) {
-// TODO Auto-generated catch block
e.printStackTrace();
}
}
1.13 +1 -4 jakarta-
commons/math/src/test/org/apache/commons/math/distribution/ExponentialDist
ributionTest.java
Index: ExponentialDistributionTest.java
===
RCS file: /home/cvs/jakarta-
commons/math/src/test/org/apache/commons/math/distribution/ExponentialDist
ributionTest.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ExponentialDistributionTest.java21 Feb 2004 21:35:17 -
1.12
+++ ExponentialDistributionTest.java23 May 2004 00:33:40 -
1.13
@@ -161,7 +161,6 @@
double actual = exp.cumulativeProbability(0.25, 0.75);
assertEquals(0.0905214, actual, 10e-4);
} catch (MathException e) {
-// TODO Auto-generated catch block
e.printStackTrace();
}
@@ -172,7 +171,6 @@
double actual = exp.cumulativeProbability(x);
TestUtils.assertEquals(expected, actual, 10e-4);
} catch (MathException e) {
-// TODO Auto-generated catch block
e.printStackTrace();
}
}
@@ -182,7 +180,6 @@
double actual = exp.inverseCumulativeProbability(p);
TestUtils.assertEquals(expected, actual, 10e-4);
} catch (MathException e) {
-// TODO Auto-generated catch block
e.printStackTrace();
}
}
1.12 +1 -3 jakarta-
commons/math/src/test/org/apache/commons/math/distribution/FDistributionTe
st.java
Index: FDistributionTest.java
===
RCS file:
RE: [math] Dependencies WAS: Design review pre 1.0
Phil Wrote commons-beanutils doesn't seem to be used, so shouldn't be in project xml BeanUils is used in the BeanList stuff that I recently rectified but have not moved back into src from test. I guess I am in favor of relegating this to experimental and dropping the dependency for 1.0. [Tim O'Brien] Yes, 100% go for it. I wonder if we can release a supplemental (separate) deliverable that would provide some less important utilities that needed these dependencies. In other words, a core math library with zero or one dependency, and a supplemental that adds capabilities that depend on other commons libraries. Confusing or interesting: What do you think? Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bug report for Commons [2004/05/16]
Does anyone read this Bug Report? Just wondering, if people don't find utility from this big list of Commons, bug I propose we just tell Bugzilla to stop sending it to commons-dev. Tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, May 16, 2004 9:17 AM To: [EMAIL PROTECTED] Subject: Bug report for Commons [2004/05/16] +- --+ | Bugzilla Bug ID | | +--- --+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned | | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +--- --+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +--- --+ | | | | Date Posted | | | | | + --+ | | | | | Description | | | | | | | | 6508|Ass|Enh|2002-02-17|HttpClient now supports proxyHost and proxyPort - | | 6826|Ass|Enh|2002-03-04|Need to have xml files validated against DTDs as p| | 6829|Ass|Enh|2002-03-04|Allow easier way of user specified tests | | 7069|Ass|Enh|2002-03-13|DTD and DOM Validators | | 7135|Opn|Enh|2002-03-14|[beanutils] Misleading error message when beaninfo| | 7226|Opn|Enh|2002-03-19|Nested Bean Collection | | 7367|New|Nor|2002-03-22|[unspecified] ServiceManager not actually serializ| | 7465|New|Nor|2002-03-25|Need better 'dist' build | | 7981|Ver|Nor|2002-04-11|[codec][PATCH] add 2 new methods for encoding stri| | 8140|Ver|Nor|2002-04-16|Incorrect credentials loop infinitely | |10319|New|Enh|2002-06-28|Instantiate property if null in form bean | |10543|Ass|Enh|2002-07-08|generate ant task automatically from CLI | |10793|New|Enh|2002-07-15|User definable default headers support | |10810|New|Enh|2002-07-15|Response handlers | |10813|New|Enh|2002-07-15|RFC 2965 Support (Port sensitive cookies) | |10815|New|Enh|2002-07-15|Instrumentation for Timings | |10957|New|Nor|2002-07-18|Change Header/HeaderElement to handle a list as th| |12807|New|Nor|2002-09-19|[PATCH] x 2 Update build.xml to use commons- loggin| |13031|New|Enh|2002-09-26|Use regular expression (regex) pattern matching fo| |13390|New|Nor|2002-10-07|ResponseHeaderHandler and ResponseHeaderValidator | |13426|New|Enh|2002-10-08|[PATCH] xml-reference.xml responseHeader addition | |13743|Opn|Enh|2002-10-17|Need getPropertyType(Class theClass, String propNa| |14036|New|Enh|2002-10-29|MultipartPostMethod does not check for error messa| |14262|Opn|Maj|2002-11-05|SAXBeanWriter produces invalid XML | |14394|Ver|Nor|2002-11-08|Excessive exceptions log under security manager | |14471|Opn|Enh|2002-11-12|validator-rules.xml JavaScript fails when field no| |14667|Ver|Maj|2002-11-19|PropertyUtils.copyProperties does not copy to Dyna| |15082|Ass|Enh|2002-12-04|[lang] elapsed time formatting utility method | |15451|Opn|Enh|2002-12-17|Multiple mapped properties not possible / Direct m| |15519|Ver|Maj|2002-12-19|PropertyUtils.getPropertyType() for java.util.Coll| |15534|New|Nor|2002-12-19|Inadequate HTTP proxy server support in HttpClient| |15744|New|Nor|2002-12-31|[unspecified] Scaffold ResultSet used after statem| |15895|Unc|Nor|2003-01-08|In BeanMap all properties are writable (some with | |16038|Opn|Enh|2003-01-13|[beanutils] LocaleBeanUtils.copyProperties() does | |16132|New|Maj|2003-01-15|[Jelly] core:file convert html to lt;htmlgt; | |16394|New|Enh|2003-01-24|Enhance the IndexedListProperty to handle nested l| |16525|Opn|Enh|2003-01-29|BeanUtils.setProperty is over-zealous at convertin| |16600|New|Nor|2003-01-30|JUnitTestAdapter throws SAXException because no DT| |16859|New|Nor|2003-02-06|[unspecified] Can't supply a javax.mail.Session to| |16873|New|Enh|2003-02-07|Specifying a different latka.properties file | |16907|New|Enh|2003-02-08|Introduce Aspect oriented programming | |16920|Opn|Enh|2003-02-10|Declaration of Locale (language/country) in valida| |17002|Opn|Enh|2003-02-12|Problem with index property | |17102|New|Enh|2003-02-15|Can't embed characters in paramValue data. | |17306|Opn|Enh|2003-02-22|extend field tag with forward attribute for er| |17416|New|Enh|2003-02-26|Send InputStreams instead of files in MultipartPos| |17501|New|Enh|2003-02-27|Add dynamic discovery of mapped properties to Prop| |17619|New|Nor|2003-03-03|[jelly] ClassLoader Problems with XMLParser and XM| |17650|New|Nor|2003-03-04|[unspecified] Make Messages pay attention to retur| |17662|New|Nor|2003-03-05|unknown options are ignored instead of throwing Un| |17682|New|Nor|2003-03-05|HelpFormatter does not wrap lines
[math] project wide approach to toString() methods
toString() methods are possibly the most trivial thing in the world, but, for consistency, it might make sense to embrace the Commons Lang ToStringBuilder everywhere we need to implement toString(). *I'm not advocating the use of the reflection builder*, but we have a number of places where a toString() method is implemented by creating a StringBuffer or just concatenating strings ourselves. Another topic is how some of the classes have a toString() method which contains considerable logic, like how to print a Matrix or a Frequency. I think it would be a better decision to create Printer objects which allow you to configure how something is output. This is similar to the way that Map doesn't hold any formatting information, instead we have debugPrint() and verbosePrint() on MapUtils. (But, I don't advocate an explosion of XXXUtils objects in Commons Math) Note that this does not apply to o/a/c/m/function/simple package. That would just be silliness as the toString() is simply returning one string. (Although someone is free to suggest that we externalize all strings in the system for internationalization, I think this is a good idea generally for J-C.) Here's a list of issues: 0. SummaryStatisticsImpl - this one would be simple to use ToStringBuilder with. (If we've got Commons Lang, let us take advantage of it... ) 1. AbstractDescriptiveStatistics - this one would be simple to use ToStringBuilder with. 2. Frequency - This one is tricky, and I'm wondering if this is really an appropriate use of toString(). Frequency's toString() prints out a tab delimited table which lists the frequency of each element. I think something like this may make more sense as a FrequencyFormat object. Anyone? 3. RealMatrixImpl - Again, I think we should have a MatrixFormat that takes care of printing a matrix. Or a MatrixPrinter, I'm definitely not stuck on the idea of extending java.text.Format. Just for added emphasis, if someone decides to do any of this this, don't use a reflection builder, that wouldn't work for clients with restrictive security policies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Design review pre 1.0
-Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 6) ComplexFormat doesn't extend the JDK Format class [Tim O'Brien] Good catch, this makes sense, and it is now has the milestone of being the 29,000th Bugzilla issue. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Design review pre 1.0
-Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 3) Javadocs are sometimes thin. On occasions, they are written as paragraphs visually but without the HTML p tag. (eg. UnivariateRealSolver) or missing, eg StandardDeviation [Tim O'Brien] Agree, JavaDocs are somewhat thin and in some cases we just reference some other web site. (i.e. ComplexMath simply has a URL: http://myweb.lmu.edu/dmsmith/ZMLIB.pdf ). A good benchmark to use is Digester, our users should be able to use a commons component without needing to look at the source, and having fuller JavaDoc goes a long way towards this goal. So, be warned, I'm using Bugzilla as a task list. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] 1.3 Release Candidate Status
Yes, quiet is an understatement. :-) I never addressed the improved testing of DoubleMetaphone, but I think that we at least have better coverage than we did a few weeks ago. Tim -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Friday, May 07, 2004 1:37 PM To: Jakarta Commons Developers List Subject: RE: [codec] 1.3 Release Candidate Status Unless I hear some noise (better Clover or otherwise), I would like to propose to cut a 1.3 RC1. Things have been quiet and stable. Thank you, Gary -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 11:41 To: Jakarta Commons Developers List Subject: RE: [codec] 1.3 Release Candidate Status Are there any volunteers to improve Clover unit test coverage for the 1.3 release? What we have today is pretty good but some classes could be better covered. Thank you, Gary -Original Message- From: Tim O'Brien [mailto:[EMAIL PROTECTED] Sent: Thursday, April 22, 2004 10:58 To: Jakarta Commons Developers List Subject: RE: [codec] 1.3 Release Candidate Status Sounds good, I'd like to take this time to fully test DoubleMetaphone, I'll get to it this weekend. Tim On Thu, 22 Apr 2004, Gary Gregory wrote: Tim and all, I am going to be very busy until next week, so I cannot attend to [codec]. Any polishing anyone wants to do is welcome ;-) Thank you, Gary -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 15:14 To: Jakarta Commons Developers List Subject: RE: [codec] 1.3 Release Candidate Status Gary, let me know if you need any support for the release. I'd like to pass the baton off to you as it isn't a good idea to monopolize release management. Tim, You're not monopolizing anything Tim ;-) AFAIAC, the committer that has the time and the inclination can do it. Right, I've got little bits of time here and there. I'd like to cut a 1.3 while it is stable and before streamable codec work begins. So, unless someone steps up with concerns or decides to increase code coverage, I'd like to get started with an RC1. Thank you, Gary - 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] -- -- Tim O'Brien Evanston, IL (847) 863-7045 [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: [codec] 1.3 Release Candidate Status
Sounds good, I'd like to take this time to fully test DoubleMetaphone, I'll get to it this weekend. Tim On Thu, 22 Apr 2004, Gary Gregory wrote: Tim and all, I am going to be very busy until next week, so I cannot attend to [codec]. Any polishing anyone wants to do is welcome ;-) Thank you, Gary -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 15:14 To: Jakarta Commons Developers List Subject: RE: [codec] 1.3 Release Candidate Status Gary, let me know if you need any support for the release. I'd like to pass the baton off to you as it isn't a good idea to monopolize release management. Tim, You're not monopolizing anything Tim ;-) AFAIAC, the committer that has the time and the inclination can do it. Right, I've got little bits of time here and there. I'd like to cut a 1.3 while it is stable and before streamable codec work begins. So, unless someone steps up with concerns or decides to increase code coverage, I'd like to get started with an RC1. Thank you, Gary - 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] -- -- Tim O'Brien Evanston, IL (847) 863-7045 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] 1.3 Release Candidate Status
Gary, I'm expanding coverage right now. Testing Metaphone is neither easy
nor fun. We'll also need to increase coverage in DoubleMetaphone.
I uncovered a potential bug in Metaphone. The code in question deals with
the encoding of 'B':
// START CODE from Metaphone
case 'B' :
if ((n 0) !(n + 1 == wdsz)
(local.charAt(n - 1) == 'M')) { // not MB at end of word
code.append(symb);
} else {
code.append(symb);
}
mtsz++;
break;
// END CODE
My understanding is that we should not encode a 'B' if a word ends in MB.
(Following: http://aspell.sourceforge.net/metaphone/metaphone-kuhn.txt)So
the Metaphone of COMB is KM not TMB, and the Metaphone of TOMB is
TM not TMB. I refactored this code a bit and came up with the
following:
case 'B' :
if ( isPreviousChar(local, n, 'M')
isLastChar(wdsz, n) ) {
// B is silent if word ends in MB
break;
} else {
code.append(symb);
}
break;
Also, this code was (outright) copied from a C++ program, there was no need
to keep track of the length of our StringBuffer in a variable named mtsz.
That's gone, and the only reason this was possible was great code coverage.
Tim
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 18, 2004 1:24 PM
To: Jakarta Commons Developers List
Subject: RE: [codec] 1.3 Release Candidate Status
Ah, yes, thanks for catching it. I've fixed this in CVS HEAD. See
Bugzilla Bug 28455: Hex converts illegal characters to 255.
Thank you,
Gary
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 18, 2004 10:40
To: Jakarta Commons Developers List
Subject: Re: [codec] 1.3 Release Candidate Status
Gary
Has the problem reported by Tom van den Berge been looked into?
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=108201900324974w=
2
If not, I believe it should be
Oleg
On Sun, 2004-04-18 at 19:33, Gary Gregory wrote:
Hello all,
It seems to me that we should start the release process for Codec
1.3.
Does the following need polish?
- Better unit test code coverage (Clover). Some classes are 100%,
others
not (volunteers?). New classes are 100% I believe.
- Check that the release notes file is up to date WRT fixes and new
features.
Depending on feedback from the list, we could build an RC1.
Thank you,
Gary
-
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: [all] Shared build causes issues in releases
Stephen, what about just bundling the generated ant build.xml writing a good README which explains the situation. Tim On Tue, 6 Apr 2004, Henri Yandell wrote: Write a custom jakarta-commons-plugin which has a release goal which incorporates including the commons-build directory would be one option. Would love to do it, but heavily overcommitted to things atm :( The personal wossnames I mentioned in private email a few weeks back was the news that my wife is pregnant :) Congrats Henri. Hen On Tue, 6 Apr 2004, [iso-8859-1] Stephen Colebourne wrote: Our maven scripts now depend on commons-build, however this is of course not included in the release zips. This is a problem and means that maven cannot be used in releases. Anyone got any ideas on how to solve this? I don't like the idea of hacking project xml for each release. Stephen - 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] -- -- Tim O'Brien Evanston, IL (847) 863-7045 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote][all] migrate top level commons site to mavenized version.
On Wed, 31 Mar 2004, Mark R. Diggory wrote: [x] +1 yes, and I'll help [ ] +0 yes, go for it, but I'll just watch. [ ] -1 no way, you've got more work before you can do this. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] Requesting permission to work in commons sandbox
+1 from me. Although, I'd be just as happy if you worked in an EXPERIMENT branch in codec proper. In other words, I see the sandbox as a place for new projects. I know that CLI recently used the sandbox to develop a new version, but that, to me at least, is a confusing use of the sandbox. Anyone else care to chime in? Tim Alex Karasulu wrote: Hello, I would like to request karma to the sandbox to present and document these stateful decoder/encoder interfaces along with some proof of concept work. I'm already an Avalon committer and work on the directory project. I could just keep this stuff in the directory project's jira but don't feel I'm doing it justice there :-). I have already implemented several decoders in the incubator's directory project in the past few days using these interfaces. What I have to date looks good - such decoders chain well together using callbacks. There is flexibility and a single callback could technically handle an entire chain. These findings I would like to document. However others like Brett and Noel still have opinions but I think we're close to an agreement. Perhaps through examples and use cases presented in the commons-sandbox we can reach some sort of consensus and move the code to codec proper. Alex - 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]
[beanutils] A BeanPredicate which wraps another Predicate
BeanUtils has a BeanPropertyValueEqualsPredicate, this Predicate uses PropertyUtils to get a bean property and then checks to see if the bean property equals a certain value. This is great if your application needs to test a bean property for equality, but it limits what can be done with the various Predicates now available in collections 3.0. I've added a BeanPredicate which allows you to decorate a Predicate to act upon a bean property. This class is in the spirit of BeanComparator. BeanPropertyValueEqualsPredicate predicate = new BeanPropertyValueEqualsPredicate( activeEmployee, Boolean.FALSE ); Now becomes, BeanPredicate predicate = new BeanPredicate( activeEmployee, new EqualPredicate( Boolean.FALSE ) ); And it also allow for other predicates. To check for a null bean property: BeanPredicate predicate = new BeanPredicate( name, NullPredicate.INSTANCE ); Or to test the type of a bean property: BeanPredicate predicate = new BeanPredicate( name, new InstanceofPredicate(String.class) ); ... and so on and so forth ... Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Book time - Pro Jakarta Commons
I hear Robert's concerns loud and clear. I think that too often people expect the ASF to be the community around a particular codebase - nothing discourages or encourages anyone from creating a site that lists relevant books, articles, and documentation. We should not only follow the lead of Struts, but the lead of the HTTPD group. There are scores of books about the Apache web server, both by individuals involved with the community and by others - I don't believe you will find a page that mentions any of these books on ASF sites. I think it is a good policy to keep ASF neutral when it comes to companies, publishers, books, articles, etc. If it doesn't specifically to the code - put it somewhere else. Tim robert burrell donkin wrote: i think that links to books and articles on jakarta products are (in general) a good thing. documentation is the weakness of most jakarta products. it's much easier to persuade a coder to submit a patch adding a feature than a technical author to submit good documentation. both books and articles serve a useful purpose in allow us to concentrate on coding. i've heard the argument that people can find this information using google but it may be buried so deep in the search results as to be effectively invisible. providing links to resources serves a useful purpose by increasing the chance that the existing information will be found (whether directly or indirectly through a search engine). as it becomes larger and more diverse, the ASF will necessarily need more central control over policy. it will also become more and more difficult to establish consensus on any issue. (take, for example, the fate of the jakarta newsletter when it was promoted to apache-wide status.) innovation will have to happen more and more offshore at arms length. (contrast, for example, codehaus and planetapache with jakarta.) sooner or later, the ASF will probably need to create a policy related to endorsements but AFAIK they have not felt the need to do so yet and are happy to allow the community to police itself. i agree that a disclaimer would be useful to make it clear that these are not official endorsements. but my main concern over tacit endorsements is that they have been the cause of personal conflicts which have been damaging to ASF development communities. IMHO disclaimers are not sufficient in this case. maybe we should think hard about the struts solution (an offshore but linked community resources page). - robert On 6 Mar 2004, at 23:13, Gary Gregory wrote: Perhaps the non-endorsement sentiment could also be enforced by name of the section such links would appear under. Instead of a title like Resources, maybe Elsewhere or External Resources or ... Gary -Original Message- From: Michael Davey [mailto:[EMAIL PROTECTED] Sent: Saturday, March 06, 2004 14:37 To: Jakarta Commons Developers List Subject: Re: [general] Book time - Pro Jakarta Commons robert burrell donkin wrote: [snip] i think that links to new books and articles on jakarta is useful but tacit endorsements of particular products is a little bit of a sensitive subject. How about a simple disclaimer. Something like: The following links are provided as a community resource. The information provided does not necessarily reflect the views of the community or any individual. While The Apache Software Foundation may officially endorse or promote some of the information linked to from this page, a link from this page, in itself, should not be cosidered official endorsement or promotion. To add a link, please email [EMAIL PROTECTED] -- Michael - 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: [codec] StatefulDecoders
Good, more consensus from a user - I will commit if no one beats me to it. Ryan Hoegg wrote: As a user of codec, I would like to post a non-binding +1 for the interfaces in Alex's JIRA issue. They are simple and provide a clean, intuitive asynchronous interfaces for client usage. I'd also like to request the analogous interfaces on the Encoder side. Is codec going to continue to maintain String??coder and Binary??coder interfaces? If so, please implement these as subinterfaces of Stateful??coder. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ Alex Karasulu wrote: Brett, Noel, How about we put our minds together and finalize some of this stuff so I can start writing some codecs that can be added back to this project? - 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] policy question (was Re: [VFS][PATCH] make it compile)
On Tue, 2 Mar 2004, Henri Yandell wrote: I don't bother to add to the status file as I consider this kind of thing to be Commons development and not VFS specific stuff. It's a bit rude of me, but no one has complained at me yet for barging into their project to fix some typo or move docs around. I don't consider that rude at all - I consider that right. Too much turf in the Commons - I think this is the main reason why projects stagnate. People assume that somebody else is taking care of project X - I've found that they usually are not. If there is a project with shotty documentation or typos, the expectation should be that it can be fixed by *anyone* with commit rights. Broken windows should be fixed by whomever has the itch and the karma, if another committer doesn't like a change then -1 it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build][all] Mavenized top level site generation example.
Mark R. Diggory wrote: http://jakarta.apache.org/commons-mavenized Please feel free to point out any problems. -Mark +1, that looks great. I think that this page: http://jakarta.apache.org/commons-mavenized/sandbox.html, needs some updating. I'll get on it, and commit a newer version in about an hour. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-build][all] Mavenized top level site generation example.
Martin Cooper wrote: What Hen said. ;-) In addition, if we're really not going to have the sandbox components in the navigation bar, then the sandbox page needs to reference, and link to, all of them. (At least, I can't find any other way to get to sandbox components than though this page.) I checked in a version of sandbox.xml that starts to address this issue. I think we need to create an informative sandbox page, instead of linking from the left nav. I took the categorization of sandbox sites straight off of Henri's state of the sandbox entry. We will need inidividual component champions to supply a description. Tim -- Martin Cooper On Sun, 29 Feb 2004, Henri Yandell wrote: [These are not all for attention right now] For one, the 'Sandbox' link on the front page [rather than nav] does not link to it, but instead jumps down to a small blurb. One thing that Maven does, that I can't understand, is seem to make the lines under the links go on for a space extra. It's not in the source, but the css somehow makes this happen in both IE and Mozilla. Very ugly. How do we change the projects to have the same LHS nav bar? ie) if I click on IO, the nav bar changes, and not just the top chunk. Can we differentiate the top block of the nav bar. It's the only part that should not be global, and yet it looks the same. Perhaps a different background, or a more emphasized line between Jakarta Commons and Download. What is 'Doc for 1.0' on the Commons site? Will we version the site, or is this an accident? The copyright at the bottom is lacking a start date. Should the 'Components' page contain Sandbox items if a Sandbox page exists? Need to update the Pre-Release here to include the ones I mailed out. Volunteering page looks very bad. License page is 1.1. The 'Releases' link should be renamed. Sounds too much like Download. How to Release perhaps. Also it might want to be a tree menu for the 4 links inside it. Unsure. Otherwise, I like a lot :) Hen On Sun, 29 Feb 2004, Tim O'Brien wrote: Mark R. Diggory wrote: http://jakarta.apache.org/commons-mavenized Please feel free to point out any problems. -Mark +1, that looks great. I think that this page: http://jakarta.apache.org/commons-mavenized/sandbox.html, needs some updating. I'll get on it, and commit a newer version in about an hour. Tim - 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: [commons-build][all] Mavenized top level site generation example.
Henri Yandell wrote: [These are not all for attention right now] For one, the 'Sandbox' link on the front page [rather than nav] does not link to it, but instead jumps down to a small blurb. Addressed, I checked in an updated sandbox.xml which I cannabalized from your state of the sandbox entry. I left off descriptions, we'll let inidividual more familiar with each component commit changes to sandbox.xml in commons-build. What is 'Doc for 1.0' on the Commons site? Will we version the site, or is this an accident? Changed the project.properties to remove this. Volunteering page looks very bad. Many of these pages look very bad. I think switching the site over will encourage / lower-the-barrier to improving the content of this behemoth. The whole commons site has a large number of wording, perspective, and spelling problems. We should create a page called broken windows, and check off the items as they are fixed. Ignore-thisOr maybe we should track commons-wide issues in a Jira project - or maybe I want to start a long drawn out fight to no end which will involve 400 email messages. :-) /Ignore-this - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpClient] Moving to Jakarta
Another uninvolved +1 for this move. Tim [EMAIL PROTECTED] wrote: Martin Cooper [EMAIL PROTECTED] wrote on 29/02/2004 06:51:01 AM: On Sat, 21 Feb 2004, Michael Becke wrote: Below is a message I recently posted to commons-httpclient-dev. The input of other commons developers would be greatly appreciated. I look forward to hearing from you. There seems to be a deafening silence on this subject, but just for the record, and in case it's not obvious from the message below, I am +1 on this. I'm +1 on it too. -- dIon Gillard, Multitask Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] more granular artifacts
On Tue, 24 Feb 2004, Ryan Hoegg wrote: In order to promote the reuse of commons-codec instead of the source-code-copy reuse strategy, I propose modifying the codec build to create certain additional artifacts that might be more palatable to developers in this situation. Ryan, this is a great idea - to create separate artifacts which are geared towards specific uses. _ Tim O'Brien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] StatefulDecoders
Oleg, no one has talked about breaking existing interfaces - 1.2 will still be supported be (at the very least) by all existing features. This is more of a discussion of future growth, we are going to find a way to enable features dependent on 1.4 while still support (creating a distributable) for 1.2. Tim On Tue, 24 Feb 2004, Oleg Kalnichevski wrote: Tim, Gary Currently [Codec] is still Java 1.2 compatible. And yes, there are [Codec] users who would like it to stay that way at least for some time. Not that we enjoy working around Java 1.2 limitations that much, but we simply have obligations to our users as well (there are several projects, including Apache ones, dependent on [HttpClient] that need to support a wide spectrum of platforms including those that do not have modern JDKs). We will support 1.2 compatible [Codec] branch ourselves, if we absolutely have to, but would still very much appreciate if you kept us posted before the decision was taken to make [Codec] dependent on Java 1.2 features. I apologize for being such a pain in the rear Oleg On Tue, 2004-02-24 at 04:37, Tim O'Brien wrote: Gary Gregory wrote: public java.util.List operation(java.nio.ByteBuffer buffer); This brings up an interesting issue: How do we potentially package and deliver some code that depends on Java 1.4. In a second [codec] jar? I think we should keep the JRE requirement to a minimum for [codec]. Here, we are stuck on 1.3.1 for the foreseeable future. We'll tackle the problem of creating a 1.3 compatible release at relase time, but for the time being, I'm not going to reject good code from highly motivated parties within the ASF. I don't think anyone plans on breaking existing interfaces, but the proposed addition is new functionality. Some others, I imagine need 1.2 compatibility. If you are using 1.2, you can expect releases that support 1.2 to be maintained if there are developers with the motivation to maintain these releases. Tim - 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] -- -- Tim O'Brien Evanston, IL (847) 863-7045 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] StatefulDecoders
Alex Karasulu wrote: Hi, I've been working on the idea of stateful Decoders designed for use with non-blocking reads where buffers are read from channels and used by decoders. As you know you don't always get the complete PDU in a single channel read and so buffers need to be handled in a decoding session. This JIRA issue contains attachments explaining the new interface: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?id=13599 First I would like to figure out what the codec people think about this stateful decoder concept and then perhaps we can add the interfaces into the codec for general use. Well reasoned issue discussion - especially with regards to memory footprint, scalability. I think StatefulDecoder would be a welcome addition to Commons Codec - subpackage stateful? Requesting your permission to use the discussion in JIRA as documentation? This is a good opportunity to provide an interface and a pointer to well conceived implementation within the ASF. Also I'm wondering if we can make the DecoderException and the EncoderException extend the IOException reather than just Exception. Most of these operations are IO based and it makes sense to me to have the Exception derive from IOException. Already chimed in, I'm +1 on this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] DecoderException superclass [WAS: StatefulDecoders]
I think the introduction of EncoderException and DecoderException in and of itself was a mistake in the first place. Creating hierarchies of exception just for the hell of it isn't a hobby I can maintain. IMO, Encoder and Decoder are similar to Reader and Writer which both throw IOException. Tim Gary Gregory wrote: It also makes me wonder why De/EncoderException do not subclass a CoderException, CodecException? Just thinking aloud... gg -Original Message- From: Tim O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, February 23, 2004 18:00 To: Jakarta Commons Developers List Subject: Re: [codec] DecoderException superclass [WAS: StatefulDecoders] Gary Gregory wrote: Alex suggests below that IOException would also make sense. Opinions? I'm don't have strong feelings either way. If EncoderException were to extend IOException, or if Encoders threw IOExceptions instead of EncoderException. Encoder and Decoder were experiments, most people who use Codec instantiate an object like Base64 or Soundex directly. If these interfaces and exceptions need to evolve, let's do it. Tim - 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: [codec] StatefulDecoders
Gary Gregory wrote: public java.util.List operation(java.nio.ByteBuffer buffer); This brings up an interesting issue: How do we potentially package and deliver some code that depends on Java 1.4. In a second [codec] jar? I think we should keep the JRE requirement to a minimum for [codec]. Here, we are stuck on 1.3.1 for the foreseeable future. We'll tackle the problem of creating a 1.3 compatible release at relase time, but for the time being, I'm not going to reject good code from highly motivated parties within the ASF. I don't think anyone plans on breaking existing interfaces, but the proposed addition is new functionality. Some others, I imagine need 1.2 compatibility. If you are using 1.2, you can expect releases that support 1.2 to be maintained if there are developers with the motivation to maintain these releases. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [codec] DecoderException superclass [WAS: StatefulDecoders]
Noel J. Bergman wrote: Encoder and Decoder are similar to Reader and Writer which both throw IOException. Note that this would no longer hold true in a push model codec library, since it would not actually perform I/O. True, having StatefulDecoder.getDecoded() throw an IOException seems fishy. StatefulDecoder operates on ByteBuffers, and getDecoded() should return an exception if there was a problem exception during encoding - say undecodable or unexpected input. Again, I'm not convinced that people actually use EncoderException and DecoderException. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] missing deprecated classes from Javadoc
Seems like our Javadoc is being generated with -nodeprecated. Can someone else confirm that my mind isn't playing tricks on me. If this is the case, this affects all Maven generated sites. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll][all] A very brief poll on your usage of javascript.
Mark, if you want to start using Javascript, the only condition is that it work on a number of browsers on all platforms. Mock up the commons nav menu in Javascript, and let's see what it would look like. -- Tim O'Brien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
