Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 85472 invoked from network); 2 Nov 2005 13:42:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Nov 2005 13:42:05 -0000 Received: (qmail 58736 invoked by uid 500); 2 Nov 2005 13:41:49 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 58676 invoked by uid 500); 2 Nov 2005 13:41:48 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 58663 invoked by uid 99); 2 Nov 2005 13:41:48 -0000 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Nov 2005 05:41:48 -0800 Received: by ajax.apache.org (Postfix, from userid 99) id 443DF5BA; Wed, 2 Nov 2005 14:41:27 +0100 (CET) From: bugzilla@apache.org To: commons-dev@jakarta.apache.org Subject: DO NOT REPLY [Bug 37152] - [configuration] Fake "resources" dependency kills Maven2 X-Bugzilla-Reason: AssignedTo Message-Id: <20051102134127.443DF5BA@ajax.apache.org> Date: Wed, 2 Nov 2005 14:41:27 +0100 (CET) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37152 ------- Additional Comments From oliver.heger@t-online.de 2005-11-02 14:41 ------- Here is another, more radical approach. I checked again the test cases that make use of this resources.jar and came to the following result: From configuration's point of view it does not matter whether a configuration file is loaded from a jar or elsewhere from the class path. In both cases it is simply dealt with a URL (which of course looks different). So what we test here is not in the first line our implementation, but the Java runtime's ability to handle different types of URLs transparently. The affected test cases do not contribute to the code coverage of our test suite. So IMHO we could simply remove these tests, thus getting rid of the faked dependency at all. Other opinions? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org