[jira] Commented: (POOL-75) [pool] GenericObjectPool not FIFO with respect to borrowing threads
[ http://issues.apache.org/jira/browse/POOL-75?page=comments#action_12415087 ] Sandy McArthur commented on POOL-75: While the implementation in the patch (in bugzilla) looks straight forward, I think it has some problems. 1: I think with the _borrowerQueue.add(Thread.currentThread()); out side the sync block you have race that could lead to: 1.a: a pool configured to use WHEN_EXHAUSTED_FAIL to throw a NoSuchElementException when it shouldn't. 1.b: a pool configured to use WHEN_EXHAUSTED_GROW to create a new poolable objects when there are idle objects available. 2. Since if this were to be included in Pool it would mostly likely be included in Pool 2.0 it should pass those unit tests. (To test with these extend TestObjectPool or subclass and implement the makeEmptyPool methods and the suit method.) Currently it fails the TestObjectPool.testPOFBorrowObjectUsages() test as it calls activateObject for an object that was just made via makeObject. This fix is as simple as adding return pair.value; right after the newlyCreated = true; line. 3. How is this supposed to work with the evictor? Is the evictor allowed to preempt the other threads? I think that is what would happen now. [pool] GenericObjectPool not FIFO with respect to borrowing threads --- Key: POOL-75 URL: http://issues.apache.org/jira/browse/POOL-75 Project: Commons Pool Type: Improvement Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Gordon Mohr Assignee: Sandy McArthur Priority: Minor GenericObjectPool has recently been made FIFO with respect to the managed pool objects -- however, it is still not FIFO with respect to threads requesting those objects. Specifically, because standard non-fair Java synchronization monitors are used, later threads may barge ahead of earlier threads that are already waiting for a pool object to become available. At its extreme, some threads can cycle objects through the pool many times while others wait interminable. Not every application needs FIFO fairness with respect to threads, and such fairness implies an overhead, so it need not be the default behavior, but it would be a valuable option where many threads are sharing a smaller number of pool objects. I can submit a FairGenericObjectPool which achieves thread-fairness; it only requires small changes to GenericObjectPool which allow some subclass overriding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Release FileUpload 1.1.1-RC1 (take two)
Vote passed with 5 binding +1s: Martin Cooper Niall Pemberton Henri Yandell Phil Steitz Rahul Akolkar I'll work on the release tomorrow. Hen On 6/3/06, Henri Yandell [EMAIL PROTECTED] wrote: Repeating this vote call because the last one got a bit lost in getting the site generation right, but I don't think an RC2 is required just for that. - I've prepared a release for FileUpload; http://people.apache.org/~bayard/fileupload/ [ ] +1, looks good. [ ] -1, nope, something needs fixing. Will keep the vote open until Wednesday. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons-collections events
On 6/6/06, Bryce L Nordgren [EMAIL PROTECTED] wrote: PS: I'd like to update my maven dependency for commons-collections to 3.2, but it's not on ibiblio yet (released May16th). When might this arrival be celebrated? The rsync between the ASF (and other places) and iBiblio is down since Codehaus had problems. No idea on the eta for it come back unfortunately. I've a hundred javadoc jars sitting and waiting :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-collections (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-collections has an issue affecting its community integration. This issue affects 221 projects, and has been outstanding for 75 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - JacORB : The free Java implementation of the OMG's CORBA standard. - anakia : Essentially an XML transformation tool, Anakia uses JDOM and... - ant-embed-optional : Java based build tool - ant-xdocs-proposal : Java based build tool - apache-ldapber-provider : Apache Directory Project - apacheds-core : Apache Directory Server - apacheds-main : Apache Directory Server - apollo : Apollo Project - asn1-ber : Apache ASN.1 Tools - authx-core : Apache Authentication and Authorization Framework - authx-example : Apache Authentication and Authorization Framework - authx-jdbc : Apache Authentication and Authorization Framework - authx-script : Apache Authentication and Authorization Framework - cargo : Cargo provides a Java API to manipulate Java Containers - checkstyle : Java style checker - commons-beanutils-bean-collections : Bean Utilities (Bean Collections) - commons-betwixt : Commons Betwixt Package - commons-chain : GoF Chain of Responsibility pattern - commons-collections : Collections - commons-collections-testframework : Jakarta commons - commons-configuration : Jakarta commons - commons-dbcp : Database Connection Pool - commons-digester : XML to Java Object Configuration - commons-digester-rss : Digester RSS Example - commons-graph : Jakarta commons dormant - sandbox components which are inact... - commons-javaflow : Commons Javaflow - commons-jci : Commons JCI - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-jelly-test : Commons Jelly - commons-jxpath : XPath traversal of JavaBeans - commons-messenger : A web based JMS framework - commons-modeler : Modeler MBeans - commons-pool : Object Pooling - commons-primitives : Provides a collection of types and utilities optimized for w... - commons-services : Basic Services Architecture - commons-validator : Validation Framework - commons-vfs : Jakarta commons - db-ddlutils : Easy-to-use component for working with Database Definition (... - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - db-torque : Persistence Layer - db-torque-gen : Persistence Layer - excalibur-component : Repository of reusable components. - excalibur-cornerstone-connection-api : Repository of reusable components. - excalibur-cornerstone-connection-impl : Repository of reusable components. - excalibur-cornerstone-datasources-impl : Repository of reusable components. - excalibur-cornerstone-scheduler-impl : Repository of reusable
[EMAIL PROTECTED]: Project commons-collections (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-collections has an issue affecting its community integration. This issue affects 221 projects, and has been outstanding for 75 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - JacORB : The free Java implementation of the OMG's CORBA standard. - anakia : Essentially an XML transformation tool, Anakia uses JDOM and... - ant-embed-optional : Java based build tool - ant-xdocs-proposal : Java based build tool - apache-ldapber-provider : Apache Directory Project - apacheds-core : Apache Directory Server - apacheds-main : Apache Directory Server - apollo : Apollo Project - asn1-ber : Apache ASN.1 Tools - authx-core : Apache Authentication and Authorization Framework - authx-example : Apache Authentication and Authorization Framework - authx-jdbc : Apache Authentication and Authorization Framework - authx-script : Apache Authentication and Authorization Framework - cargo : Cargo provides a Java API to manipulate Java Containers - checkstyle : Java style checker - commons-beanutils-bean-collections : Bean Utilities (Bean Collections) - commons-betwixt : Commons Betwixt Package - commons-chain : GoF Chain of Responsibility pattern - commons-collections : Collections - commons-collections-testframework : Jakarta commons - commons-configuration : Jakarta commons - commons-dbcp : Database Connection Pool - commons-digester : XML to Java Object Configuration - commons-digester-rss : Digester RSS Example - commons-graph : Jakarta commons dormant - sandbox components which are inact... - commons-javaflow : Commons Javaflow - commons-jci : Commons JCI - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-jelly-test : Commons Jelly - commons-jxpath : XPath traversal of JavaBeans - commons-messenger : A web based JMS framework - commons-modeler : Modeler MBeans - commons-pool : Object Pooling - commons-primitives : Provides a collection of types and utilities optimized for w... - commons-services : Basic Services Architecture - commons-validator : Validation Framework - commons-vfs : Jakarta commons - db-ddlutils : Easy-to-use component for working with Database Definition (... - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - db-torque : Persistence Layer - db-torque-gen : Persistence Layer - excalibur-component : Repository of reusable components. - excalibur-cornerstone-connection-api : Repository of reusable components. - excalibur-cornerstone-connection-impl : Repository of reusable components. - excalibur-cornerstone-datasources-impl : Repository of reusable components. - excalibur-cornerstone-scheduler-impl : Repository of reusable
RE: Commons-collections events
--- Noel J. Bergman [EMAIL PROTECTED] wrote: Bryce L Nordgren wrote: I'm in the process of stealing (possibly forking) the dormant project commons-events. I'd really rather keep it separate and refer to it by a dependency. Would there be any interest in reviving this project Yes. Yes. This is a basically good idea for a commons project, although the name could be better. is there any reason not to absorb commons-events back into commons-collections? Arguments for? Against? Commons-collections is too big. It was deliberately broken out to make both parts managable. This project did have quite an active life at first. Where it floundered was that there were IIRC three competing code implementations (not just designs). I believe that all are currently in SVN. To revive this, we would have to select one without excessive ego. I also believe that Michael Heuer may have released something related on java.net? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Commons Collections 3.2 released
--- Wendy Smoak [EMAIL PROTECTED] wrote: On 5/15/06, Stephen Colebourne wrote: The Commons Collections team is pleased to announce the release of commons-collections-3.2. I see it in dist/java-repository, but the jar for Collections 3.2 hasn't been added to ibiblio yet: According to Hen: The rsync between the ASF (and other places) and iBiblio is down since Codehaus had problems. No idea on the eta for it come back unfortunately. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Brett, any comments on this? cheers -- Torsten On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Brett, I did the test that you suggested. 1. Installed commons-lang 1.0.1 into my local repo with groupId=org.apache.commons mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/commons-lang-1.0.1.jar 2. Created Maven 2 projects a, b and c with the dependencies mentioned below. 3. Installed projects a and b into my local repo mvn install 4. packaged project c as a war mvn package The resulting war file includes both commons-lang-1.0.1.jar and commons-lang-2.1.jar which was what you thought would happen. So this is bad, I guess. Anyone who uses commons components transitively in a Maven 2 environment are likely to be bitten by this. They must keep the same groupId for all commons-lang dependencies, as an example, in the entire chain of transitive dependencies. I.e. they can't mix groupId=commons-lang and groupId=org.apache.commons. This can be a PITA since some of the dependencies are most likely out of the projects own control. What do you suggest we do? Should we wait with this relocation until a version of Maven 2 is released that can handle these kind of dependencies? -- Dennis Lundberg Brett Porter wrote: an extensive test should be something along the lines of: project A depends on commons-lang:commons-lang 2.1 project B depends on o.a.c:commons-lang 1.0 project C is a webapp that depends on A and B webapp should have only one commons-lang. You could do this with your own repository (and something completely artificial instead of commons-lang if it makes it easier). - Brett Dennis Lundberg wrote: Hi Brett Sorry, I misunderstood you regarding when to do the testing. So, no I haven't done the test, yet. Can you elaborate a bit more on what needs to be tested? Perhaps you know of an artifact that has been relocated that we can have a look at, to see how they have done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
AFAIK there is a way in maven repo to relocate dependencies, so that a POM for any commons can be published at commons-xxx groupId, that relocates to org.apache.commons groupId. Servletapi for example is now under javax.servlet http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom Using this, when maven2 search for the latest release of any commons it will look at the relocated one. Torsten Curdt a écrit : Brett, any comments on this? cheers -- Torsten On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Brett, I did the test that you suggested. 1. Installed commons-lang 1.0.1 into my local repo with groupId=org.apache.commons mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/commons-lang-1.0.1.jar 2. Created Maven 2 projects a, b and c with the dependencies mentioned below. 3. Installed projects a and b into my local repo mvn install 4. packaged project c as a war mvn package The resulting war file includes both commons-lang-1.0.1.jar and commons-lang-2.1.jar which was what you thought would happen. So this is bad, I guess. Anyone who uses commons components transitively in a Maven 2 environment are likely to be bitten by this. They must keep the same groupId for all commons-lang dependencies, as an example, in the entire chain of transitive dependencies. I.e. they can't mix groupId=commons-lang and groupId=org.apache.commons. This can be a PITA since some of the dependencies are most likely out of the projects own control. What do you suggest we do? Should we wait with this relocation until a version of Maven 2 is released that can handle these kind of dependencies? -- Dennis Lundberg Brett Porter wrote: an extensive test should be something along the lines of: project A depends on commons-lang:commons-lang 2.1 project B depends on o.a.c:commons-lang 1.0 project C is a webapp that depends on A and B webapp should have only one commons-lang. You could do this with your own repository (and something completely artificial instead of commons-lang if it makes it easier). - Brett Dennis Lundberg wrote: Hi Brett Sorry, I misunderstood you regarding when to do the testing. So, no I haven't done the test, yet. Can you elaborate a bit more on what needs to be tested? Perhaps you know of an artifact that has been relocated that we can have a look at, to see how they have done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Modeler] Resync and Release for commons-modeler
Yoav, No problem at all. Is there still another outstanding patch? i thought bill took care of it all. I'll check the bugzilla. and will start a vote next week for making a release. thanks, dims On 6/6/06, Yoav Shapira [EMAIL PROTECTED] wrote: Dims, Sorry for the late response. This is a very busy week for me, so I don't have much time. I can definitely handle syncing Tomcat to the latest stable modeler release, once such a release is available. It'd be nice if someone else can commit the modeler patch and cut that modeler release... Yoav On 6/3/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Bill, Yoav, Dennis, Could you please help with [1] and the resync with Tomcat's version of modeler? Once that is done, rbb and/or i can start a VOTE thread for a release that we need for Geronimo. Thanks, dims [1] http://issues.apache.org/jira/browse/MODELER-3 -- Davanum Srinivas : http://wso2.com/blogs/ -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] FTPS...
Hi... ...Steve Cohen, Rory Winston, and all the people that contribute to Jakarta Commons. I just known, that all are very busy with JIRA migration, and many proyects: personal, from work and other jakarta proyect. My question is, when jakarta commons net 1.5 or 2.0... with FTPS in his distint aproximation (incluiding Satoshi Ishigami patch), will be release... Again, i offer my help if yours need, for this proyect, or other. Thanks to all. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r412456 - /jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java
Author: bayard Date: Wed Jun 7 10:21:48 2006 New Revision: 412456 URL: http://svn.apache.org/viewvc?rev=412456view=rev Log: Modifying the test so it creates a new format object rather than reusing the static one. For some reason it gives the wrong response and it's hard to see why given that it works for other methods and JUnit is single threaded. This is discussed in CLI-40 Modified: jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java Modified: jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java?rev=412456r1=412455r2=412456view=diff == --- jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java (original) +++ jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java Wed Jun 7 10:21:48 2006 @@ -65,7 +65,10 @@ validator.validate(list); final Iterator i = list.iterator(); -assertEquals(2003-12-23, _MM_YY.format((Date) i.next())); +// CLI-40: For some reason, the _MM_YY object gets quite +// confused here and returns 2003-12-22. If we make a new one +// there is no problem. +assertEquals(2003-12-23, new SimpleDateFormat(-MM-dd).format((Date) i.next())); assertFalse(i.hasNext()); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r412457 - /jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/FileValidatorTest.java
Author: bayard
Date: Wed Jun 7 10:26:40 2006
New Revision: 412457
URL: http://svn.apache.org/viewvc?rev=412457view=rev
Log:
Applying patch in CLI-40 that avoids the test from failing sometimes on Windows
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/FileValidatorTest.java
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/FileValidatorTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/FileValidatorTest.java?rev=412457r1=412456r2=412457view=diff
==
---
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/FileValidatorTest.java
(original)
+++
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/FileValidatorTest.java
Wed Jun 7 10:26:40 2006
@@ -150,6 +150,10 @@
Process proc = Runtime.getRuntime().exec(
attrib.exe + + attr + src/test/data/.hidden.txt,
null, new File(.));
+proc.waitFor();
+} catch (InterruptedException e) {
+System.out.println(e.getMessage());
+e.printStackTrace();
} catch (IOException e) {
System.out.println(e.getMessage());
e.printStackTrace();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r412458 - in /jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2: option/ArgumentTest.java validation/DateValidatorTest.java
Author: bayard
Date: Wed Jun 7 10:27:11 2006
New Revision: 412458
URL: http://svn.apache.org/viewvc?rev=412458view=rev
Log:
Renaming _MM_YY to _MM_DD as that seems like a much more accurate name
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/option/ArgumentTest.java
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/option/ArgumentTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/option/ArgumentTest.java?rev=412458r1=412457r2=412458view=diff
==
---
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/option/ArgumentTest.java
(original)
+++
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/option/ArgumentTest.java
Wed Jun 7 10:27:11 2006
@@ -63,7 +63,7 @@
public static Argument buildDateLimitArgument() {
return new ArgumentImpl(limit, the last acceptable date, 0, 1,
'=', '\0',
-new
DateValidator(DateValidatorTest._MM_YY), null, null, 0);
+new
DateValidator(DateValidatorTest._MM_DD), null, null, 0);
}
public static Argument buildTargetsArgument() {
@@ -91,7 +91,7 @@
public void testNew() {
try {
new ArgumentImpl(limit, the last acceptable date, 10, 5, '=',
'\0',
- new DateValidator(DateValidatorTest._MM_YY),
null, null, 0);
+ new DateValidator(DateValidatorTest._MM_DD),
null, null, 0);
} catch (IllegalArgumentException e) {
assertEquals(resources.getMessage(Argument.minimum.exceeds.maximum),
e.getMessage());
}
@@ -99,7 +99,7 @@
{
ArgumentImpl arg =
new ArgumentImpl(null, the last acceptable date, 5, 5, '=',
'\0',
- new
DateValidator(DateValidatorTest._MM_YY), null, null, 0);
+ new
DateValidator(DateValidatorTest._MM_DD), null, null, 0);
assertEquals(wrong arg name, arg, arg.getPreferredName());
}
@@ -108,7 +108,7 @@
try {
new ArgumentImpl(null, the last acceptable date, 1, 1, '=',
'\0',
- new
DateValidator(DateValidatorTest._MM_YY), null, defaults, 0);
+ new
DateValidator(DateValidatorTest._MM_DD), null, defaults, 0);
} catch (IllegalArgumentException exp) {
assertEquals(resources.getMessage(Argument.too.few.defaults),
exp.getMessage());
}
@@ -120,7 +120,7 @@
defaults.add(2);
new ArgumentImpl(null, the last acceptable date, 1, 1, '=', '\0',
- new DateValidator(DateValidatorTest._MM_YY),
null, defaults, 0);
+ new DateValidator(DateValidatorTest._MM_DD),
null, defaults, 0);
} catch (IllegalArgumentException exp) {
assertEquals(resources.getMessage(Argument.too.many.defaults),
exp.getMessage());
}
@@ -367,7 +367,7 @@
option.validate(commandLine, option);
assertContentsEqual(Arrays.asList(new Object[] {
-
DateValidatorTest._MM_YY.parse(2004-01-01)
+
DateValidatorTest._MM_DD.parse(2004-01-01)
}), commandLine.getValues(option));
}
Modified:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java?rev=412458r1=412457r2=412458view=diff
==
---
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java
(original)
+++
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java
Wed Jun 7 10:27:11 2006
@@ -40,8 +40,8 @@
extends TestCase {
private static final ResourceHelper resources =
ResourceHelper.getResourceHelper();
public static final DateFormat D_M_YY = new SimpleDateFormat(d/M/yy);
-public static final DateFormat _MM_YY = new
SimpleDateFormat(-MM-dd);
-private List formats = Arrays.asList(new Object[] { D_M_YY, _MM_YY });
+public static final DateFormat _MM_DD = new
SimpleDateFormat(-MM-dd);
+private List formats = Arrays.asList(new Object[] { D_M_YY, _MM_DD });
public void testSingleFormatValidate()
throws InvalidArgumentException {
@@ -52,7 +52,7 @@
[jira] Resolved: (CLI-40) [cli] DateValidatorTest FileValidatorTest problems
[ http://issues.apache.org/jira/browse/CLI-40?page=all ] Henri Yandell resolved CLI-40: -- Resolution: Fixed I've also applied the patch for the File test. svn ci -m Applying patch in CLI-40 that avoids the test from failing sometimes on Windows src/test/org/vapache/commons/cli2/validation/FileValidatorTest.java Sending src/test/org/apache/commons/cli2/validation/FileValidatorTest.java Transmitting file data . Committed revision 412457. [cli] DateValidatorTest FileValidatorTest problems Key: CLI-40 URL: http://issues.apache.org/jira/browse/CLI-40 Project: Commons CLI Type: Bug Environment: Operating System: other Platform: Other Reporter: Jarek Gawor Attachments: patch3 The DateValidatorTest always fails with validation errors. It looks like the test itself might be invalid but since I don't know the history of the code I don't know which one is right. The FileValidatorTest tests might sometimes fail if executed for the very first time on Windows. There is a missing .waitFor() call to ensure the process finishes before the test is executed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r412466 - in /jakarta/commons/proper/cli/trunk/src/test/org/apache/commons: cli/bug/ cli/bug/BugCLI18Test.java cli2/bug/BugCLI18Test.java
Author: bayard
Date: Wed Jun 7 10:40:06 2006
New Revision: 412466
URL: http://svn.apache.org/viewvc?rev=412466view=rev
Log:
Adding Andrew's unit tests for CLI-18 - they pass for me too, so marking the
issue as Cannot Reproduce
Added:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli/bug/
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli/bug/BugCLI18Test.java
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/bug/BugCLI18Test.java
Added:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli/bug/BugCLI18Test.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli/bug/BugCLI18Test.java?rev=412466view=auto
==
---
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli/bug/BugCLI18Test.java
(added)
+++
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli/bug/BugCLI18Test.java
Wed Jun 7 10:40:06 2006
@@ -0,0 +1,42 @@
+/**
+ * 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.cli.bug;
+
+import org.apache.commons.cli.*;
+
+import java.io.PrintWriter;
+import java.io.StringWriter;
+
+import junit.framework.TestCase;
+
+/**
+ * http://issues.apache.org/jira/browse/CLI-18
+ */
+public class BugCLI18Test extends TestCase {
+
+ public void testCLI18() {
+Options options = new Options();
+options.addOption(new Option(a,aaa,false,aaa));
+options.addOption(new Option(null,bbb,false,bbb dksh fkshd fkhs
dkfhsdk fhskd hksdks dhfowehfsdhfkjshf skfhkshf sf jkshfk sfh skfh skf f));
+options.addOption(new Option(c,null,false,ccc));
+
+HelpFormatter formatter = new HelpFormatter();
+StringWriter out = new StringWriter();
+
+formatter.printHelp(new PrintWriter(out),80, foobar, dsfkfsh kdh hsd
hsdh fkshdf ksdh fskdh fsdh fkshfk sfdkjhskjh fkjh fkjsh khsdkj hfskdhf skjdfh
ksf khf s, options, 2, 2, blort j jgj j jg jhghjghjgjhgjhg jgjhgj jhg jhg hjg
jgjhghjg jhg hjg jhgjg jgjhghjg jg jgjhgjgjg jhg jhgjh + '\r' + '\n' +
rarrr, true);
+ }
+}
+
Added:
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/bug/BugCLI18Test.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/bug/BugCLI18Test.java?rev=412466view=auto
==
---
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/bug/BugCLI18Test.java
(added)
+++
jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/bug/BugCLI18Test.java
Wed Jun 7 10:40:06 2006
@@ -0,0 +1,59 @@
+/**
+ * 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.cli2.bug;
+
+import java.io.PrintWriter;
+import java.io.StringWriter;
+
+import org.apache.commons.cli2.Group;
+import org.apache.commons.cli2.Option;
+import org.apache.commons.cli2.builder.DefaultOptionBuilder;
+import org.apache.commons.cli2.builder.GroupBuilder;
+import org.apache.commons.cli2.util.HelpFormatter;
+
+import junit.framework.TestCase;
+
+/**
+ * http://issues.apache.org/jira/browse/CLI-18
+ */
+public class BugCLI18Test extends TestCase {
+
+ public BugCLI18Test() {
+super();
+ }
+
+
+ public void testBug() {
+Option a = new
DefaultOptionBuilder().withLongName(aaa).withShortName(a).withDescription(aaa).create();
+Option b = new
DefaultOptionBuilder().withLongName(bbb).withDescription( dksh fkshd
fkhs dkfhsdk fhskd hksdks dhfowehfsdhfkjshf skfhkshf sf jkshfk sfh skfh skf
f).create();
+Option c = new
DefaultOptionBuilder().withLongName(ccc).withShortName(c).withDescription(ccc).create();
+
+Group g = new
GroupBuilder().withOption(a).withOption(b).withOption(c).create();
+
+HelpFormatter
[jira] Resolved: (CLI-18) [cli] HelpFormatter.printHelp(String cmdLineSyntax, String header, Options options, String footer) throws exception if footer contains CR LF
[ http://issues.apache.org/jira/browse/CLI-18?page=all ] Henri Yandell resolved CLI-18: -- Resolution: Cannot Reproduce Unit tests applied. They pass for me too. Resolving this as Cannot Reproduce. Neboja, if you have the chance it would be very much appreciated if you could run Andrew's unit tests to see if they pass for you too. svn ci -m Adding Andrew's unit tests for CLI-18 - they pass for me too, so marking the issue as Cannot R eproduce Adding src/test/org/apache/commons/cli/bug Adding src/test/org/apache/commons/cli/bug/BugCLI18Test.java Adding src/test/org/apache/commons/cli2/bug/BugCLI18Test.java Transmitting file data .. Committed revision 412466. [cli] HelpFormatter.printHelp(String cmdLineSyntax, String header, Options options, String footer) throws exception if footer contains CR LF Key: CLI-18 URL: http://issues.apache.org/jira/browse/CLI-18 Project: Commons CLI Type: Bug Versions: 1.0 Final Environment: Operating System: All Platform: PC Reporter: Neboja Attachments: BugCLI18Test.java, BugCLI18Test.java If String footer contains windows new line, printHelp throws exception. If it contains only LF line endings, it works fine on Linux and Windows platforms. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
You are right. This would involve copying all the old group sutff to the new group and add the relocation poms. On 6/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote: AFAIK there is a way in maven repo to relocate dependencies, so that a POM for any commons can be published at commons-xxx groupId, that relocates to org.apache.commons groupId. Servletapi for example is now under javax.servlet http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom Using this, when maven2 search for the latest release of any commons it will look at the relocated one. Torsten Curdt a écrit : Brett, any comments on this? cheers -- Torsten On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Brett, I did the test that you suggested. 1. Installed commons-lang 1.0.1 into my local repo with groupId=org.apache.commons mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/commons-lang-1.0.1.jar 2. Created Maven 2 projects a, b and c with the dependencies mentioned below. 3. Installed projects a and b into my local repo mvn install 4. packaged project c as a war mvn package The resulting war file includes both commons-lang-1.0.1.jar and commons-lang-2.1.jar which was what you thought would happen. So this is bad, I guess. Anyone who uses commons components transitively in a Maven 2 environment are likely to be bitten by this. They must keep the same groupId for all commons-lang dependencies, as an example, in the entire chain of transitive dependencies. I.e. they can't mix groupId=commons-lang and groupId=org.apache.commons. This can be a PITA since some of the dependencies are most likely out of the projects own control. What do you suggest we do? Should we wait with this relocation until a version of Maven 2 is released that can handle these kind of dependencies? -- Dennis Lundberg Brett Porter wrote: an extensive test should be something along the lines of: project A depends on commons-lang:commons-lang 2.1 project B depends on o.a.c:commons-lang 1.0 project C is a webapp that depends on A and B webapp should have only one commons-lang. You could do this with your own repository (and something completely artificial instead of commons-lang if it makes it easier). - Brett Dennis Lundberg wrote: Hi Brett Sorry, I misunderstood you regarding when to do the testing. So, no I haven't done the test, yet. Can you elaborate a bit more on what needs to be tested? Perhaps you know of an artifact that has been relocated that we can have a look at, to see how they have done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) 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-jsl-test has an issue affecting its community integration. This issue affects 1 projects. 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-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 19 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.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-apache-resolver.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/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:78) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:71) [junit] at org.apache.commons.jelly.tags.jsl.StylesheetTag.doTag(StylesheetTag.java:124) [junit] Root cause [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-classes/org/apache/commons/jelly/jsl/suite.jelly:123:89: x:expr You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.ExprTag.doTag(ExprTag.java:46) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) 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-jsl-test has an issue affecting its community integration. This issue affects 1 projects. 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-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 19 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.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-apache-resolver.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/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:78) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:71) [junit] at org.apache.commons.jelly.tags.jsl.StylesheetTag.doTag(StylesheetTag.java:124) [junit] Root cause [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-classes/org/apache/commons/jelly/jsl/suite.jelly:123:89: x:expr You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.ExprTag.doTag(ExprTag.java:46) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at
[RESULT] [VOTE] commons karma for Jochen Wiedmann
i count: +1's (binding) robert burrell donkin Stephen Colebourne Yoav Shapira Davanum Srinivas with no other votes. if i have made any mistakes please post a correct. therefore the vote for jakarta karma for jochen has passed. - robert On Tue, 2006-05-23 at 23:31 +0100, robert burrell donkin wrote: Jochen Wiedmann ([EMAIL PROTECTED]) is a pmc'er over in web services land. Jochen would like commons karma (http://mail-archives.apache.org/mod_mbox/jakarta-general/200605.mbox/% [EMAIL PROTECTED]) to help work on file-upload. i trust that he'll discuss any plans with the file upload team but i think we can use his help. since this is a vote for karma, i think this can be executed a little quicker than normal. i'll tally votes not earlier than 2230 hours GMT on Thursday 25th of May. here's my +1 - robert --8 [ ] +1 grant Jochen Wiedmann commons karma [ ] +0 [ ] -0 [ ] -1 do not grant Jochen Wiedmann commons karma --- signature.asc Description: This is a digitally signed message part
[EMAIL PROTECTED]: Project commons-jelly-tags-define-test (in module commons-jelly) 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-define-test has an issue affecting its community integration. This issue affects 1 projects. 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-define-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build) Work ended in a state of : Failed Elapsed: 15 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:118) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208) [junit] at junit.framework.TestSuite.run(TestSuite.java:203) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:536) [junit] Jun 7, 2006 12:42:40 PM org.apache.commons.jelly.expression.xpath.XPathExpression evaluate [junit] SEVERE: Error constructing xpath [junit] org.jaxen.XPathSyntaxException: Node-set expected [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:131) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:156) [junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101) [junit] at org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78) [junit] at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-define-test (in module commons-jelly) 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-define-test has an issue affecting its community integration. This issue affects 1 projects. 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-define-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build) Work ended in a state of : Failed Elapsed: 15 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:118) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208) [junit] at junit.framework.TestSuite.run(TestSuite.java:203) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:536) [junit] Jun 7, 2006 12:42:40 PM org.apache.commons.jelly.expression.xpath.XPathExpression evaluate [junit] SEVERE: Error constructing xpath [junit] org.jaxen.XPathSyntaxException: Node-set expected [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:131) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:156) [junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101) [junit] at org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78) [junit] at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
So, in the simple example below, covering commons-lang, the procedure
would be:
1. Copy all files from /commons-lang/ to
/org/apache/commons/commons-lang/ in the *Apache* repo
2. Change the groupId of all the pom files under
/org/apache/commons/commons-lang/ so that they use the
org.apache.commons groupId
3. Add relocation elements to all pom files in /commons-lang/ pointing
them to org.apache.commons like this:
relocation
groupIdorg.apache.commons/groupId
/relocation
If I understand the model documentation correctly, we shouldn't have to
use artifactId or version since they are the same. But should we add a
message ?
4. Wait for a sync between the Apache repo and ibiblio, or is this
something that we need to ping someone about?
Is that correct so far?
When we later decide to release our first artifact using the new
groupId, should we also copy it to the repo using the groupId? My gut
feeling says no, but it's best to ask.
If I want to try this out locally first, can I test it in my local repo
${user.home}/.m2/repository/... or do I need to use a local httpd
serving as a central repo?
--
Dennis Lundberg
Carlos Sanchez wrote:
You are right. This would involve copying all the old group sutff to
the new group and add the relocation poms.
On 6/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
AFAIK there is a way in maven repo to relocate dependencies, so that a
POM for any commons can be published at commons-xxx groupId, that
relocates to org.apache.commons groupId.
Servletapi for example is now under javax.servlet
http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom
Using this, when maven2 search for the latest release of any commons
it will look at the relocated one.
Torsten Curdt a écrit :
Brett,
any comments on this?
cheers
--
Torsten
On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Brett, I did the test that you suggested.
1. Installed commons-lang 1.0.1 into my local repo with
groupId=org.apache.commons
mvn install:install-file -DgroupId=org.apache.commons
-DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar
-Dfile=/path/to/commons-lang-1.0.1.jar
2. Created Maven 2 projects a, b and c with the dependencies mentioned
below.
3. Installed projects a and b into my local repo
mvn install
4. packaged project c as a war
mvn package
The resulting war file includes both commons-lang-1.0.1.jar and
commons-lang-2.1.jar which was what you thought would happen.
So this is bad, I guess. Anyone who uses commons components
transitively
in a Maven 2 environment are likely to be bitten by this. They must
keep
the same groupId for all commons-lang dependencies, as an example, in
the entire chain of transitive dependencies. I.e. they can't mix
groupId=commons-lang and groupId=org.apache.commons. This can be a
PITA
since some of the dependencies are most likely out of the projects own
control.
What do you suggest we do? Should we wait with this relocation until a
version of Maven 2 is released that can handle these kind of
dependencies?
--
Dennis Lundberg
Brett Porter wrote:
an extensive test should be something along the lines of:
project A depends on commons-lang:commons-lang 2.1
project B depends on o.a.c:commons-lang 1.0
project C is a webapp that depends on A and B
webapp should have only one commons-lang.
You could do this with your own repository (and something completely
artificial instead of commons-lang if it makes it easier).
- Brett
Dennis Lundberg wrote:
Hi Brett
Sorry, I misunderstood you regarding when to do the testing. So,
no I
haven't done the test, yet. Can you elaborate a bit more on what
needs
to be tested? Perhaps you know of an artifact that has been
relocated
that we can have a look at, to see how they have done.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
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: [Modeler] Resync and Release for commons-modeler
Please make sure that you check Jira first. Commons recently moved from Bugzilla to Jira and I have resolved the issues in Jira only. -- Dennis Lundberg Davanum Srinivas wrote: Yoav, No problem at all. Is there still another outstanding patch? i thought bill took care of it all. I'll check the bugzilla. and will start a vote next week for making a release. thanks, dims On 6/6/06, Yoav Shapira [EMAIL PROTECTED] wrote: Dims, Sorry for the late response. This is a very busy week for me, so I don't have much time. I can definitely handle syncing Tomcat to the latest stable modeler release, once such a release is available. It'd be nice if someone else can commit the modeler patch and cut that modeler release... Yoav On 6/3/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Bill, Yoav, Dennis, Could you please help with [1] and the resync with Tomcat's version of modeler? Once that is done, rbb and/or i can start a VOTE thread for a release that we need for Geronimo. Thanks, dims [1] http://issues.apache.org/jira/browse/MODELER-3 -- Davanum Srinivas : http://wso2.com/blogs/ -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] commons karma for Jochen Wiedmann
Karma done. On 6/7/06, robert burrell donkin [EMAIL PROTECTED] wrote: i count: +1's (binding) robert burrell donkin Stephen Colebourne Yoav Shapira Davanum Srinivas with no other votes. if i have made any mistakes please post a correct. therefore the vote for jakarta karma for jochen has passed. - robert On Tue, 2006-05-23 at 23:31 +0100, robert burrell donkin wrote: Jochen Wiedmann ([EMAIL PROTECTED]) is a pmc'er over in web services land. Jochen would like commons karma (http://mail-archives.apache.org/mod_mbox/jakarta-general/200605.mbox/% [EMAIL PROTECTED]) to help work on file-upload. i trust that he'll discuss any plans with the file upload team but i think we can use his help. since this is a vote for karma, i think this can be executed a little quicker than normal. i'll tally votes not earlier than 2230 hours GMT on Thursday 25th of May. here's my +1 - robert --8 [ ] +1 grant Jochen Wiedmann commons karma [ ] +0 [ ] -0 [ ] -1 do not grant Jochen Wiedmann commons karma --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBEhy4E1TNOdbExPeIRAmD/AJ4/lXWXP1X3uZ9PBmqabD5ExG5uSACbBNXs DpjtlKOtAA88diHP3FpDU78= =ugwN -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) 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-html has an issue affecting its community integration. This issue affects 1 projects. 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-html : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/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-html-07062006.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) 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-html has an issue affecting its community integration. This issue affects 1 projects. 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-html : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/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-html-07062006.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] at
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Are you thinking about doing it in the m1 or m2 repo?
see below
On 6/7/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
So, in the simple example below, covering commons-lang, the procedure
would be:
1. Copy all files from /commons-lang/ to
/org/apache/commons/commons-lang/ in the *Apache* repo
2. Change the groupId of all the pom files under
/org/apache/commons/commons-lang/ so that they use the
org.apache.commons groupId
3. Add relocation elements to all pom files in /commons-lang/ pointing
them to org.apache.commons like this:
relocation
groupIdorg.apache.commons/groupId
/relocation
If I understand the model documentation correctly, we shouldn't have to
use artifactId or version since they are the same. But should we add a
message ?
I never did.
4. Wait for a sync between the Apache repo and ibiblio, or is this
something that we need to ping someone about?
m1 repo - wait
m2 repo - ping
Is that correct so far?
When we later decide to release our first artifact using the new
groupId, should we also copy it to the repo using the groupId? My gut
feeling says no, but it's best to ask.
no
If I want to try this out locally first, can I test it in my local repo
${user.home}/.m2/repository/... or do I need to use a local httpd
serving as a central repo?
local is ok
--
Dennis Lundberg
Carlos Sanchez wrote:
You are right. This would involve copying all the old group sutff to
the new group and add the relocation poms.
On 6/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
AFAIK there is a way in maven repo to relocate dependencies, so that a
POM for any commons can be published at commons-xxx groupId, that
relocates to org.apache.commons groupId.
Servletapi for example is now under javax.servlet
http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom
Using this, when maven2 search for the latest release of any commons
it will look at the relocated one.
Torsten Curdt a écrit :
Brett,
any comments on this?
cheers
--
Torsten
On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Brett, I did the test that you suggested.
1. Installed commons-lang 1.0.1 into my local repo with
groupId=org.apache.commons
mvn install:install-file -DgroupId=org.apache.commons
-DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar
-Dfile=/path/to/commons-lang-1.0.1.jar
2. Created Maven 2 projects a, b and c with the dependencies mentioned
below.
3. Installed projects a and b into my local repo
mvn install
4. packaged project c as a war
mvn package
The resulting war file includes both commons-lang-1.0.1.jar and
commons-lang-2.1.jar which was what you thought would happen.
So this is bad, I guess. Anyone who uses commons components
transitively
in a Maven 2 environment are likely to be bitten by this. They must
keep
the same groupId for all commons-lang dependencies, as an example, in
the entire chain of transitive dependencies. I.e. they can't mix
groupId=commons-lang and groupId=org.apache.commons. This can be a
PITA
since some of the dependencies are most likely out of the projects own
control.
What do you suggest we do? Should we wait with this relocation until a
version of Maven 2 is released that can handle these kind of
dependencies?
--
Dennis Lundberg
Brett Porter wrote:
an extensive test should be something along the lines of:
project A depends on commons-lang:commons-lang 2.1
project B depends on o.a.c:commons-lang 1.0
project C is a webapp that depends on A and B
webapp should have only one commons-lang.
You could do this with your own repository (and something completely
artificial instead of commons-lang if it makes it easier).
- Brett
Dennis Lundberg wrote:
Hi Brett
Sorry, I misunderstood you regarding when to do the testing. So,
no I
haven't done the test, yet. Can you elaborate a bit more on what
needs
to be tested? Perhaps you know of an artifact that has been
relocated
that we can have a look at, to see how they have done.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To
Collections-events
Commons-collections is too big. It was deliberately broken out to make both parts managable. This project did have quite an active life at first. Where it floundered was that there were IIRC three competing code implementations (not just designs). I believe that all are currently in SVN. To revive this, we would have to select one without excessive ego. I'm not sure I'm looking at the same package. I see 25 classes, 30 tops. There doesn't seem to be any overlap (e.g. two concepts coded in competing ways). And when it's compiled, the jar is 35k. (less than 10% of commons-collections, which weighs in at 500k--and commons-events depends on commons-collections to boot). I also believe that Michael Heuer may have released something related on java.net? Cool. I'll go looking for it too. Bryce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
Carlos Sanchez wrote:
Are you thinking about doing it in the m1 or m2 repo?
I really don't have a clue. Since I have not acted as release manager
for any component, I haven't really done my homework on what the
difference between the two is. I know about the M1 an M2 repos at
ibiblio, and that there is some sort of conversion between them, but
don't know what it looks like at the Apache end.
Do you have any suggestions on which is better?
see below
On 6/7/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
So, in the simple example below, covering commons-lang, the procedure
would be:
1. Copy all files from /commons-lang/ to
/org/apache/commons/commons-lang/ in the *Apache* repo
2. Change the groupId of all the pom files under
/org/apache/commons/commons-lang/ so that they use the
org.apache.commons groupId
3. Add relocation elements to all pom files in /commons-lang/ pointing
them to org.apache.commons like this:
relocation
groupIdorg.apache.commons/groupId
/relocation
If I understand the model documentation correctly, we shouldn't have to
use artifactId or version since they are the same. But should we add a
message ?
I never did.
4. Wait for a sync between the Apache repo and ibiblio, or is this
something that we need to ping someone about?
m1 repo - wait
m2 repo - ping
OK
Is that correct so far?
When we later decide to release our first artifact using the new
groupId, should we also copy it to the repo using the groupId? My gut
feeling says no, but it's best to ask.
no
OK
If I want to try this out locally first, can I test it in my local repo
${user.home}/.m2/repository/... or do I need to use a local httpd
serving as a central repo?
local is ok
Cool, I'll have a go at it, to see it I can get it right. It'll have to
wait until this weekend though.
--
Dennis Lundberg
Carlos Sanchez wrote:
You are right. This would involve copying all the old group sutff to
the new group and add the relocation poms.
On 6/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
AFAIK there is a way in maven repo to relocate dependencies, so
that a
POM for any commons can be published at commons-xxx groupId, that
relocates to org.apache.commons groupId.
Servletapi for example is now under javax.servlet
http://www.ibiblio.org/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom
Using this, when maven2 search for the latest release of any commons
it will look at the relocated one.
Torsten Curdt a écrit :
Brett,
any comments on this?
cheers
--
Torsten
On 6/6/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Brett, I did the test that you suggested.
1. Installed commons-lang 1.0.1 into my local repo with
groupId=org.apache.commons
mvn install:install-file -DgroupId=org.apache.commons
-DartifactId=commons-lang -Dversion=1.0.1 -Dpackaging=jar
-Dfile=/path/to/commons-lang-1.0.1.jar
2. Created Maven 2 projects a, b and c with the dependencies
mentioned
below.
3. Installed projects a and b into my local repo
mvn install
4. packaged project c as a war
mvn package
The resulting war file includes both commons-lang-1.0.1.jar and
commons-lang-2.1.jar which was what you thought would happen.
So this is bad, I guess. Anyone who uses commons components
transitively
in a Maven 2 environment are likely to be bitten by this. They must
keep
the same groupId for all commons-lang dependencies, as an
example, in
the entire chain of transitive dependencies. I.e. they can't mix
groupId=commons-lang and groupId=org.apache.commons. This can be a
PITA
since some of the dependencies are most likely out of the
projects own
control.
What do you suggest we do? Should we wait with this relocation
until a
version of Maven 2 is released that can handle these kind of
dependencies?
--
Dennis Lundberg
Brett Porter wrote:
an extensive test should be something along the lines of:
project A depends on commons-lang:commons-lang 2.1
project B depends on o.a.c:commons-lang 1.0
project C is a webapp that depends on A and B
webapp should have only one commons-lang.
You could do this with your own repository (and something
completely
artificial instead of commons-lang if it makes it easier).
- Brett
Dennis Lundberg wrote:
Hi Brett
Sorry, I misunderstood you regarding when to do the testing. So,
no I
haven't done the test, yet. Can you elaborate a bit more on what
needs
to be tested? Perhaps you know of an artifact that has been
relocated
that we can have a look at, to see how they have done.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is
[jira] Commented: (CLI-15) [cli] HelpFormatter does not handle groups properly
[ http://issues.apache.org/jira/browse/CLI-15?page=comments#action_12415201
]
David DIDIER commented on CLI-15:
-
It seems that it was not corrected. The code below:
Option a = new Option(a, aaa);
Option b = new Option(b, bbb);
Option c = new Option(c, ccc);
OptionGroup optionGroup = new OptionGroup();
optionGroup.addOption(a);
optionGroup.addOption(b);
Options options = new Options();
options.addOptionGroup(optionGroup);
options.addOption(c);
HelpFormatter formatter = new HelpFormatter();
formatter.printHelp(___, options, true);
prints:
usage: ___ [-b | -a][-c] [-a]
-a aaa
-b bbb
-c ccc
[cli] HelpFormatter does not handle groups properly
---
Key: CLI-15
URL: http://issues.apache.org/jira/browse/CLI-15
Project: Commons CLI
Type: Bug
Versions: 1.0 Final
Environment: Operating System: All
Platform: All
Reporter: Etienne Pelletier
Attachments: HelpFormatter.java, Option.java
The HelpFormatter repeats Options that have previously been printed with the
group.
The problem is in the else block where options not belonging to a group are
printed. The code gets executed if it does not belong to a group -OR- if the
group has already been printed.
if( group != null !list.contains(group)) {
// this gets executed when a new group is found
...
} else {
// this gets executed if the group is OR ISN'T null, and if group is in
list.
}
The else statement on line 267 should be as follows:
} else if (group == null) {
// This will make sure that options that have not been printed as part of a
group
// will not get printed again.
...
}
I believe this change fixes the problem.
Also, the append on line 264 should add an extra space after the ] to make
sure
that there will be a space between the ] and the next option.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed
Gump experts, Failures in these three tests are due, I think, to old jaxen, indeed jaxen 1.1-beta-4 is referenced in many places in http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.html and the other failing gump reports. Explanation for this is the gump metadata to be found at: http://svn.apache.org/repos/asf/gump/metadata/project/jakarta-commons-jelly.xml which indeed states explicitly jaxen 1.1-beta-8. Is this gump descriptor automatically generated ? Using a manually triggered process or every nights ? (it appears the first must be true since jaxen 1.1-beta-8 is in the project.xml since yesterday). I've tried: maven generate-gump -Dmaven.gump.svn.dir=commons/proper/jelly/trunk should I upload the result somewhere ? thanks paul development wrote: 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-html has an issue affecting its community integration. This issue affects 1 projects. 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-html : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/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-html-07062006.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-0706200 6.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at
Re: Collections-events
Bryce L Nordgren wrote: Commons-collections is too big. It was deliberately broken out to make both parts managable. This project did have quite an active life at first. Where it floundered was that there were IIRC three competing code implementations (not just designs). I believe that all are currently in SVN. To revive this, we would have to select one without excessive ego. I'm not sure I'm looking at the same package. I see 25 classes, 30 tops. There doesn't seem to be any overlap (e.g. two concepts coded in competing ways). See http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200306.mbox/[EMAIL PROTECTED] for some discussion. There will be more before this, and a little after. And when it's compiled, the jar is 35k. (less than 10% of commons-collections, which weighs in at 500k--and commons-events depends on commons-collections to boot). Yes its a small increase, but there seems to be a trend to favouring smaller jar files, particularly as they can be released more frequently. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r412592 - in /jakarta/commons/proper/io/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/io/LineIterator.java
Author: scolebourne
Date: Wed Jun 7 15:26:29 2006
New Revision: 412592
URL: http://svn.apache.org/viewvc?rev=412592view=rev
Log:
IO-80 - Make LineIterator implement Iterator
Modified:
jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java
Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt?rev=412592r1=412591r2=412592view=diff
==
--- jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Wed Jun 7 15:26:29 2006
@@ -30,6 +30,8 @@
Bug fixes from 1.2
--
+- LineIterator now implements Iterator
+ (It was always supposed to...)
Enhancements from 1.2
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java?rev=412592r1=412591r2=412592view=diff
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/LineIterator.java
Wed Jun 7 15:26:29 2006
@@ -18,6 +18,7 @@
import java.io.BufferedReader;
import java.io.IOException;
import java.io.Reader;
+import java.util.Iterator;
import java.util.NoSuchElementException;
/**
@@ -48,7 +49,7 @@
* @version $Id$
* @since Commons IO 1.2
*/
-public class LineIterator {
+public class LineIterator implements Iterator {
/** The reader that is being read. */
private final BufferedReader bufferedReader;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (IO-80) LineIterator should implement java.util.Iterator
[ http://issues.apache.org/jira/browse/IO-80?page=all ] Stephen Colebourne closed IO-80: Resolution: Fixed svn 412592 LineIterator should implement java.util.Iterator Key: IO-80 URL: http://issues.apache.org/jira/browse/IO-80 Project: Commons IO Type: Improvement Versions: 1.2 Final Reporter: Jörg Gottschling Priority: Minor Fix For: 1.3 I think the summary describes it all. I do not understand why this class does not implement Iterator. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r412593 - /jakarta/commons/proper/io/trunk/xdocs/index.xml
Author: scolebourne Date: Wed Jun 7 15:27:53 2006 New Revision: 412593 URL: http://svn.apache.org/viewvc?rev=412593view=rev Log: Switch to Jira Modified: jakarta/commons/proper/io/trunk/xdocs/index.xml Modified: jakarta/commons/proper/io/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/xdocs/index.xml?rev=412593r1=412592r2=412593view=diff == --- jakarta/commons/proper/io/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/io/trunk/xdocs/index.xml Wed Jun 7 15:27:53 2006 @@ -76,9 +76,7 @@ so prefix your email by [io]. /p p -Issues may be reported via a href=issue-tracking.htmlASF Bugzilla/a. -Please remember that Bugzilla is shared between all commons components, -so prefix your issue by [io]. +Issues may be reported via a href=issue-tracking.htmlASF Jira/a. /p /section !-- == -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r412596 - /jakarta/commons/proper/collections/trunk/xdocs/issue-tracking.xml
Author: scolebourne Date: Wed Jun 7 15:36:42 2006 New Revision: 412596 URL: http://svn.apache.org/viewvc?rev=412596view=rev Log: Fix spelling Modified: jakarta/commons/proper/collections/trunk/xdocs/issue-tracking.xml Modified: jakarta/commons/proper/collections/trunk/xdocs/issue-tracking.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/collections/trunk/xdocs/issue-tracking.xml?rev=412596r1=412595r2=412596view=diff == --- jakarta/commons/proper/collections/trunk/xdocs/issue-tracking.xml (original) +++ jakarta/commons/proper/collections/trunk/xdocs/issue-tracking.xml Wed Jun 7 15:36:42 2006 @@ -11,7 +11,7 @@ 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 iouage governing permissions and +See the License for the specific language governing permissions and limitations under the License. -- document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r412601 - in /jakarta/commons/proper/primitives/trunk/xdocs: index.xml issue-tracking.xml
Author: scolebourne Date: Wed Jun 7 15:56:04 2006 New Revision: 412601 URL: http://svn.apache.org/viewvc?rev=412601view=rev Log: Switch to Jira Removed: jakarta/commons/proper/primitives/trunk/xdocs/issue-tracking.xml Modified: jakarta/commons/proper/primitives/trunk/xdocs/index.xml Modified: jakarta/commons/proper/primitives/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/primitives/trunk/xdocs/index.xml?rev=412601r1=412600r2=412601view=diff == --- jakarta/commons/proper/primitives/trunk/xdocs/index.xml (original) +++ jakarta/commons/proper/primitives/trunk/xdocs/index.xml Wed Jun 7 15:56:04 2006 @@ -1,6 +1,6 @@ ?xml version=1.0? !-- - Copyright 2003-2005 The Apache Software Foundation + Copyright 2003-2006 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. @@ -82,17 +82,9 @@ so prefix your email by [primitives]. /p p -Issues may be reported via a href=issue-tracking.htmlASF Bugzilla/a. -Please remember that Bugzilla is shared between all commons components, -so prefix your issue by [primitives]. +Issues may be reported via a href=issue-tracking.htmlASF Jira/a. /p /section !-- == -- /body /document - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r412603 - /jakarta/commons/proper/primitives/trunk/xdocs/issue-tracking.xml
Author: scolebourne Date: Wed Jun 7 15:56:26 2006 New Revision: 412603 URL: http://svn.apache.org/viewvc?rev=412603view=rev Log: Switch to Jira Added: jakarta/commons/proper/primitives/trunk/xdocs/issue-tracking.xml (with props) Added: jakarta/commons/proper/primitives/trunk/xdocs/issue-tracking.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/primitives/trunk/xdocs/issue-tracking.xml?rev=412603view=auto == --- jakarta/commons/proper/primitives/trunk/xdocs/issue-tracking.xml (added) +++ jakarta/commons/proper/primitives/trunk/xdocs/issue-tracking.xml Wed Jun 7 15:56:26 2006 @@ -0,0 +1,64 @@ +?xml version=1.0? +!-- +Copyright 2005-2006 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. +-- +document + properties + titleIssue tracking/title + author email=commons-dev@jakarta.apache.orgCommons Documentation Team/author + /properties +body +!-- == -- +section name=Issue tracking +p + Commons Primitives uses a href=http://issues.apache.org/jira/browse/PRIMITIVES;ASF Jira/a for tracking issues. +/p +p + To use Jira you may need to a href=http://issues.apache.org/jira/secure/Signup!default.jspa;create an account/a + (if you have previously created/updated Commons issues using Bugzilla an account will have been automatically + created and you can use the a href=http://issues.apache.org/jira/secure/ForgotPassword!default.jspa;Forgot Password/a + page to get a new password). +/p +p + If you would like to report a bug, or raise an enhancement request with + Commons Primitives please do the following: + ol + lia href=http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=trueamp;pid=12310477amp;sorter/field=issuekeyamp;sorter/order=DESCamp;status=1amp;status=4;Search existing open bugs/a. + If you find your issue listed then please add a comment with your details./li + lia href=http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/;Search the mailing list archive/a. + You may find your issue or idea has already been discussed./li + lia href=http://issues.apache.org/jira/browse/PRIMITIVES;Submit a bug report or enhancement request/a./li + /ol +/p +p + Please also remember these points: + ul + lithe more information you provide, the better we can help you/li + litest cases are vital, particularly for any proposed enhancements/li + lithe developers of Commons Primitives are all unpaid volunteers/li + /ul +/p +p + You may also find these links useful: + ul + lia href=http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=trueamp;pid=12310477amp;sorter/field=issuekeyamp;sorter/order=DESCamp;status=1amp;status=4;All Open Primitives bugs/a/li + lia href=http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=trueamp;pid=12310477amp;sorter/field=issuekeyamp;sorter/order=DESCamp;status=5amp;status=6;All Resolved Primitives bugs/a/li + lia href=http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=trueamp;pid=12310477amp;sorter/field=issuekeyamp;sorter/order=DESC;All Primitives bugs/a/li + /ul +/p +/section +!-- == -- +/body +/document Propchange: jakarta/commons/proper/primitives/trunk/xdocs/issue-tracking.xml -- svn:eol-style = native - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[fileupload] hi,all,got a delete prob
hi,all i got a problem . our requirements is upload some jpg/gif to the server(images server). also,we maybe upload a file more than one time. we found , some times, all(radom) files of the folder (upload use in the server) are lost !! our version is 1.0 . i do not know whether it is the problem of fileupload component. I find this http://issues.apache.org/jira/browse/FILEUPLOAD-85 any secure way to delete the tempotery files? so does any one has solutions ? we are confuesed by the radom delete of the jpg/gif files. any suggestion is welcome. thank you all ! yours,biglaughing [free as freedom] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons-events passes tests...
My original checkout of commons-events failed two out of 316 tests packaged with it. It took a couple of hours, but here's the diagnosis: I was depending on commons-collections 3.1 and the test in commons-events was finding a bug in HashBag (actually AbstractMapBag) w.r.t. the return value of remove(). I updated the dependency to commons-collections-3.2 (installed manually in my maven repo) and the problem vanished. (I did have to fix some control logic in ObservableBag, but it was really cosmetic.) Note that even though the buggy return value was fixed, the unit tests for commons-collections (3.2) do not examine the return value of the remove() method. I don't know whether this is a bug or not. :) Now the patient looks fine!! Bryce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CHAIN-30) ServletSessionScopeMap always forces a Session to be Created
ServletSessionScopeMap always forces a Session to be Created Key: CHAIN-30 URL: http://issues.apache.org/jira/browse/CHAIN-30 Project: Commons Chain Type: Bug Versions: 1.0 Release Reporter: Niall Pemberton The current implementation of ServletSessionScopeMap always forces a Session to be created whenever getSessionScope() is called on ServletWebContext. This could be avoided and would be smarter if ServletSessionScopeMap was instantiated with the HttpServletRequest rather than the HttpSession - that way if no Session exists it could be lazily created only during write operations on the Map. Frameworks such as Struts check session scope for various attributes for each request processed - if it used this abstracted Map representaion of session scope it would mean a session is always created (if it doesn't already exist) whether its needed or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] hi,all,got a delete prob
On 6/7/06, biglaughing [EMAIL PROTECTED] wrote: hi,all i got a problem . our requirements is upload some jpg/gif to the server(images server). also,we maybe upload a file more than one time. we found , some times, all(radom) files of the folder (upload use in the server) are lost !! our version is 1.0 . The first thing you should do is upgrade to FileUpload 1.1. There were several changes in that release to the way in which uploaded files are cleaned up. That said, without seeing any code, or reading any explanation of how you are using FileUpload, it's a little hard to know what you're doing wrong... i do not know whether it is the problem of fileupload component. I find this http://issues.apache.org/jira/browse/FILEUPLOAD-85 That has to do with the exact manner in which files are deleted, not whether or not they are deleted. any secure way to delete the tempotery files? so does any one has solutions ? I thought your problem was that files are being deleted that you do not want deleted, right? What does that have to do with secure deletion? -- Martin Cooper we are confuesed by the radom delete of the jpg/gif files. any suggestion is welcome. thank you all ! yours,biglaughing [free as freedom] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] hi,all,got a delete prob
By the way, your questions are more appropriate for the User list than the Dev list. -- Martin Cooper On 6/7/06, Martin Cooper [EMAIL PROTECTED] wrote: On 6/7/06, biglaughing [EMAIL PROTECTED] wrote: hi,all i got a problem . our requirements is upload some jpg/gif to the server(images server). also,we maybe upload a file more than one time. we found , some times, all(radom) files of the folder (upload use in the server) are lost !! our version is 1.0 . The first thing you should do is upgrade to FileUpload 1.1. There were several changes in that release to the way in which uploaded files are cleaned up. That said, without seeing any code, or reading any explanation of how you are using FileUpload, it's a little hard to know what you're doing wrong... i do not know whether it is the problem of fileupload component. I find this http://issues.apache.org/jira/browse/FILEUPLOAD-85 That has to do with the exact manner in which files are deleted, not whether or not they are deleted. any secure way to delete the tempotery files? so does any one has solutions ? I thought your problem was that files are being deleted that you do not want deleted, right? What does that have to do with secure deletion? -- Martin Cooper we are confuesed by the radom delete of the jpg/gif files. any suggestion is welcome. thank you all ! yours,biglaughing [free as freedom] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) 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-jsl-test has an issue affecting its community integration. This issue affects 1 projects. 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-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 19 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.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-apache-resolver.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/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:78) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:71) [junit] at org.apache.commons.jelly.tags.jsl.StylesheetTag.doTag(StylesheetTag.java:124) [junit] Root cause [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-classes/org/apache/commons/jelly/jsl/suite.jelly:123:89: x:expr You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.ExprTag.doTag(ExprTag.java:46) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) 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-jsl-test has an issue affecting its community integration. This issue affects 1 projects. 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-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 19 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.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-apache-resolver.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/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:78) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:71) [junit] at org.apache.commons.jelly.tags.jsl.StylesheetTag.doTag(StylesheetTag.java:124) [junit] Root cause [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-classes/org/apache/commons/jelly/jsl/suite.jelly:123:89: x:expr You must define an attribute called 'select' for this tag. [junit] at org.apache.commons.jelly.tags.xml.ExprTag.doTag(ExprTag.java:46) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at
Re: [fileupload] hi,all,got a delete prob
Martin Cooper wrote:
On 6/7/06, biglaughing [EMAIL PROTECTED] wrote:
hi,all
i got a problem .
our requirements is upload some jpg/gif to the server(images server).
also,we maybe upload a file more than one time.
we found , some times, all(radom) files of the folder (upload use in the
server)
are lost !!
our version is 1.0 .
The first thing you should do is upgrade to FileUpload 1.1. There were
several changes in that release to the way in which uploaded files are
cleaned up.
I used FileUpload 1.0 . I am changing to 1.1 :)
That said, without seeing any code, or reading any explanation of how you
are using FileUpload, it's a little hard to know what you're doing
wrong...
My code is :
DiskFileUpload nDiskFileUpload = new DiskFileUpload();
nDiskFileUpload.setSizeMax(50*1024*1024);
nDiskFileUpload.setSizeThreshold(60*1024);
i use the java.io.tmp env ( /tmp ) to safe my temptory upload files .
List nFileItems = nDiskFileUpload.parseRequest(request);
Iterator nIterator1 = nFileItems.iterator();
while(nIterator1.hasNext()){
FileItem nFileItem1 = (FileItem)nIterator1.next();
if(!nFileItem1.isFormField()){
String strFieldName=nFileItem1.getFieldName();
if(!strFieldName.equals(UploadTemp)){
String strFileName=nFileItem1.getName();
String
strSaveAsName=nUploadImageFile.getSaveAsName(strFieldName,strFileName);
if(blnGetRepositoryPath){
nDiskFileUpload.setRepositoryPath(nUploadImageFile.getTempPath());
blnGetRepositoryPath=false;
}
if(!strSaveAsName.equals()){
File saveFile=new File(strSaveAsName);
nFileItem1.write(saveFile); //this is where i
save my files .
}
else{
System.out.println();
}
}
}
}
is there any problem with my codes ?
i do not know whether it is the problem of
fileupload component.
I find this
http://issues.apache.org/jira/browse/FILEUPLOAD-85
That has to do with the exact manner in which files are deleted, not
whether
or not they are deleted.
any secure way to delete the tempotery files? so does any one has
solutions ?
I thought your problem was that files are being deleted that you do
not want
deleted, right? What does that have to do with secure deletion?
images files uploaded to the server ...lost .
I guess whether is the reason of FileUpload1.0 ?
You know ,1.0 use
File f =new File(.)
f.deleteOnExit() ;
All the upload-temp files are registered to the JVM . Got any prob ?
Will the pointer mis-point to the files i wanna save and delete them
all ,when the server reboot.
I am really confused by the lost images files .
Will FileUpload 1.1 cause the same prob ?
I am not sure what is the point (delete files),so ..
any suggestion and guess is welcome !
--
Martin Cooper
Thanks you any way .
yours,biglaughing
[free as freedom]
we are confuesed by the radom delete of the jpg/gif files.
any suggestion is welcome.
thank you all !
yours,biglaughing
[free as freedom]
-
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: [fileupload] hi,all,got a delete prob
Martin Cooper wrote:
On 6/7/06, biglaughing [EMAIL PROTECTED] wrote:
hi,all
i got a problem .
our requirements is upload some jpg/gif to the server(images server).
also,we maybe upload a file more than one time.
we found , some times, all(radom) files of the folder (upload use in the
server)
are lost !!
our version is 1.0 .
The first thing you should do is upgrade to FileUpload 1.1. There were
several changes in that release to the way in which uploaded files are
cleaned up.
I used FileUpload 1.0 . I am changing to 1.1 :)
That said, without seeing any code, or reading any explanation of how you
are using FileUpload, it's a little hard to know what you're doing
wrong...
My code is :
DiskFileUpload nDiskFileUpload = new DiskFileUpload();
nDiskFileUpload.setSizeMax(50*1024*1024);
nDiskFileUpload.setSizeThreshold(60*1024);
i use the java.io.tmp env ( /tmp ) to safe my temptory upload files .
List nFileItems = nDiskFileUpload.parseRequest(request);
Iterator nIterator1 = nFileItems.iterator();
while(nIterator1.hasNext()){
FileItem nFileItem1 = (FileItem)nIterator1.next();
if(!nFileItem1.isFormField()){
String strFieldName=nFileItem1.getFieldName();
if(!strFieldName.equals(UploadTemp)){
String strFileName=nFileItem1.getName();
String
strSaveAsName=nUploadImageFile.getSaveAsName(strFieldName,strFileName);
if(blnGetRepositoryPath){
nDiskFileUpload.setRepositoryPath(nUploadImageFile.getTempPath());
blnGetRepositoryPath=false;
}
if(!strSaveAsName.equals()){
File saveFile=new File(strSaveAsName);
nFileItem1.write(saveFile); //this is where i
save my files .
}
else{
System.out.println();
}
}
}
}
is there any problem with my codes ?
i do not know whether it is the problem of
fileupload component.
I find this
http://issues.apache.org/jira/browse/FILEUPLOAD-85
That has to do with the exact manner in which files are deleted, not
whether
or not they are deleted.
any secure way to delete the tempotery files? so does any one has
solutions ?
I thought your problem was that files are being deleted that you do
not want
deleted, right? What does that have to do with secure deletion?
images files uploaded to the server ...lost .
I guess whether is the reason of FileUpload1.0 ?
You know ,1.0 use
File f =new File(.)
f.deleteOnExit() ;
All the upload-temp files are registered to the JVM . Got any prob ?
Will the pointer mis-point to the files i wanna save and delete them
all ,when the server reboot.
I am really confused by the lost images files .
Will FileUpload 1.1 cause the same prob ?
I am not sure what is the point (delete files),so ..
any suggestion and guess is welcome !
--
Martin Cooper
Thanks you any way .
yours,biglaughing
[free as freedom]
we are confuesed by the radom delete of the jpg/gif files.
any suggestion is welcome.
thank you all !
yours,biglaughing
[free as freedom]
-
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: [fileupload] hi,all,got a delete prob
On 6/7/06, biglaughing [EMAIL PROTECTED] wrote:
Martin Cooper wrote:
On 6/7/06, biglaughing [EMAIL PROTECTED] wrote:
hi,all
i got a problem .
our requirements is upload some jpg/gif to the server(images server).
also,we maybe upload a file more than one time.
we found , some times, all(radom) files of the folder (upload use in
the
server)
are lost !!
our version is 1.0 .
The first thing you should do is upgrade to FileUpload 1.1. There were
several changes in that release to the way in which uploaded files are
cleaned up.
I used FileUpload 1.0 . I am changing to 1.1 :)
That said, without seeing any code, or reading any explanation of how
you
are using FileUpload, it's a little hard to know what you're doing
wrong...
My code is :
DiskFileUpload nDiskFileUpload = new DiskFileUpload();
nDiskFileUpload.setSizeMax(50*1024*1024);
nDiskFileUpload.setSizeThreshold(60*1024);
i use the java.io.tmp env ( /tmp ) to safe my temptory upload files .
List nFileItems = nDiskFileUpload.parseRequest(request);
Iterator nIterator1 = nFileItems.iterator();
while(nIterator1.hasNext()){
FileItem nFileItem1 = (FileItem)nIterator1.next();
if(!nFileItem1.isFormField()){
String strFieldName=nFileItem1.getFieldName();
if(!strFieldName.equals(UploadTemp)){
String strFileName=nFileItem1.getName();
String
strSaveAsName=nUploadImageFile.getSaveAsName(strFieldName,strFileName);
Is this method call guaranteed to return a unique name, even if the same
parameters are passed more than once? If not, then you could be overwriting
files that were previously uploaded.
Also, does this method return a full path to where the file should be saved?
You are using the returned value with no additional directory specified when
you call FileItem.write() later in your code, so unless this method returns
the full path, write() will use whatever the current working directory
happens to be.
if(blnGetRepositoryPath){
nDiskFileUpload.setRepositoryPath(nUploadImageFile.getTempPath
());
This is too late. The repository path is part of the file item factory, and
the path for a file item is set at creation time. Calling
setRepositoryPath() here will do nothing at all, since the file items are
all created by the time parseRequest() completes.
blnGetRepositoryPath=false;
}
if(!strSaveAsName.equals()){
File saveFile=new File(strSaveAsName);
nFileItem1.write(saveFile); //this is where i
save my files .
}
else{
System.out.println();
}
}
}
}
is there any problem with my codes ?
i do not know whether it is the problem of
fileupload component.
I find this
http://issues.apache.org/jira/browse/FILEUPLOAD-85
That has to do with the exact manner in which files are deleted, not
whether
or not they are deleted.
any secure way to delete the tempotery files? so does any one has
solutions ?
I thought your problem was that files are being deleted that you do
not want
deleted, right? What does that have to do with secure deletion?
images files uploaded to the server ...lost .
I guess whether is the reason of FileUpload1.0 ?
But that has nothing to so with whether deletion is secure or not, does it?
It relates only to whether deletion happens at all.
You know ,1.0 use
File f =new File(.)
f.deleteOnExit() ;
All the upload-temp files are registered to the JVM . Got any prob ?
Yes, there are problems with that. That is why the deletion code was changed
for FileUpload 1.1.
--
Martin Cooper
Will the pointer mis-point to the files i wanna save and delete them
all ,when the server reboot.
I am really confused by the lost images files .
Will FileUpload 1.1 cause the same prob ?
I am not sure what is the point (delete files),so ..
any suggestion and guess is welcome !
--
Martin Cooper
Thanks you any way .
yours,biglaughing
[free as freedom]
we are confuesed by the radom delete of the jpg/gif files.
any suggestion is welcome.
thank you all !
yours,biglaughing
[free as freedom]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-define-test (in module commons-jelly) 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-define-test has an issue affecting its community integration. This issue affects 1 projects. 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-define-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build) Work ended in a state of : Failed Elapsed: 15 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:118) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208) [junit] at junit.framework.TestSuite.run(TestSuite.java:203) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:536) [junit] Jun 7, 2006 8:32:19 PM org.apache.commons.jelly.expression.xpath.XPathExpression evaluate [junit] SEVERE: Error constructing xpath [junit] org.jaxen.XPathSyntaxException: Node-set expected [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:131) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:156) [junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101) [junit] at org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78) [junit] at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-define-test (in module commons-jelly) 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-define-test has an issue affecting its community integration. This issue affects 1 projects. 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-define-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-define-test/gump_work/build_commons-jelly_commons-jelly-tags-define-test.html Work Name: build_commons-jelly_commons-jelly-tags-define-test (Type: Build) Work ended in a state of : Failed Elapsed: 15 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/define] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/dynabean/target/commons-jelly-tags-dynabean-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar - [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:118) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208) [junit] at junit.framework.TestSuite.run(TestSuite.java:203) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:536) [junit] Jun 7, 2006 8:32:19 PM org.apache.commons.jelly.expression.xpath.XPathExpression evaluate [junit] SEVERE: Error constructing xpath [junit] org.jaxen.XPathSyntaxException: Node-set expected [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:131) [junit] at org.jaxen.BaseXPath.init(BaseXPath.java:156) [junit] at org.jaxen.dom4j.Dom4jXPath.init(Dom4jXPath.java:101) [junit] at org.apache.commons.jelly.expression.xpath.XPathExpression.evaluate(XPathExpression.java:78) [junit] at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:256) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at
Re: [fileupload] hi,all,got a delete prob
Martin Cooper wrote:
On 6/7/06, biglaughing [EMAIL PROTECTED] wrote:
Martin Cooper wrote:
On 6/7/06, biglaughing [EMAIL PROTECTED] wrote:
hi,all
i got a problem .
our requirements is upload some jpg/gif to the server(images server).
also,we maybe upload a file more than one time.
we found , some times, all(radom) files of the folder (upload use in
the
server)
are lost !!
our version is 1.0 .
The first thing you should do is upgrade to FileUpload 1.1. There were
several changes in that release to the way in which uploaded files are
cleaned up.
I used FileUpload 1.0 . I am changing to 1.1 :)
That said, without seeing any code, or reading any explanation of how
you
are using FileUpload, it's a little hard to know what you're doing
wrong...
My code is :
DiskFileUpload nDiskFileUpload = new DiskFileUpload();
nDiskFileUpload.setSizeMax(50*1024*1024);
nDiskFileUpload.setSizeThreshold(60*1024);
i use the java.io.tmp env ( /tmp ) to safe my temptory upload files .
List nFileItems = nDiskFileUpload.parseRequest(request);
Iterator nIterator1 = nFileItems.iterator();
while(nIterator1.hasNext()){
FileItem nFileItem1 = (FileItem)nIterator1.next();
if(!nFileItem1.isFormField()){
String strFieldName=nFileItem1.getFieldName();
if(!strFieldName.equals(UploadTemp)){
String strFileName=nFileItem1.getName();
String
strSaveAsName=nUploadImageFile.getSaveAsName(strFieldName,strFileName);
Is this method call guaranteed to return a unique name, even if the same
parameters are passed more than once? If not, then you could be
overwriting
files that were previously uploaded.
Also, does this method return a full path to where the file should be
saved?
You are using the returned value with no additional directory
specified when
you call FileItem.write() later in your code, so unless this method
returns
the full path, write() will use whatever the current working directory
happens to be.
The return value is the absolute path .
And our system save it to the absolute path file.
if(blnGetRepositoryPath){
nDiskFileUpload.setRepositoryPath(nUploadImageFile.getTempPath
());
This is too late. The repository path is part of the file item
factory, and
the path for a file item is set at creation time. Calling
setRepositoryPath() here will do nothing at all, since the file items are
all created by the time parseRequest() completes.
This code does suck. I've find this .Thanks.
blnGetRepositoryPath=false;
}
if(!strSaveAsName.equals()){
File saveFile=new File(strSaveAsName);
nFileItem1.write(saveFile); //this is where i
save my files .
}
else{
System.out.println();
}
}
}
}
is there any problem with my codes ?
i do not know whether it is the problem of
fileupload component.
I find this
http://issues.apache.org/jira/browse/FILEUPLOAD-85
That has to do with the exact manner in which files are deleted, not
whether
or not they are deleted.
any secure way to delete the tempotery files? so does any one has
solutions ?
I thought your problem was that files are being deleted that you do
not want
deleted, right? What does that have to do with secure deletion?
images files uploaded to the server ...lost .
I guess whether is the reason of FileUpload1.0 ?
But that has nothing to so with whether deletion is secure or not,
does it?
It relates only to whether deletion happens at all.
You know ,1.0 use
File f =new File(.)
f.deleteOnExit() ;
All the upload-temp files are registered to the JVM . Got any prob ?
Yes, there are problems with that. That is why the deletion code was
changed
for FileUpload 1.1.
I will update to 1.1 ASAP.
Thank you very much .
btw,
any toturial about the PhantomReference ?
I do not know whether the 1.1 will cause the same prob
I am confused by the images lost .
--
Martin Cooper
Will the pointer mis-point to the files i wanna save and delete them
all ,when the server reboot.
I am really confused by the lost images files .
Will FileUpload 1.1 cause the same prob ?
I am not sure what is the point (delete files),so ..
any suggestion and guess is welcome !
--
Martin Cooper
Thanks you any way .
yours,biglaughing
[free as freedom]
we are confuesed by the radom delete of the jpg/gif files.
any suggestion is welcome.
thank you all !
yours,biglaughing
[free as freedom]
-
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
[EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) 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-html has an issue affecting its community integration. This issue affects 1 projects. 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-html : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/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-html-07062006.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) 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-html has an issue affecting its community integration. This issue affects 1 projects. 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-html : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/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-html-07062006.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/html] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You must define an attribute called 'test' for this tag. [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:54) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase: testMixedCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an ERROR [junit] file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] org.apache.commons.jelly.MissingAttributeException: file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:47:48: test:assert You must define an attribute called 'test' for this tag. [junit] at
Re: Collections-events
Bryce L Nordgren wrote: I also believe that Michael Heuer may have released something related on java.net? Cool. I'll go looking for it too. Sorry for chiming in late, my stuff is in cvs at java.net but was never released. I would be willing to help revive collections-events if there is interest. Even more so if it can happen with generics support. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project commons-jelly-tags-html (in module commons-jelly) failed
The metadata for Gump is stored in the Gump SVN repo. It ignores (or, rather overrides) whatever is in the project POM. The reason, of course, is that most of the time you want Gump to try and compile your project against the HEAD of it's dependancies, so you get a warning when somebody in another project changes something that breaks yours. To update the metadata, all you need do is: $ svn co https://svn.apache.org/repos/asf/gump/metadata $ cd metadata/project $ vi jakarta-commons-jelly.xml $ svn ci Paul Libbrecht [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Gump experts, Failures in these three tests are due, I think, to old jaxen, indeed jaxen 1.1-beta-4 is referenced in many places in http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/index.htmland the other failing gump reports. Explanation for this is the gumpmetadata to be found at: http://svn.apache.org/repos/asf/gump/metadata/project/jakarta-commons-jelly.xmlwhich indeed states explicitly jaxen 1.1-beta-8.Is this gump descriptor automatically generated ?Using a manually triggered process or every nights ? (it appears thefirst must be true since jaxen 1.1-beta-8 is in the project.xml sinceyesterday).I've tried: maven generate-gump -Dmaven.gump.svn.dir=commons/proper/jelly/trunkshould I upload the result somewhere ?thankspaul development wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For moreinformation please visit http://gump.apache.org/nagged.html, and/or contactthe folk at [EMAIL PROTECTED] Project commons-jelly-tags-html has an issue affecting its communityintegration. This issue affects 1 projects. The curr ent state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-html : Commons Jelly Full details are available at:http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/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-html-07062006.jar] identifier setto project name -DEBUG- Dependency on xml-xerces exists, no need to add for propertymaven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/project.xml -DEBUG- Maven project properties in:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ht ml/project.properties -INFO- Project Reports in:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed:http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-html/gump_work/build_commons-jelly_commons-jelly-tags-html.html Work Name: build_commons-jelly_commons-jelly-tags-html (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: maven --offline jar [Working Directory:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/html] CLASSPATH:/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-j elly-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/commons-jelly-tags-jsl-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-07062006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-07062006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-07062006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/jaxen-1.1-beta-4/jaxen-1.1-beta-4.jar:/usr/local/gump/packages/nekohtml-0.9.5/nekohtml.jar - [junit] atorg.apache.commons.jelly.tags.junit.Ca seTag$1.runTest(CaseTag.java:59) [junit] [junit] [junit] Testcase:testLowerCase(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused anERROR [junit]file:/x1/gump/public/workspace/commons-jelly/jelly-tags/html/target/test-classes/org/apache/commons/jelly/html/suite.jelly:40:48: test:assert You
