Re: Migrate to SVN?
I'm working with subversion (1.1.1)/subclipse/tortoiseSVN for a while now and I'm not completely convinced. The subclipse plugin for eclipse is by far not as mature as the cvs support (no links supported etc.) I was a little bit disappointed when I tried to use subclipse behind a proxy. I didn't managed to use subclipse behind a proxy, even though I convinced the tech stuff at the customer I'm currently working to enable the delta-v commands. On the other hand the more people using it will make the community grow that works on subclipse/subversion. Cheers, Daniel Jakarta Commons Developers List [EMAIL PROTECTED] schrieb am 25.11.04 20:08:02: 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: [EMAIL PROTECTED] __ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-io (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-io has an issue affecting its community integration. This issue affects 127 projects, and has been outstanding for 14 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - avalon-http-context : Avalon SVN - avalon-http-demo : Avalon SVN - avalon-http-examples : Avalon SVN - avalon-http-impl : Avalon SVN - avalon-http-server : Avalon SVN - avalon-http-servlet : Avalon SVN - avalon-http-static : Avalon SVN - avalon-http-test : Avalon SVN - avalon-planet-facilities : Avalon SVN - bootstrap-ojb : ObjectRelationalBridge - cocoon : Java XML Framework - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-chaperon : Java XML Framework - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-faces : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-linotype : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-poi : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-fw : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slide : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-webdav : Java XML Framework - cocoon-block-woody : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - commons-fileupload : Commons File Upload Package - commons-io : Commons I/O Utility Package - commons-jelly-tags-ojb : A variety of tags for working with the ObjectBridge persiste... - commons-jelly-tags-quartz : This is a Jelly interface for the Quartz Scheduler. - db-ojb : ObjectRelationalBridge - db-torque : Persistence Layer - forrest : Apache Forrest is an XML standards-oriented documentation fr... - fulcrum-bsf : Services Framework - fulcrum-cache : Services Framework - fulcrum-configuration-impl : Services Framework - fulcrum-crypto : Services Framework - fulcrum-dvsl : Services Framework - fulcrum-factory : Services Framework - fulcrum-hsqldb : Services Framework - fulcrum-intake : Services Framework - fulcrum-localization : Services Framework - fulcrum-mimetype : Services Framework - fulcrum-naming : Services Framework - fulcrum-osworkflow : Services Framework - fulcrum-parser : Services Framework - fulcrum-pool : Services Framework - fulcrum-quartz : Services Framework - fulcrum-security-adapter-turbine : Services Framework - fulcrum-security-api : Services Framework - fulcrum-security-memory : Services Framework - fulcrum-security-nt : Services Framework - fulcrum-template : Services Framework - fulcrum-testcontainer : Services Framework - fulcrum-upload : Services Framework - fulcrum-xmlrpc : Services Framework - fulcrum-xslt
Re: Migrate to SVN?
Le 26 nov. 04, à 00:07, Brett Porter a écrit : Has anyone experienced maven's svn support ? The scm plugin is probably the only thing not supporting it, and that's just a time issue. If it were a priority, it could be done reasonably quickly. Well, for Maven-based webistes (all at commons) that seems to be quite an issue. Is there any other place than the scm plugin where svn integration in maven makes sense ? paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32401] New: - The bundle-Attribute of the arg-Tag seems to have a Bug
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32401.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32401
Summary: The bundle-Attribute of the arg-Tag seems to have a Bug
Product: Commons
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Validator
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hello,
i have a Problem to switch the Bundle in the arg-Tag of the validation.xml
File always the default Resourcebundle is used to match the key-Attribute.
The bundle-Attribute of the msg-Tag has no Problems
Following Code.
struts-config.xml
-
.
message-resources parameter=resources.master/
message-resources key=phonebook parameter=resources.phonebook/
.
resources/phonebook.properties
--
errors.required={0} is required.
phonebook.jsp.searchfor='Search for' entry
validation.xml
-
.
form-validation
global/
formset
form name=phonebookForm
field property=telQueryValue depends=required
msg name=required key=errors.required bundle=phonebook/
arg position=0 name=required key=phonebook.jsp.searchfor
bundle=phonebook/
/field
/form
/formset
/form-validation
.
Following happens if the validator finds an error.
the errors.required key is translated, but the phonebook.jsp.searchfor key
is not translated, only if I put the key value-pair in the master.properties
File. Did anybody have an idea ? I use Validator 1.1.3, but also the
nightlybuild 1.2.0 seems to did not work. I found nothing in the web
describing this Problem. So could anyone help.
Thanks Jens
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32401] - The bundle-Attribute of the arg-Tag seems to have a Bug
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32401. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32401 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-11-26 10:21 --- Currently bundle is ignored - there isn't a version yet, that fixes this issue. It has already been reported in Bug 21760 and there is a patch waiting to go into Struts to resolve this, but that patch is dependant on some changes in Commons Validator - those have been done and were just waiting for a GA quality release of Validator 1.1.4 (its being voted on as we speak) so that we can move the Struts dependency to 1.1.4 and then appply the fix. So I'm closing this as a duplciate of Bug 21760. Niall *** This bug has been marked as a duplicate of 21760 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32152] - [net] Problem calculating total article count
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32152. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32152 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-26 10:41 --- You're right, I will put a check for that condition in there. Thanks. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/net/src/java/org/apache/commons/net/nntp NNTPClient.java
rwinston2004/11/26 01:41:32
Modified:net/src/java/org/apache/commons/net/nntp NNTPClient.java
Log:
Handle the condition where the low and high water marks are 0, as per bug
32152
Revision ChangesPath
1.15 +5 -1
jakarta-commons/net/src/java/org/apache/commons/net/nntp/NNTPClient.java
Index: NNTPClient.java
===
RCS file:
/home/cvs/jakarta-commons/net/src/java/org/apache/commons/net/nntp/NNTPClient.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- NNTPClient.java 29 Jun 2004 04:54:31 - 1.14
+++ NNTPClient.java 26 Nov 2004 09:41:32 - 1.15
@@ -193,7 +193,11 @@
firstNum = Integer.parseInt(first);
result._setFirstArticle(firstNum);
result._setLastArticle(lastNum);
-result._setArticleCount(lastNum - firstNum + 1);
+
+ if((firstNum == 0) (lastNum == 0))
+ result._setArticleCount(0);
+ else
+ result._setArticleCount(lastNum - firstNum + 1);
}
catch (NumberFormatException e)
{
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project commons-jelly-tags-ant (in module jelly-tags) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-ant has an issue affecting its community integration. This issue affects 3 projects, and has been outstanding for 42 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-ant : This is a Jelly interface for Ant. - commons-jelly-tags-fmt : This is a set of Jelly i18n tags. - commons-jelly-tags-jsl : The Jelly Stylesheet Library (JSL) Full details are available at: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-ant/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-ant-26112004.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jelly-tags/commons-jelly-tags-ant/gump_work/build_jelly-tags_commons-jelly-tags-ant.html Work Name: build_jelly-tags_commons-jelly-tags-ant (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-ant-26112004 jar [Working Directory: /usr/local/gump/public/workspace/jelly-tags/ant] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jelly-tags/ant/target/classes:/usr/local/gump/public/workspace/jelly-tags/ant/target/test-classes:/usr/local/gump/public/workspace/jakarta-commons/jelly/target/commons-jelly-26112004.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-26112004.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-26112004.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-26112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/packages/dom4j-1.4/dom4j-full.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-26112004.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/standard.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtmlXni.jar:/usr/local/gump/packages/nekohtml-0.9.3/nekohtml.jar:/usr/local/gump/public/workspace/commons-grant/target/commons-grant-26112004.jar:/usr/local/gump/public/workspace/jelly-tags/util/target/commons-jelly-tags-util-26112004.jar:/usr/local/gump/public/workspace/jelly-tags/junit/target/commons-jelly-tags-junit-26112004.jar - [junit] Testcase: readWriteIn took 0.191 sec [junit] Testcase: startUpReadWrite took 0.123 sec [junit] Testcase: copy took 0.131 sec [junit] Caused an ERROR [junit] file:/home/gump/workspaces2/public/workspace/jelly-tags/ant/target/test-classes/org/apache/commons/jelly/ant/suite.jelly:114:80: util:loadText charsetName [junit] org.apache.commons.jelly.JellyTagException: file:/home/gump/workspaces2/public/workspace/jelly-tags/ant/target/test-classes/org/apache/commons/jelly/ant/suite.jelly:114:80: util:loadText charsetName [junit] at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:680) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at
RE: [email] rm -r lib/*.jar
It's fine. Can you also do the same trick in jakarta-commons-sandbox/email/libs as well? As I sent in my email to the PMC, I thought the reason those jars are not on ibiblio is that you can't redistribute them via a website. But having them in CVS would be akin to having them in a war file, correct? You can crack open a war file and download the jar the same way you can can go into CVS and checkout just that jar. But, it's not really a big deal. It's only a problem for the nightly build based on Ant, and as long as Gump is happy (which it should be as they are installed as packages) then it doesn't bother me. Eric -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 9:47 PM To: Jakarta Commons Developers List Subject: [email] rm -r lib/*.jar Apologies for treading on people's toes here, but I wanted to get the problem solved quickly, even if it causes a bad build etc. Making sure we're good licence-wise is crucial. Craig raised the issue on the PMC list that the email component had the activation.jar and the javamail.jar in the cvs repository. We're allowed to ship them in distributions, but not to offer them separately (correct me if that's wrong somebody?). Having them in CVS is effectively offering them separately. I've rm-r'd them on the cvs server and modified the build.xml to do the same thing the project.xml does; attempt to grab them from ibiblio and fail. I used rm -r as opposed to cvs remove as they'd still be available with cvs remove. Sorry for not just waiting for the main email committers to read Craig's email from this morning. Given the time of year I'd hate for it to turn out that the 2 or 3 people most likely to fix it are in the US and out late at thanksgiving dinners. Feel free to flame :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
I don't have any problems with moving to SVN, in fact I've been itching to use it for a while, since it's become relatively mature. The only things I am unsure about is the tool support - I find the advanced CVS support in Eclipse invaluable. However, I guess the more people that use SVN, the more momentum will go into other projects like that one. So here's a +1 from me. Cheers, Rory Henri Yandell wrote: The problems I've hit are: 1/ No easy way to do 'cvs status -v project.xml' and list the tags that have been applied to a component. Instead I've switched to using an alias with: svn list http://svn.osjava.org/svn/osjava/releases | grep $1 | sed 's/\/$//' 2/ Have to change the mindset for doing releases without a piece of work. Say [io] doesn't want to release the find sub-package. The way I'd normally do this in CVS is to check it out; remove the find package and do a cvs tag. With SVN I think I would tag the whole thing; then check the tag out and treat it like a branch, removing files from it to get the right thing. I'm not sure if this is any worse; might just be a mental change. 3/ URLs. Definitely more of a pain to come up with the two long urls to tag with etc :) I wonder how well the IDE plugins do with this. How do you train them to understand your tag/branch/release strategy. 4/ Tagging multiple entities. With maven (or ant I guess), when using a shared super-build file (ie commons-build/project.xml), you should tag both your component and the super-build file. In Commons we've got around this by only using the super-build file for site generation, but I've a project where I use it for building too. To tag the right files, I have to create a new directory in releases/, commit that into svn, then svn copy various things into it. A little bit of a pain, more so if you screw up and do an update in releases/ :) Overall though I've adapted and am dealing with it. My only worries with SVN are the pains the berkeley db has given me, including some bug in viewcvs which corrupted the svn repo to the extent that the rescue scripts failed and whether IDE plugins will be good enough whenever I can afford a powerful enough laptop :) The only one that would affect the ASF for other people I think is whether their current method of using CVS is supported in SVN and how loudly they want to cry if it isn't. Hen On Thu, 25 Nov 2004 12:44:21 -0800, Martin Cooper [EMAIL PROTECTED] wrote: On Thu, 25 Nov 2004 15:37:42 -0500, Henri Yandell [EMAIL PROTECTED] wrote: The more painful tagging in svn is made up for by the advantages of svn, so I'm happy to embrace it. Hmm, I actually found tagging and branching in SVN just as easy as in CVS. Just: svn copy URL1 URL2 A doddle, as you might say. ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@brutus]: Project commons-jelly-tags-ant (in module jelly-tags) failed
Hi all,
This has been hanging around for quite some time now and I'd like to
help getting it resolved in some way.
From my reading of the code the tag
util:loadText var=text file=${basedir}/target/tmp/ant-tests/output.txt/
in ant/target/test-classes/org/apache/commons/jelly/ant/suite.jelly
line 114 somehow manages to invoke LoadTextTag#doTag without setting
the encoding.
I don't know who is supposed to set the encoding, but I don't see any
code in doTag that would check for encoding != null either. Maybe
some code change in the util tag lib hasn't been refelected in the Ant
tag lib's testsuite?
This here
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/jelly/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util/LoadTextTag.java?r1=1.6r2=1.7
looks intruiging and it's quite possible that Gump started nagging
about the problem two months ago (discounting some time that jaxen or
dom4j failed to build).
The appended patch makes the util and ant tag lib build successfully
in my personal Gump setup.
Cheers
Stefan
Index: util/src/java/org/apache/commons/jelly/tags/util/LoadTextTag.java
===
RCS file:
/home/cvspublic/jakarta-commons/jelly/jelly-tags/util/src/java/org/apache/commons/jelly/tags/util/LoadTextTag.java,v
retrieving revision 1.7
diff -u -r1.7 LoadTextTag.java
--- util/src/java/org/apache/commons/jelly/tags/util/LoadTextTag.java 12 Sep
2004 16:04:59 - 1.7
+++ util/src/java/org/apache/commons/jelly/tags/util/LoadTextTag.java 26 Nov
2004 10:25:13 -
@@ -83,10 +83,14 @@
}
Reader reader = null;
-try {
-reader = new InputStreamReader(in, encoding);
-} catch (UnsupportedEncodingException e) {
-throw new JellyTagException(unsupported encoding,e);
+if (encoding != null) {
+try {
+reader = new InputStreamReader(in, encoding);
+} catch (UnsupportedEncodingException e) {
+throw new JellyTagException(unsupported encoding,e);
+}
+} else {
+reader = new InputStreamReader(in);
}
String text = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31636] - [net] FTPClient.storeFile() should allow to specify CopyStreamListener
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31636. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31636 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-11-26 11:33 --- Since there doesnt seem to be any objections to Daniel's suggestion, I'll mark this one as WONTFIX for now. As always , reopen if this issue arises again. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32299] - [pipeline] Numerous changes and updates for Java 1.5
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32299. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32299 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-26 11:55 --- Committed changes into the repository on behalf of Kris. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
Well, for Maven-based webistes (all at commons) that seems to be quite an issue. Is there any other place than the scm plugin where svn integration in maven makes sense ? The scm plugin is only used for checkout, tagging, releases, etc. The changelog and activity reports work just fine in SVN. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] FilenameUtils#getPrefixLength is broken on Unix
Thanks, I was aware that I'd checked in bad code, but
hadn't been able to access a system since to be able
to fix it. I might get to it tonight if someone
doesn't beat me to it.
Stephen
--- Stefan Bodewig [EMAIL PROTECTED] wrote:
Hi,
this is the manual version of what Gump is trying to
tell you 8-)
FilenameUtils.getPrefixLength fails on Unix if you
pass a string of
length one as argument since it unconditionally
tries to access the
second character (just to never use it). Therefore
the test case
fails since it tests /.
The trivial patch appended fixes this problem
It will not fix the build since the tests still
fails, but I'm not
sure whether the code ot the test is wrong. The
test failure
remaining is
[junit] Testcase: testNormalize took 0,02 sec
[junit] FAILED
[junit] Check if '/../' normalized to 'null',
was '' expected:null but was:
[junit] junit.framework.ComparisonFailure: Check
if '/../' normalized to 'null', was ''
expected:null but was:
Cheers
Stefan
Index:
io/src/java/org/apache/commons/io/FilenameUtils.java
===
RCS file:
/home/cvspublic/jakarta-commons/io/src/java/org/apache/commons/io/FilenameUtils.java,v
retrieving revision 1.27
diff -u -r1.27 FilenameUtils.java
---
io/src/java/org/apache/commons/io/FilenameUtils.java
23 Nov 2004 00:04:29 -1.27
+++
io/src/java/org/apache/commons/io/FilenameUtils.java
26 Nov 2004 07:51:24 -
@@ -416,7 +416,6 @@
}
} else {
char ch0 = filename.charAt(0);
-char ch1 = filename.charAt(1);
if (ch0 == '~') {
if (len == 1) {
return -1;
-
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]
[jira] Created: (JELLY-168) jelly-tags/swing can not build
jelly-tags/swing can not build
--
Key: JELLY-168
URL: http://nagoya.apache.org/jira/browse/JELLY-168
Project: jelly
Type: Bug
Components: taglib.swing
Versions: 1.0-beta-4
Environment: Linux 2.6.8-1.521
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Reporter: carsten madsen
Priority: Minor
When trying to build jelly-tags/swing I get the following error. Seems like the
jelly test stuff is not in the jar file?
[EMAIL PROTECTED] swing]$ maven
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.1
Attempting to download commons-jelly-SNAPSHOT.jar.
build:start:
java:prepare-filesystem:
java:compile:
[echo] Compiling to
/opt/jakarta-commons/jelly/jelly-tags/swing/target/classes
java:jar-resources:
test:prepare-filesystem:
test:test-resources:
test:compile:
[javac] Compiling 5 source files to
/opt/jakarta-commons/jelly/jelly-tags/swing/target/test-classes
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:39:
package org.apache.commons.jelly.test does not exist
import org.apache.commons.jelly.test.BaseJellyTest;
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:45:
cannot find symbol
symbol: class BaseJellyTest
public class TestSwingTags extends BaseJellyTest {
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:65:
cannot find symbol
symbol : method getJellyContext()
location: class org.apache.commons.jelly.swing.TestSwingTags
JellyContext context = getJellyContext();
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:67:
cannot find symbol
symbol : method assertEquals(java.awt.Dimension,java.awt.Dimension)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Dimension(100,100), frame.getSize());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:68:
cannot find symbol
symbol : method assertEquals(java.awt.Point,java.awt.Point)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Point(200,200), frame.getLocation());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:71:
cannot find symbol
symbol : method assertNotNull(javax.swing.JButton)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertNotNull(button);
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:72:
cannot find symbol
symbol : method assertEquals(java.awt.Color,java.awt.Color)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Color(0x11,0x22,0x33), button.getBackground());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:73:
cannot find symbol
symbol : method assertEquals(java.awt.Color,java.awt.Color)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Color(0x44,0x55,0x66), button.getForeground());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:74:
cannot find symbol
symbol : method assertEquals(int,int)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(DebugGraphics.FLASH_OPTION|DebugGraphics.LOG_OPTION,
panel.getDebugGraphicsOptions());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:75:
cannot find symbol
symbol : method assertEquals(int,int)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(DebugGraphics.BUFFERED_OPTION,
button.getDebugGraphicsOptions());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:85:
cannot find symbol
symbol : method getJellyContext()
location: class org.apache.commons.jelly.swing.TestSwingTags
JellyContext context = getJellyContext();
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:93:
cannot find symbol
symbol : method assertEquals(int,int)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(GridBagConstraints.NORTH,constraints.anchor);
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:94:
cannot find symbol
symbol : method assertEquals(int,int)
location: class org.apache.commons.jelly.swing.TestSwingTags
[jira] Commented: (JELLY-168) jelly-tags/swing can not build
[
http://nagoya.apache.org/jira/browse/JELLY-168?page=comments#action_55887 ]
Paul Libbrecht commented on JELLY-168:
--
I really tried and really can't reproduce your bug.
I tried the latest CVS status and the release version.
I also tried with maven-1.0 and maven-1.0.1.
In all cases, it compiles and tests fine.
What surprises me is that you are talking about jelly version beta-4 in your
report but there's no such thing as jelly-swing-beta-4 and the download that I
see available. jelly-swing-1.0 src jar is available from the taglib webpage
(but there's no project.xml).
So... can you give more details which version you are trying to build ?
thanks
paul
jelly-tags/swing can not build
--
Key: JELLY-168
URL: http://nagoya.apache.org/jira/browse/JELLY-168
Project: jelly
Type: Bug
Components: taglib.swing
Versions: 1.0-beta-4
Environment: Linux 2.6.8-1.521
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Reporter: carsten madsen
Priority: Minor
When trying to build jelly-tags/swing I get the following error. Seems like
the jelly test stuff is not in the jar file?
[EMAIL PROTECTED] swing]$ maven
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.1
Attempting to download commons-jelly-SNAPSHOT.jar.
build:start:
java:prepare-filesystem:
java:compile:
[echo] Compiling to
/opt/jakarta-commons/jelly/jelly-tags/swing/target/classes
java:jar-resources:
test:prepare-filesystem:
test:test-resources:
test:compile:
[javac] Compiling 5 source files to
/opt/jakarta-commons/jelly/jelly-tags/swing/target/test-classes
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:39:
package org.apache.commons.jelly.test does not exist
import org.apache.commons.jelly.test.BaseJellyTest;
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:45:
cannot find symbol
symbol: class BaseJellyTest
public class TestSwingTags extends BaseJellyTest {
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:65:
cannot find symbol
symbol : method getJellyContext()
location: class org.apache.commons.jelly.swing.TestSwingTags
JellyContext context = getJellyContext();
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:67:
cannot find symbol
symbol : method assertEquals(java.awt.Dimension,java.awt.Dimension)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Dimension(100,100), frame.getSize());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:68:
cannot find symbol
symbol : method assertEquals(java.awt.Point,java.awt.Point)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Point(200,200), frame.getLocation());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:71:
cannot find symbol
symbol : method assertNotNull(javax.swing.JButton)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertNotNull(button);
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:72:
cannot find symbol
symbol : method assertEquals(java.awt.Color,java.awt.Color)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Color(0x11,0x22,0x33), button.getBackground());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:73:
cannot find symbol
symbol : method assertEquals(java.awt.Color,java.awt.Color)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(new Color(0x44,0x55,0x66), button.getForeground());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:74:
cannot find symbol
symbol : method assertEquals(int,int)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(DebugGraphics.FLASH_OPTION|DebugGraphics.LOG_OPTION,
panel.getDebugGraphicsOptions());
^
/opt/jakarta-commons/jelly/jelly-tags/swing/src/test/org/apache/commons/jelly/swing/TestSwingTags.java:75:
cannot find symbol
symbol : method assertEquals(int,int)
location: class org.apache.commons.jelly.swing.TestSwingTags
assertEquals(DebugGraphics.BUFFERED_OPTION,
button.getDebugGraphicsOptions());
^
Re: [general] Updating the Commons common web site
Martin Cooper wrote: On Thu, 25 Nov 2004 22:17:04 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: I'd verify that if you upload the tar.gz file to minotaur, tar -zxvf it and see if it expands properly. Theres no requirement in the site:deploy method that the file open in Winzip. Yes, I realise that. However, the .tar.gz file is 45 bytes long. I really, really doubt that it contains all of the files needed for the web site... ;-) First, it will only contain the top level site. When I use Maven 1.0 I get a tar ball 179 kb containing all the top level html pages. `maven site:deploy` will publish the tar to the site on minotaur appropriately, you do not have to upload it by hand. There are chances that with newer versions of Maven, that the site build is breaking. I'm sure that works if you can ever get your keys or whatever it is set up so that ssh doesn't want to ask for a password. I have never managed to get that working, and nobody has been able to explain to be - in plain English - what I need to do to get it working. Sounds like your trying to do the build on a Windoz box. I'm always frustrated by this as well, its a problem with the cmd shell and Java, not so much Maven. Reguardless, eventually I setup keys to handle the damn problem. The best option I've found is to use a *nix box to do the build. Regardless, even if Maven managed to upload the 45 bytes, I still don't think we'd have the site updated properly. ;-) true, which version of Maven are you using. Granted I havn't tested the build on anything newer than 1.0 the docs folder is old and I believe the build.xml file in the top level dir is there because Craig uses it to do nightly builds. I wouldn't attempt building the site using this file, you end up creating a mess. OK. Do you have any suggestions on how to get the Maven build in commons-build to create the right .tar.gz for uploading / deploying? You might try setting arguments to the scp/ssh executable to include your username/passwd http://maven.apache.org/reference/plugins/site/properties.html I'll hold off on updating the site, why don't you try to get maven to handle your credentials. -Mark Martin Cooper wrote: The wiki page on promoting projects indicates that certain files need to be updated for the Commons common pages, but doesn't indicate how to build those pages. I've been trying to figure it out, but my attempts have so far failed. Here's what I tried: 1) The Maven build in commons-build seems to generate the right HTML pages. However, the resulting .tar.gz file doesn't contain those pages (and in fact, WinZip thinks it's corrupt). So attempting to deploy from there doesn't work. 2) The 'docs' target in the build file at the top level of Commons fails, because it's looking for ./site.vsl, which doesn't appear anywhere in the jakarta-commons repo. Also, just looking at the build file, it references ../../anakia-project.xml, while that file seems to be present as ./anakia-project.xml. Someone must know how this is supposed to work, since I see that the entries for Email and Transaction now show up in the right place. Can someone enlighten me as to the correct process (and let me know which of the two approaches above are supposed to work, if any, so that I can try to fix them or remove them)? Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
+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: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
Henri Yandell wrote: We've started doing Jakarta projects over to SVN, but we've been doing the easy stuff first to get into the hang of it. I think a pretty fair target for Jakarta is to be fully in SVN by the end of next year; So Henri you mean like in ~ 2006? This is really far out. Can't we just make the jump and not have the hassle of dealing with two repositories at the same time. That's over a year of using both CVS and SVN for commons stuff. I could deal but its kind of a PITA. This is just my opinion. Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
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 +1 If the svn repository is stable, maybe its time. I agree with this idea because Jakarta Commons is managed as a Project. It would be bad to have part here and part there. All of the commons should go to svn at one time. Ideally, I think Apache's move to svn should have been as a whole in the first place, the whole tree should have been migrated in one move. Maybe, all Jakarta should be migrated at one time? -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? +1 to migrate all at one time - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build project.xml
mdiggory2004/11/26 08:10:08 Modified:commons-build project.xml Log: Jakarta Project logo has moved into images directory. Revision ChangesPath 1.36 +1 -1 jakarta-commons/commons-build/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/commons-build/project.xml,v retrieving revision 1.35 retrieving revision 1.36 diff -u -r1.35 -r1.36 --- project.xml 22 Nov 2004 01:49:56 - 1.35 +++ project.xml 26 Nov 2004 16:10:08 - 1.36 @@ -25,7 +25,7 @@ organization nameThe Apache Software Foundation/name urlhttp://jakarta.apache.org/url -logohttp://jakarta.apache.org/jakarta-logo.gif/logo +logohttp://jakarta.apache.org/images/jakarta-logo.gif/logo !-- urlhttp://ApacheCon.Com/2004/US//url logohttp://ApacheCon.Com/2004/US/logos/logo_only.gif/logo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Updating the Commons common web site
I ended up updating the site while I was testing ssh keys on my workstation. please review the site and make sure its what you wanted to see updated. -Mark Mark R. Diggory wrote: Martin Cooper wrote: On Thu, 25 Nov 2004 22:17:04 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: I'd verify that if you upload the tar.gz file to minotaur, tar -zxvf it and see if it expands properly. Theres no requirement in the site:deploy method that the file open in Winzip. Yes, I realise that. However, the .tar.gz file is 45 bytes long. I really, really doubt that it contains all of the files needed for the web site... ;-) First, it will only contain the top level site. When I use Maven 1.0 I get a tar ball 179 kb containing all the top level html pages. `maven site:deploy` will publish the tar to the site on minotaur appropriately, you do not have to upload it by hand. There are chances that with newer versions of Maven, that the site build is breaking. I'm sure that works if you can ever get your keys or whatever it is set up so that ssh doesn't want to ask for a password. I have never managed to get that working, and nobody has been able to explain to be - in plain English - what I need to do to get it working. Sounds like your trying to do the build on a Windoz box. I'm always frustrated by this as well, its a problem with the cmd shell and Java, not so much Maven. Reguardless, eventually I setup keys to handle the damn problem. The best option I've found is to use a *nix box to do the build. Regardless, even if Maven managed to upload the 45 bytes, I still don't think we'd have the site updated properly. ;-) true, which version of Maven are you using. Granted I havn't tested the build on anything newer than 1.0 the docs folder is old and I believe the build.xml file in the top level dir is there because Craig uses it to do nightly builds. I wouldn't attempt building the site using this file, you end up creating a mess. OK. Do you have any suggestions on how to get the Maven build in commons-build to create the right .tar.gz for uploading / deploying? You might try setting arguments to the scp/ssh executable to include your username/passwd http://maven.apache.org/reference/plugins/site/properties.html I'll hold off on updating the site, why don't you try to get maven to handle your credentials. -Mark Martin Cooper wrote: The wiki page on promoting projects indicates that certain files need to be updated for the Commons common pages, but doesn't indicate how to build those pages. I've been trying to figure it out, but my attempts have so far failed. Here's what I tried: 1) The Maven build in commons-build seems to generate the right HTML pages. However, the resulting .tar.gz file doesn't contain those pages (and in fact, WinZip thinks it's corrupt). So attempting to deploy from there doesn't work. 2) The 'docs' target in the build file at the top level of Commons fails, because it's looking for ./site.vsl, which doesn't appear anywhere in the jakarta-commons repo. Also, just looking at the build file, it references ../../anakia-project.xml, while that file seems to be present as ./anakia-project.xml. Someone must know how this is supposed to work, since I see that the entries for Email and Transaction now show up in the right place. Can someone enlighten me as to the correct process (and let me know which of the two approaches above are supposed to work, if any, so that I can try to fix them or remove them)? Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build project.properties
mdiggory2004/11/26 08:18:27 Modified:commons-build project.properties Log: All the subprojects have the published date on the grey bar (left), to make the site more consistent with this, I've moved to there on the top level site. Revision ChangesPath 1.14 +2 -2 jakarta-commons/commons-build/project.properties Index: project.properties === RCS file: /home/cvs/jakarta-commons/commons-build/project.properties,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- project.properties31 May 2004 13:21:16 - 1.13 +++ project.properties26 Nov 2004 16:18:26 - 1.14 @@ -45,7 +45,7 @@ # commons site LF ## maven.xdoc.jsl=../commons-build/commons-site.jsl -maven.xdoc.date=bottom +maven.xdoc.date=left maven.xdoc.poweredby.image=maven-feather.png maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html maven.xdoc.includeProjectDocumentation=false - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build/xdocs navigation.xml
mdiggory2004/11/26 08:20:24 Modified:commons-build/xdocs navigation.xml Log: Adding link to top level jakarta site on grey bar Revision ChangesPath 1.10 +4 -0 jakarta-commons/commons-build/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons/commons-build/xdocs/navigation.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- navigation.xml31 May 2004 13:13:12 - 1.9 +++ navigation.xml26 Nov 2004 16:20:24 - 1.10 @@ -18,6 +18,10 @@ project name=Jakarta Commons titleJakarta Commons/title body + links + item name=Jakarta +href=http://jakarta.apache.org/ +/links about-main-menu; downloads-menu; view-menu; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? +1 to migrate all at one time From the point of VFS (for sure, only a commons sandbox) +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build project.xml
mdiggory2004/11/26 08:27:36 Modified:commons-build project.xml Log: Opse, wrong logo. The javascript is using the same logo in both instances. The project.xml logo needs to be the original. Revision ChangesPath 1.37 +1 -1 jakarta-commons/commons-build/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/commons-build/project.xml,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- project.xml 26 Nov 2004 16:10:08 - 1.36 +++ project.xml 26 Nov 2004 16:27:36 - 1.37 @@ -25,7 +25,7 @@ organization nameThe Apache Software Foundation/name urlhttp://jakarta.apache.org/url -logohttp://jakarta.apache.org/images/jakarta-logo.gif/logo + logohttp://jakarta.apache.org/images/original-jakarta-logo.gif/logo !-- urlhttp://ApacheCon.Com/2004/US//url logohttp://ApacheCon.Com/2004/US/logos/logo_only.gif/logo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] Updating the Commons common web site
This looks better, more consistent! -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 5:16 PM To: Jakarta Commons Developers List Subject: Re: [general] Updating the Commons common web site I ended up updating the site while I was testing ssh keys on my workstation. please review the site and make sure its what you wanted to see updated. -Mark Mark R. Diggory wrote: Martin Cooper wrote: On Thu, 25 Nov 2004 22:17:04 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: I'd verify that if you upload the tar.gz file to minotaur, tar -zxvf it and see if it expands properly. Theres no requirement in the site:deploy method that the file open in Winzip. Yes, I realise that. However, the .tar.gz file is 45 bytes long. I really, really doubt that it contains all of the files needed for the web site... ;-) First, it will only contain the top level site. When I use Maven 1.0 I get a tar ball 179 kb containing all the top level html pages. `maven site:deploy` will publish the tar to the site on minotaur appropriately, you do not have to upload it by hand. There are chances that with newer versions of Maven, that the site build is breaking. I'm sure that works if you can ever get your keys or whatever it is set up so that ssh doesn't want to ask for a password. I have never managed to get that working, and nobody has been able to explain to be - in plain English - what I need to do to get it working. Sounds like your trying to do the build on a Windoz box. I'm always frustrated by this as well, its a problem with the cmd shell and Java, not so much Maven. Reguardless, eventually I setup keys to handle the damn problem. The best option I've found is to use a *nix box to do the build. Regardless, even if Maven managed to upload the 45 bytes, I still don't think we'd have the site updated properly. ;-) true, which version of Maven are you using. Granted I havn't tested the build on anything newer than 1.0 the docs folder is old and I believe the build.xml file in the top level dir is there because Craig uses it to do nightly builds. I wouldn't attempt building the site using this file, you end up creating a mess. OK. Do you have any suggestions on how to get the Maven build in commons-build to create the right .tar.gz for uploading / deploying? You might try setting arguments to the scp/ssh executable to include your username/passwd http://maven.apache.org/reference/plugins/site/properties.html I'll hold off on updating the site, why don't you try to get maven to handle your credentials. -Mark Martin Cooper wrote: The wiki page on promoting projects indicates that certain files need to be updated for the Commons common pages, but doesn't indicate how to build those pages. I've been trying to figure it out, but my attempts have so far failed. Here's what I tried: 1) The Maven build in commons-build seems to generate the right HTML pages. However, the resulting .tar.gz file doesn't contain those pages (and in fact, WinZip thinks it's corrupt). So attempting to deploy from there doesn't work. 2) The 'docs' target in the build file at the top level of Commons fails, because it's looking for ./site.vsl, which doesn't appear anywhere in the jakarta-commons repo. Also, just looking at the build file, it references ../../anakia-project.xml, while that file seems to be present as ./anakia-project.xml. Someone must know how this is supposed to work, since I see that the entries for Email and Transaction now show up in the right place. Can someone enlighten me as to the correct process (and let me know which of the two approaches above are supposed to work, if any, so that I can try to fix them or remove them)? Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build project.xml
mdiggory2004/11/26 08:38:54 Modified:commons-build project.xml Log: No, this is actually wrong, this should be the longer logo, like it was originally, undoing my last change. Revision ChangesPath 1.38 +1 -1 jakarta-commons/commons-build/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/commons-build/project.xml,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- project.xml 26 Nov 2004 16:27:36 - 1.37 +++ project.xml 26 Nov 2004 16:38:54 - 1.38 @@ -25,7 +25,7 @@ organization nameThe Apache Software Foundation/name urlhttp://jakarta.apache.org/url - logohttp://jakarta.apache.org/images/original-jakarta-logo.gif/logo +logohttp://jakarta.apache.org/images/jakarta-logo.gif/logo !-- urlhttp://ApacheCon.Com/2004/US//url logohttp://ApacheCon.Com/2004/US/logos/logo_only.gif/logo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Updating the Commons common web site
Thnx... Eric Pugh wrote: This looks better, more consistent! -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 5:16 PM To: Jakarta Commons Developers List Subject: Re: [general] Updating the Commons common web site I ended up updating the site while I was testing ssh keys on my workstation. please review the site and make sure its what you wanted to see updated. -Mark Mark R. Diggory wrote: Martin Cooper wrote: On Thu, 25 Nov 2004 22:17:04 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: I'd verify that if you upload the tar.gz file to minotaur, tar -zxvf it and see if it expands properly. Theres no requirement in the site:deploy method that the file open in Winzip. Yes, I realise that. However, the .tar.gz file is 45 bytes long. I really, really doubt that it contains all of the files needed for the web site... ;-) First, it will only contain the top level site. When I use Maven 1.0 I get a tar ball 179 kb containing all the top level html pages. `maven site:deploy` will publish the tar to the site on minotaur appropriately, you do not have to upload it by hand. There are chances that with newer versions of Maven, that the site build is breaking. I'm sure that works if you can ever get your keys or whatever it is set up so that ssh doesn't want to ask for a password. I have never managed to get that working, and nobody has been able to explain to be - in plain English - what I need to do to get it working. Sounds like your trying to do the build on a Windoz box. I'm always frustrated by this as well, its a problem with the cmd shell and Java, not so much Maven. Reguardless, eventually I setup keys to handle the damn problem. The best option I've found is to use a *nix box to do the build. Regardless, even if Maven managed to upload the 45 bytes, I still don't think we'd have the site updated properly. ;-) true, which version of Maven are you using. Granted I havn't tested the build on anything newer than 1.0 the docs folder is old and I believe the build.xml file in the top level dir is there because Craig uses it to do nightly builds. I wouldn't attempt building the site using this file, you end up creating a mess. OK. Do you have any suggestions on how to get the Maven build in commons-build to create the right .tar.gz for uploading / deploying? You might try setting arguments to the scp/ssh executable to include your username/passwd http://maven.apache.org/reference/plugins/site/properties.html I'll hold off on updating the site, why don't you try to get maven to handle your credentials. -Mark Martin Cooper wrote: The wiki page on promoting projects indicates that certain files need to be updated for the Commons common pages, but doesn't indicate how to build those pages. I've been trying to figure it out, but my attempts have so far failed. Here's what I tried: 1) The Maven build in commons-build seems to generate the right HTML pages. However, the resulting .tar.gz file doesn't contain those pages (and in fact, WinZip thinks it's corrupt). So attempting to deploy from there doesn't work. 2) The 'docs' target in the build file at the top level of Commons fails, because it's looking for ./site.vsl, which doesn't appear anywhere in the jakarta-commons repo. Also, just looking at the build file, it references ../../anakia-project.xml, while that file seems to be present as ./anakia-project.xml. Someone must know how this is supposed to work, since I see that the entries for Email and Transaction now show up in the right place. Can someone enlighten me as to the correct process (and let me know which of the two approaches above are supposed to work, if any, so that I can try to fix them or remove them)? Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Updating the Commons common web site
As well, this was a successful test of Maven 1.0.1 to build the top level site. -Mark Mark R. Diggory wrote: Thnx... Eric Pugh wrote: This looks better, more consistent! -Original Message- From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 5:16 PM To: Jakarta Commons Developers List Subject: Re: [general] Updating the Commons common web site I ended up updating the site while I was testing ssh keys on my workstation. please review the site and make sure its what you wanted to see updated. -Mark Mark R. Diggory wrote: Martin Cooper wrote: On Thu, 25 Nov 2004 22:17:04 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: I'd verify that if you upload the tar.gz file to minotaur, tar -zxvf it and see if it expands properly. Theres no requirement in the site:deploy method that the file open in Winzip. Yes, I realise that. However, the .tar.gz file is 45 bytes long. I really, really doubt that it contains all of the files needed for the web site... ;-) First, it will only contain the top level site. When I use Maven 1.0 I get a tar ball 179 kb containing all the top level html pages. `maven site:deploy` will publish the tar to the site on minotaur appropriately, you do not have to upload it by hand. There are chances that with newer versions of Maven, that the site build is breaking. I'm sure that works if you can ever get your keys or whatever it is set up so that ssh doesn't want to ask for a password. I have never managed to get that working, and nobody has been able to explain to be - in plain English - what I need to do to get it working. Sounds like your trying to do the build on a Windoz box. I'm always frustrated by this as well, its a problem with the cmd shell and Java, not so much Maven. Reguardless, eventually I setup keys to handle the damn problem. The best option I've found is to use a *nix box to do the build. Regardless, even if Maven managed to upload the 45 bytes, I still don't think we'd have the site updated properly. ;-) true, which version of Maven are you using. Granted I havn't tested the build on anything newer than 1.0 the docs folder is old and I believe the build.xml file in the top level dir is there because Craig uses it to do nightly builds. I wouldn't attempt building the site using this file, you end up creating a mess. OK. Do you have any suggestions on how to get the Maven build in commons-build to create the right .tar.gz for uploading / deploying? You might try setting arguments to the scp/ssh executable to include your username/passwd http://maven.apache.org/reference/plugins/site/properties.html I'll hold off on updating the site, why don't you try to get maven to handle your credentials. -Mark Martin Cooper wrote: The wiki page on promoting projects indicates that certain files need to be updated for the Commons common pages, but doesn't indicate how to build those pages. I've been trying to figure it out, but my attempts have so far failed. Here's what I tried: 1) The Maven build in commons-build seems to generate the right HTML pages. However, the resulting .tar.gz file doesn't contain those pages (and in fact, WinZip thinks it's corrupt). So attempting to deploy from there doesn't work. 2) The 'docs' target in the build file at the top level of Commons fails, because it's looking for ./site.vsl, which doesn't appear anywhere in the jakarta-commons repo. Also, just looking at the build file, it references ../../anakia-project.xml, while that file seems to be present as ./anakia-project.xml. Someone must know how this is supposed to work, since I see that the entries for Email and Transaction now show up in the right place. Can someone enlighten me as to the correct process (and let me know which of the two approaches above are supposed to work, if any, so that I can try to fix them or remove them)? Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Commons Math 1.0
Its been very quiet, this may be a good sign. Are we ready to roll on 1.0? -Mark Phil Steitz wrote: The Commons Math team is pleased to announce the release of Commons Math 1.0-RC2. Commons Math is a library of lightweight, self-contained mathematics and statistics components. This release candidate incorporates community feedback from 1.0-RC1. Assuming there are no problems reported with 1.0-RC2, the formal 1.0 release distribution will be made available on the Apache distribution mirrors in two weeks. We encourage users to wait for the final 1.0 release before putting the code into production. The release candidate source and binary distributions are available for download here: http://jakarta.apache.org/~psteitz/commons-math-1.0-RC2/dist The Commons Math web site is here: http://jakarta.apache.org/commons/math/ A list of changes since RC1 is available here: http://jakarta.apache.org/commons/math/changes-report.html Please direct any feedback on issues or bugs to [EMAIL PROTECTED], starting the subject line with [math]. -- Phil Steitz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32343.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32343
--- Additional Comments From [EMAIL PROTECTED] 2004-11-26 18:18 ---
I would like to suggest a different way of doing things with the client side
validation. If we make the different validators validate values instead of
fields, we would improve in code reusability and duplication. I'll try to
explain:
Use a generic javascript function called grabValuesFromField(oField) (or
whatever) which returns an array (most of the times a 1 element array) of
strings with all values of the specified field. Then have the different
validators validate all values from the array making them easier to mantain and
more reusable.
There is a common misconception when using html that states that the name of a
text field must be unique within a form. This is because IMHO javascript deals
with this issue erroneously: document.forms[0].textField.value should be
document.forms[0].textField[0].value. Most of the time there is one text field
for the same name, but with checkboxes or radio buttons this is not true. If you
use several text fields with the same name (which is absolutely necessary
sometimes) you need to loop through in a document.forms[0].textField[i] fashion
just like radios and checkboxes.
This is the main reason why radio and checkbox validations perform poorly
usually. I propose a first draft for this function:
function grabValuesFromField(oField) {
var values = new Array();
if ((oField.length) (!oField.type || oField.type.indexOf('select')
== -1)) {
//we have to push out the selects when they have a type because
select.length
refers to options
for (n=0; noField.length; n++) {
var singleValues = grabValuesFromSingleField(oField[n]);
name = oField[n].name;
values = values.concat(singleValues);
}
} else {
values = grabValuesFromSingleField(oField);
}
alert(values.length);
}
function grabValuesFromSingleField(oSingleField) {
var singleValues = new Array();
if (oSingleField.type == 'select-multiple') {
for (s=0; soSingleField.options.length; s++) {
if (oSingleField.options[s].selected) {
singleValues[singleValues.length] =
oSingleField.options[s].value;
}
}
} else if (oSingleField.type == 'select-one') {
singleValues[0] =
oSingleField.options[oSingleField.selectedIndex].value;
} else if (oSingleField.type == 'radio' || oSingleField.type ==
'checkbox') {
if (oSingleField.checked) {
singleValues[singleValues.length] = oSingleField.value;
}
} else {
singleValues[0] = oSingleField.value;
}
return singleValues;
}
Please take a look to the following page so you can check this in action:
http://www.visual-ma.com/validator/grab.html
The page is composed of two panels one with single fields and one with double
fields. If you click on grab you will get the number of values it has returned.
This is the number of values that should be passed to the validators. I know the
page is ugly and maybe quite confusing, specially after seeing Niall's... If
requested I'll improve it so we could have pseudo test cases.
Nacho G. Mac Dowell
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Release Validator 1.1.4
The vote to release Validator 1.1.4 resulted in 3 binding +1's and 1 non-binding +1 The vote thread is here: http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=60629 Niall Pemberton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32343. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32343 --- Additional Comments From [EMAIL PROTECTED] 2004-11-26 18:39 --- Nacho, Yes - this would be a good improvement. I'm going away this weekend, so I'm not going to get time to think about or incorporate this until sometime next week. Having said that, part of me would like to get it into commons validator first - others could then contributing/apply patches if they wanted and it wouldn't be just me doing the work :-) Anyway, thanks for your input. Niall -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Commons Math 1.0
Mark R. Diggory wrote: Its been very quiet, this may be a good sign. Are we ready to roll on 1.0? Yes. I have been on the road. When I get back tonight I will roll the release and call the vote -- at last!!! -Phil -Mark Phil Steitz wrote: The Commons Math team is pleased to announce the release of Commons Math 1.0-RC2. Commons Math is a library of lightweight, self-contained mathematics and statistics components. This release candidate incorporates community feedback from 1.0-RC1. Assuming there are no problems reported with 1.0-RC2, the formal 1.0 release distribution will be made available on the Apache distribution mirrors in two weeks. We encourage users to wait for the final 1.0 release before putting the code into production. The release candidate source and binary distributions are available for download here: http://jakarta.apache.org/~psteitz/commons-math-1.0-RC2/dist The Commons Math web site is here: http://jakarta.apache.org/commons/math/ A list of changes since RC1 is available here: http://jakarta.apache.org/commons/math/changes-report.html Please direct any feedback on issues or bugs to [EMAIL PROTECTED], starting the subject line with [math]. -- Phil Steitz - 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: Migrate to SVN?
+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: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Updating the Commons common web site
Mark R. Diggory wrote: I'm sure that works if you can ever get your keys or whatever it is set up so that ssh doesn't want to ask for a password. I have never managed to get that working, and nobody has been able to explain to be - in plain English - what I need to do to get it working. When I do it, maven always reminds me that I need to use maven -Dmaven username=psteitz site:sshdeploy then it does prompt me for a password (actually a few times) and then proceeds to do the update. I always use Linux to do it, though. Sounds like your trying to do the build on a Windoz box. I'm always frustrated by this as well, its a problem with the cmd shell and Java, not so much Maven. Reguardless, eventually I setup keys to handle the damn problem. The best option I've found is to use a *nix box to do the build. Regardless, even if Maven managed to upload the 45 bytes, I still don't think we'd have the site updated properly. ;-) true, which version of Maven are you using. Granted I havn't tested the build on anything newer than 1.0 the docs folder is old and I believe the build.xml file in the top level dir is there because Craig uses it to do nightly builds. I wouldn't attempt building the site using this file, you end up creating a mess. OK. Do you have any suggestions on how to get the Maven build in commons-build to create the right .tar.gz for uploading / deploying? You might try setting arguments to the scp/ssh executable to include your username/passwd http://maven.apache.org/reference/plugins/site/properties.html I'll hold off on updating the site, why don't you try to get maven to handle your credentials. -Mark Martin Cooper wrote: The wiki page on promoting projects indicates that certain files need to be updated for the Commons common pages, but doesn't indicate how to build those pages. I've been trying to figure it out, but my attempts have so far failed. Here's what I tried: 1) The Maven build in commons-build seems to generate the right HTML pages. However, the resulting .tar.gz file doesn't contain those pages (and in fact, WinZip thinks it's corrupt). So attempting to deploy from there doesn't work. 2) The 'docs' target in the build file at the top level of Commons fails, because it's looking for ./site.vsl, which doesn't appear anywhere in the jakarta-commons repo. Also, just looking at the build file, it references ../../anakia-project.xml, while that file seems to be present as ./anakia-project.xml. Someone must know how this is supposed to work, since I see that the entries for Email and Transaction now show up in the right place. Can someone enlighten me as to the correct process (and let me know which of the two approaches above are supposed to work, if any, so that I can try to fix them or remove them)? Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] rm -r lib/*.jar
Done. On Fri, 26 Nov 2004 11:14:28 +0100, Eric Pugh [EMAIL PROTECTED] wrote: It's fine. Can you also do the same trick in jakarta-commons-sandbox/email/libs as well? As I sent in my email to the PMC, I thought the reason those jars are not on ibiblio is that you can't redistribute them via a website. But having them in CVS would be akin to having them in a war file, correct? You can crack open a war file and download the jar the same way you can can go into CVS and checkout just that jar. But, it's not really a big deal. It's only a problem for the nightly build based on Ant, and as long as Gump is happy (which it should be as they are installed as packages) then it doesn't bother me. Eric -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 9:47 PM To: Jakarta Commons Developers List Subject: [email] rm -r lib/*.jar Apologies for treading on people's toes here, but I wanted to get the problem solved quickly, even if it causes a bad build etc. Making sure we're good licence-wise is crucial. Craig raised the issue on the PMC list that the email component had the activation.jar and the javamail.jar in the cvs repository. We're allowed to ship them in distributions, but not to offer them separately (correct me if that's wrong somebody?). Having them in CVS is effectively offering them separately. I've rm-r'd them on the cvs server and modified the build.xml to do the same thing the project.xml does; attempt to grab them from ibiblio and fail. I used rm -r as opposed to cvs remove as they'd still be available with cvs remove. Sorry for not just waiting for the main email committers to read Craig's email from this morning. Given the time of year I'd hate for it to turn out that the 2 or 3 people most likely to fix it are in the US and out late at thanksgiving dinners. Feel free to flame :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Volunteer for SVN migration management? Was: Migrate to SVN?
Do we have a volunteer to organise the move of Commons to SVN? (which is probably some combination of: vote, plan, liaise with infra) 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: [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]
cvs commit: jakarta-commons/io/src/java/org/apache/commons/io FilenameUtils.java
martinc 2004/11/26 11:18:28
Modified:io/src/java/org/apache/commons/io FilenameUtils.java
Log:
Fix breakage when getPrefixLength() is fed a string of length one.
Revision ChangesPath
1.28 +1 -2
jakarta-commons/io/src/java/org/apache/commons/io/FilenameUtils.java
Index: FilenameUtils.java
===
RCS file:
/home/cvs/jakarta-commons/io/src/java/org/apache/commons/io/FilenameUtils.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- FilenameUtils.java23 Nov 2004 00:04:29 - 1.27
+++ FilenameUtils.java26 Nov 2004 19:18:28 - 1.28
@@ -416,7 +416,6 @@
}
} else {
char ch0 = filename.charAt(0);
-char ch1 = filename.charAt(1);
if (ch0 == '~') {
if (len == 1) {
return -1;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] FilenameUtils#getPrefixLength is broken on Unix
I've removed the offending line, as suggested. I have not fixed the
test problems, though. I'll leave that for Stephen. ;-)
FYI, the tests also fail on Windows, but the failure I see is:
[junit] Testcase: testNormalize took 0.02 sec
[junit] FAILED
[junit] Check if '///' normalized to '\', was 'null' expected:\
but was:null
[junit] junit.framework.ComparisonFailure: Check if '///'
normalized to '\', was 'null' expected:\ but was:null
--
Martin Cooper
On Fri, 26 Nov 2004 08:56:40 +0100, Stefan Bodewig [EMAIL PROTECTED] wrote:
Hi,
this is the manual version of what Gump is trying to tell you 8-)
FilenameUtils.getPrefixLength fails on Unix if you pass a string of
length one as argument since it unconditionally tries to access the
second character (just to never use it). Therefore the test case
fails since it tests /.
The trivial patch appended fixes this problem
It will not fix the build since the tests still fails, but I'm not
sure whether the code ot the test is wrong. The test failure
remaining is
[junit] Testcase: testNormalize took 0,02 sec
[junit] FAILED
[junit] Check if '/../' normalized to 'null', was '' expected:null but
was:
[junit] junit.framework.ComparisonFailure: Check if '/../' normalized to
'null', was '' expected:null but was:
Cheers
Stefan
Index: io/src/java/org/apache/commons/io/FilenameUtils.java
===
RCS file:
/home/cvspublic/jakarta-commons/io/src/java/org/apache/commons/io/FilenameUtils.java,v
retrieving revision 1.27
diff -u -r1.27 FilenameUtils.java
--- io/src/java/org/apache/commons/io/FilenameUtils.java23 Nov 2004
00:04:29 - 1.27
+++ io/src/java/org/apache/commons/io/FilenameUtils.java26 Nov 2004
07:51:24 -
@@ -416,7 +416,6 @@
}
} else {
char ch0 = filename.charAt(0);
-char ch1 = filename.charAt(1);
if (ch0 == '~') {
if (len == 1) {
return -1;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] rm -r lib/*.jar
On Fri, 26 Nov 2004 11:14:28 +0100, Eric Pugh [EMAIL PROTECTED] wrote: But, it's not really a big deal. It's only a problem for the nightly build based on Ant, and as long as Gump is happy (which it should be as they are installed as packages) then it doesn't bother me. If the Ant script had properties to define the source URLs for these two JARs, I could point them at my local copies. The license on the JARs in question allows them to be distributed as *part* of a larger package, so my building my own copy into the nightlies is fine ... the license also says you cannot make them available *separately*, which is why having them in CVS doesn't work. Would you guys mind if I hand patched the build.xml file to see if I can get that to work? Eric Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32360] - Default Namespace not handled correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32360. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32360 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-11-26 21:05 --- I really don't think this is a bug, and the solution that you have in the bug description is the correct one. Here's a quote from the XPath specification: 'A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context. This is the same way expansion is done for element type names in start and end-tags except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then the namespace URI is null (this is the same way attribute names are expanded). It is an error if the QName has a prefix for which there is no namespace declaration in the expression context.' See: http://www.w3c.org/TR/xpath.html#node-tests -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator project.xml
dgraham 2004/11/26 12:55:49 Modified:validator project.xml Log: Updated dependency versions to latest releases for commons-logging, commons-beanutils, commons-digester, and commons-collections. Updated version number to 1.2.0-dev and alphabetized the developer list. Revision ChangesPath 1.55 +23 -23jakarta-commons/validator/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/validator/project.xml,v retrieving revision 1.54 retrieving revision 1.55 diff -u -r1.54 -r1.55 --- project.xml 12 Nov 2004 17:53:07 - 1.54 +++ project.xml 26 Nov 2004 20:55:49 - 1.55 @@ -20,7 +20,7 @@ nameValidator/name idcommons-validator/id - currentVersion1.1.4/currentVersion + currentVersion1.2.0-dev/currentVersion inceptionYear2002/inceptionYear shortDescriptionCommons Validator/shortDescription description @@ -75,6 +75,12 @@ developers developer + nameDon Brown/name + idmrdon/id + email[EMAIL PROTECTED]/email + organization/organization +/developer +developer nameMartin Cooper/name idmartinc/id email[EMAIL PROTECTED]/email @@ -105,24 +111,6 @@ organization/organization /developer developer - nameJames Turner/name - idturner/id - email[EMAIL PROTECTED]/email - organization/organization -/developer -developer - nameDavid Winterfeldt/name - iddwinterfeldt/id - email[EMAIL PROTECTED]/email - organization/organization -/developer -developer - nameDon Brown/name - idmrdon/id - email[EMAIL PROTECTED]/email - organization/organization -/developer -developer nameJames Mitchell/name idjmitchell/id emailjmitchell NOSPAM apache.org/email @@ -134,6 +122,18 @@ emailniallp NOSPAM apache.org/email organization/organization /developer +developer + nameJames Turner/name + idturner/id + email[EMAIL PROTECTED]/email + organization/organization +/developer +developer + nameDavid Winterfeldt/name + iddwinterfeldt/id + email[EMAIL PROTECTED]/email + organization/organization +/developer /developers contributors @@ -270,25 +270,25 @@ dependency idcommons-beanutils/id - version1.6.1/version + version1.7.0/version urlhttp://jakarta.apache.org/commons/beanutils.html/url /dependency dependency idcommons-collections/id - version2.1/version + version3.1/version urlhttp://jakarta.apache.org/commons/collections.html/url /dependency dependency idcommons-digester/id - version1.5/version + version1.6/version urlhttp://jakarta.apache.org/commons/digester.html/url /dependency dependency idcommons-logging/id - version1.0.3/version + version1.0.4/version urlhttp://jakarta.apache.org/commons/logging.html/url /dependency - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator project.xml
dgraham 2004/11/26 13:08:27 Modified:validator project.xml Log: Removed the commons-collections dependency because we only use FastHashMap which is included in the commons-beanutils 1.7.0 release. Our usage of FastHashMap has been deprecated for some time so we could remove those references soon anyways. Revision ChangesPath 1.56 +0 -6 jakarta-commons/validator/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/validator/project.xml,v retrieving revision 1.55 retrieving revision 1.56 diff -u -r1.55 -r1.56 --- project.xml 26 Nov 2004 20:55:49 - 1.55 +++ project.xml 26 Nov 2004 21:08:27 - 1.56 @@ -275,12 +275,6 @@ /dependency dependency - idcommons-collections/id - version3.1/version - urlhttp://jakarta.apache.org/commons/collections.html/url -/dependency - -dependency idcommons-digester/id version1.6/version urlhttp://jakarta.apache.org/commons/digester.html/url - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator project.xml
dgraham 2004/11/26 13:16:05 Modified:validator project.xml Log: Fixed beanutils, logging, and digester dependency urls. Revision ChangesPath 1.57 +4 -4 jakarta-commons/validator/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/validator/project.xml,v retrieving revision 1.56 retrieving revision 1.57 diff -u -r1.56 -r1.57 --- project.xml 26 Nov 2004 21:08:27 - 1.56 +++ project.xml 26 Nov 2004 21:16:05 - 1.57 @@ -271,19 +271,19 @@ dependency idcommons-beanutils/id version1.7.0/version - urlhttp://jakarta.apache.org/commons/beanutils.html/url + urlhttp://jakarta.apache.org/commons/beanutils//url /dependency dependency idcommons-digester/id version1.6/version - urlhttp://jakarta.apache.org/commons/digester.html/url + urlhttp://jakarta.apache.org/commons/digester//url /dependency dependency idcommons-logging/id version1.0.4/version - urlhttp://jakarta.apache.org/commons/logging.html/url + urlhttp://jakarta.apache.org/commons/logging//url /dependency dependency @@ -302,7 +302,7 @@ dependency idjunit/id version3.8.1/version - urlhttp://www.junit.org/url + urlhttp://www.junit.org//url /dependency /dependencies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator GenericTypeValidator.java
dgraham 2004/11/26 13:25:12
Modified:validator/src/share/org/apache/commons/validator/util
ValidatorUtils.java
validator/src/share/org/apache/commons/validator
GenericTypeValidator.java
Log:
Made Log instance final.
Revision ChangesPath
1.9 +5 -11
jakarta-commons/validator/src/share/org/apache/commons/validator/util/ValidatorUtils.java
Index: ValidatorUtils.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/util/ValidatorUtils.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- ValidatorUtils.java 8 Jun 2004 17:17:44 - 1.8
+++ ValidatorUtils.java 26 Nov 2004 21:25:12 - 1.9
@@ -41,10 +41,7 @@
*/
public class ValidatorUtils {
-/**
- * Logger.
- */
-private static Log log = LogFactory.getLog(ValidatorUtils.class);
+private static final Log log = LogFactory.getLog(ValidatorUtils.class);
/**
* pReplace part of a codeString/code with another value./p
@@ -53,10 +50,7 @@
* @param key The name of the constant.
* @param replaceValue The value of the constant.
*/
-public static String replace(
-String value,
-String key,
-String replaceValue) {
+public static String replace(String value, String key, String
replaceValue) {
if (value == null || key == null || replaceValue == null) {
return value;
1.15 +4 -4
jakarta-commons/validator/src/share/org/apache/commons/validator/GenericTypeValidator.java
Index: GenericTypeValidator.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/GenericTypeValidator.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- GenericTypeValidator.java 9 Apr 2004 00:16:39 - 1.14
+++ GenericTypeValidator.java 26 Nov 2004 21:25:12 - 1.15
@@ -36,7 +36,7 @@
*/
public class GenericTypeValidator implements Serializable {
- private static Log log = LogFactory.getLog(GenericTypeValidator.class);
+ private static final Log log =
LogFactory.getLog(GenericTypeValidator.class);
/**
* Checks if the value can safely be converted to a byte primitive.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/test/org/apache/commons/validator TestCommon.java TestNumber.java ExtensionTest.java
dgraham 2004/11/26 13:35:19
Modified:validator/src/test/org/apache/commons/validator
TestCommon.java TestNumber.java ExtensionTest.java
Log:
Removed logging from tests. They should either pass or fail without
requiring us to look through log messages.
Revision ChangesPath
1.7 +5 -21
jakarta-commons/validator/src/test/org/apache/commons/validator/TestCommon.java
Index: TestCommon.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/test/org/apache/commons/validator/TestCommon.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- TestCommon.java 21 Feb 2004 17:10:30 - 1.6
+++ TestCommon.java 26 Nov 2004 21:35:19 - 1.7
@@ -25,8 +25,6 @@
import junit.framework.TestCase;
-import org.apache.commons.logging.Log;
-import org.apache.commons.logging.LogFactory;
import org.xml.sax.SAXException;
/**
@@ -38,11 +36,6 @@
* Resources used for validation tests.
*/
protected ValidatorResources resources = null;
-
-/**
- * Commons Logging instance.
- */
-protected Log log = LogFactory.getLog(this.getClass());
public TestCommon(String string) {
super(string);
@@ -59,19 +52,10 @@
try {
in = this.getClass().getResourceAsStream(file);
resources = new ValidatorResources(in);
-
-} catch (IOException e) {
-log.error(e.getMessage(), e);
-throw e;
-
} finally {
if (in != null) {
-try {
-in.close();
-} catch (IOException e) {
-log.error(e.getMessage(), e);
-}
-}
+ in.close();
+ }
}
}
}
1.5 +4 -10
jakarta-commons/validator/src/test/org/apache/commons/validator/TestNumber.java
Index: TestNumber.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/test/org/apache/commons/validator/TestNumber.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TestNumber.java 21 Feb 2004 17:10:30 - 1.4
+++ TestNumber.java 26 Nov 2004 21:35:19 - 1.5
@@ -18,7 +18,7 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
-
+
package org.apache.commons.validator;
import java.io.IOException;
@@ -65,9 +65,6 @@
// Create bean to run test on.
ValueBean info = new ValueBean();
info.setValue(0);
-if (log.isDebugEnabled()) {
-log.debug(testNumberFailure Action= + ACTION + , FORM_KEY= +
FORM_KEY);
-}
valueTest(info, true);
}
@@ -77,9 +74,6 @@
public void testNumberFailure() throws ValidatorException {
// Create bean to run test on.
ValueBean info = new ValueBean();
-if (log.isDebugEnabled()) {
-log.debug(testNumberFailure Action= + ACTION + , FORM_KEY= +
FORM_KEY);
-}
valueTest(info, false);
}
1.2 +15 -27
jakarta-commons/validator/src/test/org/apache/commons/validator/ExtensionTest.java
Index: ExtensionTest.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/test/org/apache/commons/validator/ExtensionTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ExtensionTest.java4 Apr 2004 13:53:25 - 1.1
+++ ExtensionTest.java26 Nov 2004 21:35:19 - 1.2
@@ -27,9 +27,6 @@
import junit.framework.TestCase;
import junit.framework.TestSuite;
-import org.apache.commons.logging.Log;
-import org.apache.commons.logging.LogFactory;
-
/**
* pPerforms tests for extension in form definitions. Performs the same
tests
* RequiredNameTest does but with an equivalent validation definition with
extension
@@ -61,12 +58,6 @@
*/
protected static String ACTION = required;
-
-/**
- * Commons Logging instance.
-*/
-private Log log = LogFactory.getLog(this.getClass());
-
/**
* Resources used for validation tests.
*/
@@ -103,21 +94,18 @@
* validator-extension.xml.
*/
protected void setUp() throws Exception {
- // Load resources
- InputStream in = null;
+ // Load resources
+ InputStream in = null;
- try {
- in =
this.getClass().getResourceAsStream(validator-extension.xml);
- resources = new
Re: [transaction] improved logging interface.
I thought the standard way to handle this is to guard the log statements with checks if the log level is enabled like: if (isFineEnabled()) logFine(anyObject1 + any string + anyObject2); which already is possible with LoggerFacade. This would make the extension obsolete... Oliver On Thu, 25 Nov 2004 14:19:13 +0100, Stefan Lützkendorf [EMAIL PROTECTED] wrote: Hello Oliver, I would like to improve the LoggerFacade interface with methods like, logFiner(String message, Object param1); logFiner(String message, Object param1, Object param2); logFine(String message, Object param1); ... to avoid the frequently used calls like logFine(anyObject1 + any string + anyObject2); This would reduce the overhead if logging is disabled. Changing the interfaces before the first release would be good, I think. What do you think? Regards, Stefan -- Stefan Lützkendorf -- [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: Migrate to SVN?
I remain unenthused by SVN, probably because I don't have to manage a CVS server. Effectively I'm -1, but I'm probably not going to fight. My main reason is that SVN does not appear to be that widely adopted yet. A sign that the time has come to migrate would be when Eclipse/Idea ships with SVN support built in. At the moment, I fear we may just scare off some potential users/contributers. If we are moving though, I would want the pain all at once. Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] +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: [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]
[Jakarta Commons Wiki] Updated: TheSandbox
Date: 2004-11-26T15:21:15 Editor: OliverZeigermann [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: TheSandbox URL: http://wiki.apache.org/jakarta-commons/TheSandbox no comment Change Log: -- @@ -30,7 +30,6 @@ * Reflect - extracted from BeanUtils, but unfinished and in a coma. * Servlet - not enough here to justify a component * Threading - migrated over from Avalon Excalibur. Currently inactive. - * Transaction - extracted from Slide, ready for promotion. * xo - XML to Bean mapper. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: FrontPage
Date: 2004-11-26T15:22:56 Editor: OliverZeigermann [EMAIL PROTECTED] Wiki: Jakarta Commons Wiki Page: FrontPage URL: http://wiki.apache.org/jakarta-commons/FrontPage no comment Change Log: -- @@ -28,6 +28,7 @@ * [:Math] is a library of lightweight, self-contained mathematics and statistics components. * [:Net] - Net is a collection of classes implementing various network protocols such as FTP, NNTP, SMTP, Telnet. * [:Pool] - Pool provides a generic object pooling interface, a toolkit for creating modular object pools and several general purpose pool implementations. + * [:Transaction] - Transaction provides utility classes commonly used in transactional programming * [:Validator] - Validator provides components for user input validation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
Stephen Colebourne wrote: My main reason is that SVN does not appear to be that widely adopted yet. A sign that the time has come to migrate would be when Eclipse/Idea ships with SVN support built in. IDEA's current EAP cycle has included support OOTB. I haven't tried it yet though... At the moment, I fear we may just scare off some potential users/contributers. Good point. How much will this affect commons as a whole? Are there any particular components that are receiving a lot of user contributions? I personally think they'll figure it out if we have reasonable SVN documentation to help them out. The reverse is also true. Folks can now get access to SVN behind a corporate proxy, where with CVS an SSH tunnel is nearly impossible to attain and pserver only slightly easier. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: FrontPage
Date: 2004-11-26T15:28:45 Editor: 12.108.188.134 Wiki: Jakarta Commons Wiki Page: FrontPage URL: http://wiki.apache.org/jakarta-commons/FrontPage Chain and Resources are in Commons Proper now. Change Log: -- @@ -13,6 +13,7 @@ On this wiki: * [:BeanUtils] - !BeanUtils is a collection of bean related libraries. * [:Betwixt] - Betwixt provides services for mapping !JavaBeans to XML documents, and vice versa. + * [:Chain] - A Chain of Responsibility pattern implemention for organizing complex processing flows. * [:Codec] - Codec contains some general encoding/decoding algorithms. Includes some phonetic encoders, Hex, Base64, and a URL encoder. * [:Collections] - Collections builds upon the Java Collections Framework of List, Set and Map to provide many more implementations, new collections and abstract base classes. * [:Configuration] - Tools to assist in the reading of configuration/preferences files in various formats @@ -28,6 +29,7 @@ * [:Math] is a library of lightweight, self-contained mathematics and statistics components. * [:Net] - Net is a collection of classes implementing various network protocols such as FTP, NNTP, SMTP, Telnet. * [:Pool] - Pool provides a generic object pooling interface, a toolkit for creating modular object pools and several general purpose pool implementations. + * [:Resources] - A lightweight framework for defining and looking up internationalized message strings. * [:Transaction] - Transaction provides utility classes commonly used in transactional programming * [:Validator] - Validator provides components for user input validation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrate to SVN?
Noel, Can you comment on the admin-side advantages of svn ? I do know most of the client-side advantages... thanks paul Le 27 nov. 04, à 00:12, Stephen Colebourne a écrit : I remain unenthused by SVN, probably because I don't have to manage a CVS server. Effectively I'm -1, but I'm probably not going to fight. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Commons Wiki] Updated: TheSandbox
Date: 2004-11-26T15:29:35 Editor: 12.108.188.134 Wiki: Jakarta Commons Wiki Page: TheSandbox URL: http://wiki.apache.org/jakarta-commons/TheSandbox Chain and Resources are in Commons Proper now. Change Log: -- @@ -3,7 +3,6 @@ (Published means that the sandbox component is on the Jakarta Commons website) * Cache - * CommonsChain - needed for Struts 1.3.x, undergoing promotion * Clazz - no community, code stable. * Compress - code extracted from Ant, currently dormant. * CommonsConvert - various conversion ideas extracted from BeanUtils, currently in development. @@ -13,7 +12,6 @@ * JJar - ready to die as superseded by Apache Depot. * Mapper * Messenger - * Resources - needed for Struts 1.3.x, undergoing promotion * [http://jakarta.apache.org/commons/sandbox/scaffold/ Scaffold] is a toolkit for building web applications, to complement web application frameworks (such as Struts). * SQL * ThreadPool - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [convert] a different approach...
Thursday, November 18, 2004, 5:57:48 AM, Matt Sgarlata wrote: I haven't been on the list a while but I saw your posts earlier this month. I too, like Ron, spent some time developing my own approach to the goals of the commons-convert project. I have some code started out that isn't incredibly well documented, but all the ideas are there. Below is a summary of my approach. The code is available at the URL below under the Apache 2.0 license. I've taken a quick look at your description and the source, which looks quite promising. Correct me if I am getting things wrong, but I think we try to solve different problems, which is acutally a good thing (as they might even complement each other). If I get things right, you try to provide a framework for passing bean like structures around, and convert them to their various representations, as every library provides its own. My focus is on trying to provide a generic conversion framework, with primary focus on the type. Eg, some libraries like to use int, others prefer short, which makes not much of a difference if all values are, say, between 0 and 1000. While this conversion is quite simple for some types, it can be cumbersome for others, eg if you got a short[], but the library prefers an int[]. Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/io/src/test/org/apache/commons/io AllIOTestSuite.java
scolebourne2004/11/26 17:21:31
Added: io/src/test/org/apache/commons/io AllIOTestSuite.java
Log:
Compound test suite
Revision ChangesPath
1.1
jakarta-commons/io/src/test/org/apache/commons/io/AllIOTestSuite.java
Index: AllIOTestSuite.java
===
/*
* Copyright 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
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.commons.io;
import junit.framework.Test;
import junit.framework.TestSuite;
import junit.textui.TestRunner;
/**
* A basic test suite that tests all the IO component.
*
* @author Stephen Colebourne
*/
public class AllIOTestSuite {
public static void main(String[] args) {
TestRunner.run(suite());
}
public static Test suite() {
TestSuite suite = new TestSuite(IO);
suite.addTest(PackageTestSuite.suite());
suite.addTest(org.apache.commons.io.filefilter.PackageTestSuite.suite());
suite.addTest(org.apache.commons.io.input.PackageTestSuite.suite());
suite.addTest(org.apache.commons.io.output.PackageTestSuite.suite());
return suite;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/io/src/java/org/apache/commons/io FilenameUtils.java
scolebourne2004/11/26 17:22:06
Modified:io/src/test/org/apache/commons/io FilenameUtilsTestCase.java
io/src/java/org/apache/commons/io FilenameUtils.java
Log:
Refactor normalize method, and simplify getPrefixLength
Revision ChangesPath
1.21 +204 -216
jakarta-commons/io/src/test/org/apache/commons/io/FilenameUtilsTestCase.java
Index: FilenameUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/io/src/test/org/apache/commons/io/FilenameUtilsTestCase.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- FilenameUtilsTestCase.java23 Nov 2004 00:04:29 - 1.20
+++ FilenameUtilsTestCase.java27 Nov 2004 01:22:05 - 1.21
@@ -38,6 +38,7 @@
*/
public class FilenameUtilsTestCase extends FileBasedTestCase {
+private static final String SEP = + File.separatorChar;
private static final boolean WINDOWS = (File.separatorChar == '\\');
private File testFile1;
@@ -80,8 +81,7 @@
FileUtils.deleteDirectory(getTestDirectory());
}
-// catPath
-
+//---
public void testCatPath() {
// TODO StringIndexOutOfBoundsException thrown if file doesn't
contain slash.
// Is this acceptable?
@@ -93,96 +93,126 @@
assertEquals(C:\\a + File.separator + d,
FilenameUtils.catPath(C:\\a\\b\\c, ../d));
}
-// resolveFile
-
-public void testResolveFileDotDot() throws Exception {
-File file = FilenameUtils.resolveFile(getTestDirectory(), ..);
-assertEquals(
-Check .. operator,
-file,
-getTestDirectory().getParentFile());
-}
-
-public void testResolveFileDot() throws Exception {
-File file = FilenameUtils.resolveFile(getTestDirectory(), .);
-assertEquals(Check . operator, file, getTestDirectory());
-}
-
-// normalize
-
+//---
public void testNormalize() throws Exception {
-String[] src =
-{
-null,
-,
-/,
-///,
-/foo,
-/foo//,
-/./,
-/foo/./,
-/foo/./bar,
-/foo/../bar,
-/foo/../bar/../baz,
-/foo/bar/../../baz,
-/././,
-/foo/./../bar,
-/foo/.././bar/,
-//foo//./bar,
-/../,
-/foo/../../,
-../foo,
-foo/../../bar,
-foo/../bar };
-
-String[] dest =
-{
-null,
-,
-/,
-/,
-/foo,
-/foo/,
-/,
-/foo/,
-/foo/bar,
-/bar,
-/baz,
-/baz,
-/,
-/bar,
-/bar/,
-/foo/bar,
-null,
-null,
-null,
-null,
-bar };
-
-assertEquals(Oops, test writer goofed, src.length, dest.length);
-
-for (int i = 0; i src.length; i++) {
-String destStr = FilenameUtils.separatorsToSystem(dest[i]);
-String resultStr = FilenameUtils.normalize(src[i]);
-assertEquals(
-Check if ' + src[i] + ' normalized to ' + destStr + ',
was ' + resultStr + ',
-destStr, resultStr);
-}
-}
-
-private String replaceAll(
-String text,
-String lookFor,
-String replaceWith) {
-StringBuffer sb = new StringBuffer(text);
-while (true) {
-int idx = sb.toString().indexOf(lookFor);
-if (idx 0) {
-break;
-}
-sb.replace(idx, idx + lookFor.length(), replaceWith);
-}
-return sb.toString();
+assertEquals(null, FilenameUtils.normalize(null));
+assertEquals(null, FilenameUtils.normalize(:));
+assertEquals(null, FilenameUtils.normalize(1:\\a\\b\\c.txt));
+assertEquals(null, FilenameUtils.normalize(1:));
+assertEquals(null, FilenameUtils.normalize(1:a));
+assertEquals(null, FilenameUtils.normalize(\\a\\b\\c.txt));
+assertEquals(null, FilenameUtils.normalize(a));
+assertEquals(null, FilenameUtils.normalize(~));
+assertEquals(null, FilenameUtils.normalize(~user));
+
+
cvs commit: jakarta-commons-sandbox/resources/xdocs/images logo.png
martinc 2004/11/26 21:01:55 Removed: resources .cvsignore LICENSE.txt NOTICE.txt PROPOSAL.html STATUS.html build-legacy.xml build.xml maven.xml project.properties project.xml resources/lib ibatis-db-1.2.9.jar resources/src/conf MANIFEST.MF mysql.sql resources/src/java overview.html resources/src/java/org/apache/commons/resources Message.java MessageList.java Messages.java Resources.java ResourcesException.java ResourcesFactory.java ResourcesKeyException.java package.html resources/src/java/org/apache/commons/resources/impl BasicMessage.java BasicMessageList.java CollectionResourcesBase.java DatabaseBasicMessage.java JDBCResources.java JDBCResourcesFactory.java PropertyResources.java PropertyResourcesFactory.java ResourceBundleResources.java ResourceBundleResourcesFactory.java ResourcesBase.java ResourcesFactoryBase.java WebappPropertyResources.java WebappPropertyResourcesFactory.java WebappXMLResources.java WebappXMLResourcesFactory.java XMLResources.java XMLResourcesFactory.java package.html resources/src/test init.sql log4j.properties resources/src/test/org/apache/commons/resources MessagesTestCase.java resources/src/test/org/apache/commons/resources/impl BasicMessageListTestCase.java BasicMessageTestCase.java CollResources.java CollResourcesFactory.java CollectionResourcesBaseTestCase.java JDBCResourcesTestCase.java LocalStrings.properties MessageResources.xml PropertyResourcesTestCase.java ResourceBundleResourcesFactoryTestCase.java ResourceBundleResourcesTestCase.java ResourcesBaseTestCase.java ResourcesFactoryBaseTestCase.java TestResources.java TestResources.properties TestResources.xml TestResourcesFactory.java TestResources_en.properties TestResources_en.xml TestResources_en_US.properties TestResources_en_US.xml TestResources_fr.properties TestResources_fr.xml XMLResourcesTestCase.java jdbc.test.config.properties resources/src/web/test-webapp-resource test-non-webapp-resource.xml test-webapp-resource.xml test.txt testWebappResource.jsp test_en_US.txt test_en_US_GMT.txt resources/src/web/test-webapp-resource/WEB-INF web.xml resources/xdocs index.xml navigation.xml todo.xml resources/xdocs/images logo.png Log: Resources has moved to Commons Proper. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
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: [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: 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: Volunteer for SVN migration management? Was: Migrate to SVN?
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] - 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: Migrate to SVN?
Stephen Colebourne wrote: I remain unenthused by SVN, probably because I don't have to manage a CVS server. Effectively I'm -1, but I'm probably not going to fight. My main reason is that SVN does not appear to be that widely adopted yet. A sign that the time has come to migrate would be when Eclipse/Idea ships with SVN support built in. At the moment, I fear we may just scare off some potential users/contributers. IntelliJ 5.0 will have subversion support and based on past history the EAP should have SVN within 2 months, I am hoping sooner. JBuilder 11 has Subversion support also. If we are moving though, I would want the pain all at once. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] rm -r lib/*.jar
We appreciate all the help we can get :-) -Corey On Fri, 26 Nov 2004 11:35:04 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: On Fri, 26 Nov 2004 11:14:28 +0100, Eric Pugh [EMAIL PROTECTED] wrote: But, it's not really a big deal. It's only a problem for the nightly build based on Ant, and as long as Gump is happy (which it should be as they are installed as packages) then it doesn't bother me. If the Ant script had properties to define the source URLs for these two JARs, I could point them at my local copies. The license on the JARs in question allows them to be distributed as *part* of a larger package, so my building my own copy into the nightlies is fine ... the license also says you cannot make them available *separately*, which is why having them in CVS doesn't work. Would you guys mind if I hand patched the build.xml file to see if I can get that to work? Eric Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
