DO NOT REPLY [Bug 33764] New: - available type=dir always fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33764. 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=33764 Summary: available type=dir always fails Product: Ant Version: 1.6.2 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] available file=C:\\Program Files type=dir property=someProperty/ always fails. In fact, I am pretty sure it fails no matter what path you use. I tried C:\\WINDOWS and it fails too. I couldn't find a workaround. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Patch] modifiedselector, style, remove unused code, slightly more lazy DigestAlgorithm.getValue
- removed iterator code fromModifiedSelector - lazier DigestAlgorithm.getValue (includes JUnit test) - removed unncecessary nesting in EqualsComparator // // - Instantiate the interfaces - // String className = null; String pkg = org.apache.tools.ant.types.selectors.modifiedselector; what do these lines do in ModifiedSelector.configure? Eclipse says that they're never read, and as they're method variables, not class or instance variables (ie not public), I was very tempted to delete them, but I thought I'd better ask first in case they're present to support future functionality Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Patch] modifiedselector, style, remove unused code, slightly more lazy DigestAlgorithm.getValue (now with added source code -doh!)
- removed iterator code fromModifiedSelector
- lazier DigestAlgorithm.getValue (includes JUnit test)
- removed unncecessary nesting in EqualsComparator
//
// - Instantiate the interfaces -
//
String className = null;
String pkg =
org.apache.tools.ant.types.selectors.modifiedselector;
what do these lines do in ModifiedSelector.configure? Eclipse says that
they're never read, and as they're method variables, not class or
instance variables (ie not public), I was very tempted to delete them,
but I thought I'd better ask first in case they're present to support
future functionality
Kev
Index: DigestAlgorithm.java
===
RCS file:
/home/cvspublic/ant/src/main/org/apache/tools/ant/types/selectors/modifiedselector/DigestAlgorithm.java,v
retrieving revision 1.7
diff -u -r1.7 DigestAlgorithm.java
--- DigestAlgorithm.java10 Jul 2004 17:15:37 - 1.7
+++ DigestAlgorithm.java28 Feb 2005 03:46:53 -
@@ -1,5 +1,5 @@
/*
- * Copyright 2003-2004 The Apache Software Foundation
+ * Copyright 2003-2005 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.
@@ -20,11 +20,11 @@
import java.io.File;
import java.io.FileInputStream;
-import java.io.FileOutputStream;
import java.security.DigestInputStream;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.security.NoSuchProviderException;
+
import org.apache.tools.ant.BuildException;
@@ -78,7 +78,7 @@
/**
* Size of the read buffer to use.
*/
-private int readBufferSize = 8 * 1024;
+private static final int READ_BUFFER_SIZE = 8 * 1024;
// - Algorithm-Configuration -
@@ -146,22 +146,18 @@
* @returnThe value for that file
*/
// implementation adapted from ...taskdefs.Checksum, thanks to Magesh for
hint
-public String getValue(File file) {
-initMessageDigest();
-String checksum = null;
-try {
-if (!file.canRead()) {
-return null;
-}
-FileInputStream fis = null;
-FileOutputStream fos = null;
-byte[] buf = new byte[readBufferSize];
+public String getValue(final File file) {
+ String checksum = null;
+ if (file.canRead()) {
+ initMessageDigest();
+ FileInputStream fis = null;
+byte[] buf = new byte[READ_BUFFER_SIZE];
try {
-messageDigest.reset();
+ messageDigest.reset();
fis = new FileInputStream(file);
DigestInputStream dis = new DigestInputStream(fis,
messageDigest);
-while (dis.read(buf, 0, readBufferSize) != -1) {
+while (dis.read(buf, 0, READ_BUFFER_SIZE) != -1) {
// do nothing
}
dis.close();
@@ -178,13 +174,11 @@
}
checksum = checksumSb.toString();
} catch (Exception e) {
-return null;
+ //do nothing
}
-} catch (Exception e) {
-return null;
-}
-return checksum;
-}
+ }
+ return checksum;
+ }
/**
Index: EqualComparator.java
===
RCS file:
/home/cvspublic/ant/src/main/org/apache/tools/ant/types/selectors/modifiedselector/EqualComparator.java,v
retrieving revision 1.6
diff -u -r1.6 EqualComparator.java
--- EqualComparator.java9 Mar 2004 16:48:49 - 1.6
+++ EqualComparator.java28 Feb 2005 03:46:53 -
@@ -41,12 +41,10 @@
if (o1 == null) {
if (o2 == null) {
return 1;
-} else {
-return 0;
}
-} else {
-return (o1.equals(o2)) ? 0 : 1;
+return 0;
}
+return (o1.equals(o2)) ? 0 : 1;
}
/**
Index: ModifiedSelector.java
===
RCS file:
/home/cvspublic/ant/src/main/org/apache/tools/ant/types/selectors/modifiedselector/ModifiedSelector.java,v
retrieving revision 1.15
diff -u -r1.15 ModifiedSelector.java
--- ModifiedSelector.java 7 Jan 2005 15:16:54 - 1.15
+++ ModifiedSelector.java 28 Feb 2005 03:46:55 -
@@ -21,7 +21,6 @@
// Java
import java.util.Comparator;
import java.util.Vector;
-import java.util.Iterator;
import java.io.File;
// Ant
@@ -309,6 +308,7 @@
/** Bean-Constructor. */
public ModifiedSelector() {
+ //default
}
@@ -382,8 +382,8 @@
//
// - Set the main attributes, pattern '*' -
//
-
AW: [Patch] modifiedselector, style, remove unused code, slightly more lazy DigestAlgorithm.getValue (now with added source code -doh!)
- removed iterator code fromModifiedSelector Why you use the for-loop instead of iterator? - lazier DigestAlgorithm.getValue (includes JUnit test) - removed unncecessary nesting in EqualsComparator // // - Instantiate the interfaces - // String className = null; String pkg = org.apache.tools.ant.types.selectors.modifiedselector; what do these lines do in ModifiedSelector.configure? Eclipse says that they're never read, and as they're method variables, not class or instance variables (ie not public), I was very tempted to delete them, but I thought I'd better ask first in case they're present to support future functionality That came more from past functionality than for future one :) While developing the modified selector I started with reflection. And in earlier steps I had hardcoded classnames for the three interfaces as default. And so I could simply shorten the text to write. My ascii editor I used there couldn´t check for unneeded variables :) Jan
Re: AW: [Patch] modifiedselector, style, remove unused code, slightly more lazy DigestAlgorithm.getValue (now with added source code -doh!)
Why you use the for-loop instead of iterator?
1 iterator has to check underlying array bounds for every hasNext(), and
every next(), checking is slow, and in this case unecessary
2 iterator call to hasNext() each time around the loop - again we can
call size() once and cache the result, since we are never updating the
underlying structure, this won't change and the local var read is faster
than a method call.
3 iterator is a large object to create, an int is a small one
(bytecode is probably smaller, although I haven't checked this, I can
almost (99%) guarantee it)
4 remove calls to iterator, then we can remove the import :)
It's just an idiom I learnt from Effective Java or one of the books
like that, but the reasons above mean that I use it whenever I can, as
it does tend to speed up large loops, at the expense of only a very
slight obfuscation of the code. Some people use essentially the same
loop but move the size variable above the loop. That's ok, but it means
that the size variable has slightly larger scope than it requires,
although the effect is the same.
Also speaking of Iterators in general...
Iterators: Signs of Weakness in Object-Oriented Languages
http://citeseer.ist.psu.edu/55669.html (there's a PDF or PS file
downloadable from the link at the top)
I don't pretend to understand all the Lispness of this paper, but some
of the arguments against external iterators (the kind we have in Java)
are interesting. I did a little test last week comparing a normal
iterator/for loop, with a functional-style of programming, both in
Java. Speed was identical, but bytecode of the functional-style was
much smaller, there were less casts and less method calls. Anecdotal at
best, but try it yourself:
[I decided to call these things Closures, but they aren't quite, rather
more like Blocks, correct me if I'm getting my terms wrong]
public interface Closure {
Object execute(Object o);
}
import java.util.ArrayList;
import java.util.List;
public class ClosureUtils {
/**
* This method maps a function to a list of data
* and returns a new modified list.
* @param list the source list of data
* @param c the Closure to apply to the list
* @return the modified list
*/
public static List map(final List list, final Closure c) {
final int size = list.size();
List result = new ArrayList(size);
for (int i=0; isize; i++) {
result.add(c.execute(list.get(i)));
}
return result;
}
}
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Date;
import java.util.Iterator;
import java.util.List;
import junit.framework.TestCase;
public class ClosureUtilsTest extends TestCase {
List testList = Arrays.asList(new String[]{This, That, Other});
/*
* @see TestCase#setUp()
*/
protected void setUp() throws Exception {
super.setUp();
}
/*
* @see TestCase#tearDown()
*/
protected void tearDown() throws Exception {
super.tearDown();
}
public void testJ5() {
try {
Date start = new Date();
System.out.println(Start J5);
for (int i=0; i10; i++) {
List newList = new ArrayList();
for (Object o : testList) {
newList.add(((String)o).toUpperCase());
}
assertEquals(((String)newList.get(0)),
((String)testList.get(0)).toUpperCase());
}
System.out.println(End elapsed : [ +(new
Date().getTime()-start.getTime()));
} catch (Exception e) {
e.printStackTrace();
fail();
}
}
public void testOld() {
try {
Date start = new Date();
System.out.println(Start old);
for (int i=0; i10; i++) {
List newList = new ArrayList();
for (Iterator it = testList.iterator(); it.hasNext();) {
newList.add(((String)it.next()).toUpperCase());
}
assertEquals(((String)newList.get(0)),
((String)testList.get(0)).toUpperCase());
}
System.out.println(End elapsed : [ +(new
Date().getTime()-start.getTime()));
} catch (Exception e) {
e.printStackTrace();
fail();
}
}
public void testMap() {
try {
Date start = new Date();
System.out.println(Start closure);
for (int i=0; i10; i++) {
List newList = ClosureUtils.map(testList, new Closure() {
public Object execute(Object o) {
return ((String)o).toUpperCase();
}
}
);
assertEquals(((String)newList.get(0)),
((String)testList.get(0)).toUpperCase());
}
System.out.println(End elapsed : [ +(new
Date().getTime()-start.getTime()));
} catch
[Patch] condition, minor style, removed extra lines, slight javadoc tweak
- unnecessary nesting (if/else with early return)
- CODE - code javadoc
- extra lines removed
Index: Http.java
===
RCS file:
/home/cvspublic/ant/src/main/org/apache/tools/ant/taskdefs/condition/Http.java,v
retrieving revision 1.13
diff -u -r1.13 Http.java
--- Http.java 9 Mar 2004 16:48:13 - 1.13
+++ Http.java 28 Feb 2005 08:41:16 -
@@ -36,7 +36,6 @@
/**
* Set the url attribute
- *
* @param url the url of the request
*/
public void setUrl(String url) {
@@ -47,7 +46,6 @@
/**
* Set the errorsBeginAt attribute
- *
* @param errorsBeginAt number at which errors begin at, default is
* 400
*/
@@ -75,9 +73,8 @@
Project.MSG_VERBOSE);
if (code 0 code errorsBeginAt) {
return true;
-} else {
-return false;
-}
+}
+return false;
}
} catch (java.io.IOException e) {
return false;
@@ -87,4 +84,4 @@
}
return true;
}
-}
+}
\ No newline at end of file
Index: IsSigned.java
===
RCS file:
/home/cvspublic/ant/src/main/org/apache/tools/ant/taskdefs/condition/IsSigned.java,v
retrieving revision 1.3
diff -u -r1.3 IsSigned.java
--- IsSigned.java 23 Nov 2004 10:40:14 - 1.3
+++ IsSigned.java 28 Feb 2005 08:41:16 -
@@ -16,14 +16,15 @@
*/
package org.apache.tools.ant.taskdefs.condition;
-import org.apache.tools.ant.BuildException;
-import org.apache.tools.ant.Project;
-import org.apache.tools.ant.types.DataType;
import java.io.File;
import java.io.IOException;
+import java.util.Enumeration;
import java.util.zip.ZipEntry;
import java.util.zip.ZipFile;
-import java.util.Enumeration;
+
+import org.apache.tools.ant.BuildException;
+import org.apache.tools.ant.Project;
+import org.apache.tools.ant.types.DataType;
/**
* Checks whether a jarfile is signed: if the name of the
@@ -37,12 +38,11 @@
private static final String SIG_END = .SF;
private String name;
-private File file;
+private File file;
/**
* The jarfile that is to be tested for the presence
* of a signature.
- *
* @param file jarfile to be tested.
*/
public void setFile(File file) {
@@ -51,7 +51,6 @@
/**
* The signature name to check jarfile for.
- *
* @param name signature to look for.
*/
public void setName(String name) {
@@ -59,8 +58,8 @@
}
/**
- * Returns CODEtrue/code if the file exists and is signed with
- * the signature specified, or, if CODEname/code wasn't
+ * Returns codetrue/code if the file exists and is signed with
+ * the signature specified, or, if codename/code wasn't
* specified, if the file contains a signature.
* @return true if the file is signed.
*/
@@ -79,20 +78,19 @@
}
}
return false;
-} else {
-boolean shortSig = jarFile.getEntry(SIG_START
-+ name.toUpperCase()
-+ SIG_END) != null;
-boolean longSig = false;
-if (name.length() 8) {
-longSig =
-jarFile.getEntry(SIG_START
- + name.substring(0, 8).toUpperCase()
- + SIG_END) != null;
-}
-
-return shortSig || longSig;
+}
+boolean shortSig = jarFile.getEntry(SIG_START
+ + name.toUpperCase()
+ + SIG_END) != null;
+boolean longSig = false;
+if (name.length() 8) {
+ longSig =
+ jarFile.getEntry(SIG_START
+ + name.substring(0, 8).toUpperCase()
+ + SIG_END) != null;
}
+
+return shortSig || longSig;
} finally {
if (jarFile != null) {
try {
@@ -105,8 +103,8 @@
}
/**
- * Returns CODEtrue/code if the file exists and is signed with
- * the signature specified, or, if CODEname/code wasn't
+ * Returns codetrue/code if the file exists and is signed with
+ * the signature specified, or, if codename/code wasn't
* specified, if the file contains a signature.
* @return true if the file is signed.
*/
@@ -134,4 +132,4 @@
}
return r;
}
-}
+}
\ No newline at end of file
Index: Os.java
===
RCS file:
DO NOT REPLY [Bug 33718] - No Authentication possible by a given keyfile
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33718. 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=33718 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 11:27 --- The problem here is that the scp task insists on having a passphrase when using key authentication, but it is quite possible to have a key without a passphrase! You can trick the task by specifying a passphrase that consists of a single space... Perhaps the passphrase property should be optional? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33718] - No Authentication possible by a given keyfile
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33718. 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=33718 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33764] - available type=dir always fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33764. 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=33764 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 11:34 --- Type using: available file=C:\Program Files type=dir property=someProperty/ -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: [Patch] modifiedselector, style, remove unused code, slightly more lazy DigestAlgorithm.getValue (now with added source code -doh!)
Just one comment on your ClosureUtils.map() method.
Although this code may be very good for ArrayList, I think
it will behave quite bad for LinkList arguments where
the cost of List.get(i) is quite expensive.
Maybe you should provide for that if you want this as a general
utility pattern.
Jose Alberto
-Original Message-
From: Kev Jackson [mailto:[EMAIL PROTECTED]
Sent: 28 February 2005 07:54
To: Ant Developers List
Subject: Re: AW: [Patch] modifiedselector, style, remove
unused code, slightly more lazy DigestAlgorithm.getValue (now
with added source code -doh!)
Why you use the for-loop instead of iterator?
1 iterator has to check underlying array bounds for every
hasNext(), and
every next(), checking is slow, and in this case unecessary
2 iterator call to hasNext() each time around the loop - again we can
call size() once and cache the result, since we are never
updating the
underlying structure, this won't change and the local var
read is faster
than a method call.
3 iterator is a large object to create, an int is a small one
(bytecode is probably smaller, although I haven't checked this, I can
almost (99%) guarantee it)
4 remove calls to iterator, then we can remove the import :)
It's just an idiom I learnt from Effective Java or one of the books
like that, but the reasons above mean that I use it whenever
I can, as
it does tend to speed up large loops, at the expense of only a very
slight obfuscation of the code. Some people use essentially the same
loop but move the size variable above the loop. That's ok,
but it means
that the size variable has slightly larger scope than it requires,
although the effect is the same.
Also speaking of Iterators in general...
Iterators: Signs of Weakness in Object-Oriented Languages
http://citeseer.ist.psu.edu/55669.html (there's a PDF or PS file
downloadable from the link at the top)
I don't pretend to understand all the Lispness of this paper,
but some
of the arguments against external iterators (the kind we have
in Java)
are interesting. I did a little test last week comparing a normal
iterator/for loop, with a functional-style of programming, both in
Java. Speed was identical, but bytecode of the functional-style was
much smaller, there were less casts and less method calls.
Anecdotal at
best, but try it yourself:
[I decided to call these things Closures, but they aren't
quite, rather
more like Blocks, correct me if I'm getting my terms wrong]
public interface Closure {
Object execute(Object o);
}
import java.util.ArrayList;
import java.util.List;
public class ClosureUtils {
/**
* This method maps a function to a list of data
* and returns a new modified list.
* @param list the source list of data
* @param c the Closure to apply to the list
* @return the modified list
*/
public static List map(final List list, final Closure c) {
final int size = list.size();
List result = new ArrayList(size);
for (int i=0; isize; i++) {
result.add(c.execute(list.get(i)));
}
return result;
}
}
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Date;
import java.util.Iterator;
import java.util.List;
import junit.framework.TestCase;
public class ClosureUtilsTest extends TestCase {
List testList = Arrays.asList(new String[]{This,
That, Other});
/*
* @see TestCase#setUp()
*/
protected void setUp() throws Exception {
super.setUp();
}
/*
* @see TestCase#tearDown()
*/
protected void tearDown() throws Exception {
super.tearDown();
}
public void testJ5() {
try {
Date start = new Date();
System.out.println(Start J5);
for (int i=0; i10; i++) {
List newList = new ArrayList();
for (Object o : testList) {
newList.add(((String)o).toUpperCase());
}
assertEquals(((String)newList.get(0)),
((String)testList.get(0)).toUpperCase());
}
System.out.println(End elapsed : [ +(new
Date().getTime()-start.getTime()));
} catch (Exception e) {
e.printStackTrace();
fail();
}
}
public void testOld() {
try {
Date start = new Date();
System.out.println(Start old);
for (int i=0; i10; i++) {
List newList = new ArrayList();
for (Iterator it = testList.iterator();
it.hasNext();) {
newList.add(((String)it.next()).toUpperCase());
}
assertEquals(((String)newList.get(0)),
DO NOT REPLY [Bug 20128] - vssget command label problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=20128. 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=20128 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 11:43 --- Created an attachment (id=14373) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14373action=view) JUnit testcase I tried to replicate this behaviour with a JUnit testcase. I can't. If I getVersionDateLabel I actually get the expected result (JUnit goes green). If this helps to prove that this is fixed in the current Ant HEAD, then this one can be closed -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Massively OT, 'Closures in Java' [was Re: AW: [Patch] modifiedselector, style, remove unused code, slightly more lazy DigestAlgorithm.getValue (now with added source code -doh!)]
Jose Alberto Fernandez wrote: Just one comment on your ClosureUtils.map() method. Although this code may be very good for ArrayList, I think it will behave quite bad for LinkList arguments where the cost of List.get(i) is quite expensive. When I read this, I thought Doh! you're right none-sequential List access is expensive, but I just rewrote the tests using a LinkedList and the time is identical. Maybe it's because the ClosureUtils requires a List interface not an ArrayList object, and as such it treats everything as simply something that implements List and uses the lowest common denominator, or maybe it's because my test data is trivial [shrug]. Still interesting code-doodle anyway. Thanks for the feedback ;) Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Massively OT, 'Closures in Java' [was Re: AW: [Patch] modifiedselector, style, remove unused code, slightly more lazy DigestAlgorithm.getValue (now with added source code -doh!)]
AFAIU, LinkedList.get(N) requires traversing the list to position N on every call [O(n^2)], so usage of an iteratoe is much cheaper on this case as there is no array behind the scenes. Jose Alberto -Original Message- From: Kev Jackson [mailto:[EMAIL PROTECTED] Sent: 28 February 2005 11:03 To: Ant Developers List Subject: Massively OT, 'Closures in Java' [was Re: AW: [Patch] modifiedselector, style, remove unused code, slightly more lazy DigestAlgorithm.getValue (now with added source code -doh!)] Jose Alberto Fernandez wrote: Just one comment on your ClosureUtils.map() method. Although this code may be very good for ArrayList, I think it will behave quite bad for LinkList arguments where the cost of List.get(i) is quite expensive. When I read this, I thought Doh! you're right none-sequential List access is expensive, but I just rewrote the tests using a LinkedList and the time is identical. Maybe it's because the ClosureUtils requires a List interface not an ArrayList object, and as such it treats everything as simply something that implements List and uses the lowest common denominator, or maybe it's because my test data is trivial [shrug]. Still interesting code-doodle anyway. Thanks for the feedback ;) Kev - 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]
[GUMP@brutus]: Project test-ant-no-xerces (in module ant) 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 test-ant-no-xerces has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 7 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - test-ant-no-xerces : Java based build tool Full details are available at: http://brutus.apache.org/gump/public/ant/test-ant-no-xerces/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org/gump/public/ant/test-ant-no-xerces/gump_work/build_ant_test-ant-no-xerces.html Work Name: build_ant_test-ant-no-xerces (Type: Build) Work ended in a state of : Failed Elapsed: 7 mins 13 secs Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtest.haltonfailure=false -Dant.home=/usr/local/gump/public/workspace/ant/dist run-tests [Working Directory: /usr/local/gump/public/workspace/ant] CLASSPATH:
Re: Massively OT, 'Closures in Java' [was Re: AW: [Patch] modifiedselector, style, remove unused code, slightly more lazy DigestAlgorithm.getValue (now with added source code -doh!)]
Jose Alberto Fernandez wrote: AFAIU, LinkedList.get(N) requires traversing the list to position N on every call [O(n^2)], so usage of an iteratoe is much cheaper on this case as there is no array behind the scenes. Jose Alberto I've just worked out why it's ok to do it this way (with respect to my particular use-case). Basically I *want* to traverse the entire list, I'm not trying to pick out any particular position in the list (yes truly expensive using LinkedList.get(i)). In my method I simply call get(i) from 0..List.size(): from docs quoteOperations that index into the list will traverse the list from the begining or the end, whichever is closer to the specified index./quote So as I'm asking for position 0, the traversal starts at the head of the list, then I simply walk the list with the loop calling get(i), which also happens to be the next element in the list from where the list cursor currently is (ListIterator interface docs). Serendipity I suppose, but my usage is the most efficient for LinkedLists and also happens to be performant with ArrayLists, to do the particular traversal that I'm doing. Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Massively OT, 'Closures in Java' [was Re: AW: [Patch] modifiedselector, style, remove unused code, slightly more lazy DigestAlgorithm.getValue (now with added source code -doh!)]
I do not think so, from LinkedList implementation:
/**
* Return the indexed entry.
*/
private Entry entry(int index) {
if (index 0 || index = size)
throw new IndexOutOfBoundsException(Index: +index+
, Size: +size);
Entry e = header;
if (index size/2) {
for (int i = 0; i = index; i++)
e = e.next;
} else {
for (int i = size; i index; i--)
e = e.previous;
}
return e;
}
It will iterate on every call.
Enough of this, as I think it is becoming a little out of subject for
the ANT list :-)
Jose Alberto
-Original Message-
From: Kev Jackson [mailto:[EMAIL PROTECTED]
Sent: 28 February 2005 11:19
To: Ant Developers List
Subject: Re: Massively OT, 'Closures in Java' [was Re: AW:
[Patch] modifiedselector, style, remove unused code, slightly
more lazy DigestAlgorithm.getValue (now with added source code -doh!)]
Jose Alberto Fernandez wrote:
AFAIU, LinkedList.get(N) requires traversing the list to
position N on
every call [O(n^2)], so usage of an iteratoe is much cheaper on this
case as there is no array behind the scenes.
Jose Alberto
I've just worked out why it's ok to do it this way (with
respect to my
particular use-case). Basically I *want* to traverse the
entire list,
I'm not trying to pick out any particular position in the list (yes
truly expensive using LinkedList.get(i)). In my method I simply call
get(i) from 0..List.size():
from docs
quoteOperations that index into the list will traverse the
list from
the begining or the end, whichever is closer to the specified
index./quote
So as I'm asking for position 0, the traversal starts at the
head of the
list, then I simply walk the list with the loop calling get(i), which
also happens to be the next element in the list from where the list
cursor currently is (ListIterator interface docs). Serendipity I
suppose, but my usage is the most efficient for LinkedLists and also
happens to be performant with ArrayLists, to do the
particular traversal
that I'm doing.
Kev
-
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: Massively OT, 'Closures in Java' [was Re: AW: [Patch] modifiedselector, style, remove unused code, slightly more lazy DigestAlgorithm.getValue (now with added source code -doh!)]
If you want to iterate through a List that has an unspecified
implementation (at the point of iteration) always use an iterator; this
is the only way to implement performant code without making assumptions
about the implementation of the list.
Phil :n.
On Mon, 2005-02-28 at 11:30, Jose Alberto Fernandez wrote:
I do not think so, from LinkedList implementation:
/**
* Return the indexed entry.
*/
private Entry entry(int index) {
if (index 0 || index = size)
throw new IndexOutOfBoundsException(Index: +index+
, Size: +size);
Entry e = header;
if (index size/2) {
for (int i = 0; i = index; i++)
e = e.next;
} else {
for (int i = size; i index; i--)
e = e.previous;
}
return e;
}
It will iterate on every call.
Enough of this, as I think it is becoming a little out of subject for
the ANT list :-)
Jose Alberto
-Original Message-
From: Kev Jackson [mailto:[EMAIL PROTECTED]
Sent: 28 February 2005 11:19
To: Ant Developers List
Subject: Re: Massively OT, 'Closures in Java' [was Re: AW:
[Patch] modifiedselector, style, remove unused code, slightly
more lazy DigestAlgorithm.getValue (now with added source code -doh!)]
Jose Alberto Fernandez wrote:
AFAIU, LinkedList.get(N) requires traversing the list to
position N on
every call [O(n^2)], so usage of an iteratoe is much cheaper on this
case as there is no array behind the scenes.
Jose Alberto
I've just worked out why it's ok to do it this way (with
respect to my
particular use-case). Basically I *want* to traverse the
entire list,
I'm not trying to pick out any particular position in the list (yes
truly expensive using LinkedList.get(i)). In my method I simply call
get(i) from 0..List.size():
from docs
quoteOperations that index into the list will traverse the
list from
the begining or the end, whichever is closer to the specified
index./quote
So as I'm asking for position 0, the traversal starts at the
head of the
list, then I simply walk the list with the loop calling get(i), which
also happens to be the next element in the list from where the list
cursor currently is (ListIterator interface docs). Serendipity I
suppose, but my usage is the most efficient for LinkedLists and also
happens to be performant with ArrayLists, to do the
particular traversal
that I'm doing.
Kev
-
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]
--
Phil Weighill-Smith [EMAIL PROTECTED]
Volantis Systems
DO NOT REPLY [Bug 32200] - CBZip2InputStream and CBZip2OutputStream produce strange exceptions when there's no data
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32200. 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=32200 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 12:56 --- Created an attachment (id=14374) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14374action=view) Fixes and Unit test for CBZip2* The unit test shows the behaviour, and the minor changes I've made allow the tests to pass, but I'm not confident about these changes not breaking anything (throwing an Exception that we didn't used to throw will probably be a BC issue) - removed trailing ; when found -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33764] - available type=dir always fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33764. 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=33764 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 12:56 --- (In reply to comment #1) Type using: available file=C:\Program Files type=dir property=someProperty/ I already did, and it gave problems where it was interpreting \P as some escaped sequence. I should point out that I am injecting this property into build.properties so I think it needs an extra layer of escaping (which I've tried). Is there some other catch with property files I should know about? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32455] - JavaCC task should prefer newer versions of JavaCC
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32455. 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=32455 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 13:13 --- Created an attachment (id=14375) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14375action=view) Documentation warning users to avoid having two versions of JavaCC available at the same time -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33764] - available type=dir always fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33764. 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=33764 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 13:21 --- 1) did you use the test by itself in a stand-alone build.xml file 2) \ is an escape character in properties file - blame mickysoft for chosing an excape character for a directory seperator 3) you can use / instread of \ for directory seperator character on windows. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33764] - available type=dir always fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33764. 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=33764 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 13:39 --- I finally tracked the problem down. Seems to have been caused by a combination of Ant's colorful properties may only be set once behavior, my own fault for not noticing that the property was already set (to an incorrect value where the space in the filename was not escaped). As well, I had this in the property file: jdk15.home=C:/program files/java/jdk1.5.0_01 Now, ignoring the fact that the space is unescaped, the actual problem is the surrounding quotes around the value. Turns out that when available gets that value, it does not interpret the quotes as escaping slashes and spaces. Instead, it just dies with unable to find path. I'd like to recommend the following for avoid this errors in the future: 1) available should allow quotes to escape the value 2) Can you please add some sort of feature whereby Ant fails the build if someone tries overriding the value of a property with a value different than it's already set to? You can make this optional but I am hopeful we can have it enabled by default. It would probably save a lot of people a lot of headaches. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33764] - available type=dir always fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33764. 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=33764 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33770] New: - Unable to retrieve file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33770.
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=33770
Summary: Unable to retrieve file
Product: Ant
Version: 1.6.2
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I am unable to retrieve the following file with Ant:
wget ftp://nlmpubs.nlm.nih.gov/online/mesh/.xmlmesh/desc2005.gz
Note the dot in the path. wget doesn't have any problems retrieving this file.
But with Ant's get task:
[get] Getting: ftp://nlmpubs.nlm.nih.gov/online/mesh/.xmlmesh/desc2005.gz
[get] Error opening connection sun.net.ftp.FtpProtocolException: PORT :500
Illegal PORT command, EPSV ALL in effect
[get] Error opening connection java.io.FileNotFoundException:
online/mesh/.xmlmesh/desc2005.gz
[get] Error opening connection java.io.FileNotFoundException:
online/mesh/.xmlmesh/desc2005.gz
[get] Can't get ftp://nlmpubs.nlm.nih.gov/online/mesh/.xmlmesh/desc2005.gz to
/work/data/src/mesh.xml.gz
And with the ftp task:
[ftp] getting files
[ftp] 0 files retrieved
Here is the corresponding fragment from the build.xml:
ftp
server=${host}
userid=anonymous
password=anonymous
action=get
depends=yes
passive=yes
preservelastmodified=yes
fileset dir=.
include name=${path}/
/fileset
/ftp
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33771] New: - Default username and password for ftp task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33771. 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=33771 Summary: Default username and password for ftp task Product: Ant Version: 1.6.2 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Optional Tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The ftp task could save us some typing by using a default anonymous user name and password, if none is specified, rather than refusing to do anything. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33771] - Default username and password for ftp task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33771. 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=33771 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement OS/Version|Windows XP |All -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33764] - available type=dir always fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33764. 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=33764 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 15:47 --- I dont think we want to get into trying to be smart about quotes, because they are sometimes there legitimately. Like when you have files with quotes in them, which is certainly feasible on some platforms. And it is usally a pretty rare occurence, you only got burned because you were using property files. Property files have their own little quirks, even though they are wonderfully simple usually. As for warning about overrides, you can run ant -verbose and get this kind of information, along with lots of others. Dont be afraid of the -v (or even -d) switch when things start misbehaving. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Ant Wiki] Updated: Proposals
Date: 2005-02-28T06:51:41 Editor: SteveLoughran Wiki: Ant Wiki Page: Proposals URL: http://wiki.apache.org/ant/Proposals no comment Change Log: -- @@ -5,3 +5,5 @@ * Being able to view the manual for previous versions on the website. * Add target that will be executed if a target failes target name=abc onerror=anothertarget + + * [Ant17/Planning] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: 1.7 release timetable features.
James Fuller wrote: no, I have already gone through the input masking funits more about locking down...or giving the opportunity to lock down; e.g. secure class loading, working with digital certs, etc... to run ant secure you'd need to generate a JAR of everything in the tasks and tasks.optional packages and sign them. And merge in the tests before running them, as they are in the same packages. that would be troublesome. It's hard to retrofit that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Ant Wiki] New: Ant17/Planning
Date: 2005-02-28T07:25:53 Editor: SteveLoughran Wiki: Ant Wiki Page: Ant17/Planning URL: http://wiki.apache.org/ant/Ant17/Planning start of planning for ant1.7 New Page: = Ant 1.7 Planning Section = == Milestones == * Beta1 * Beta2 * RC1 * Release === Projects we depend on and their forthcoming releases === * Xerces. We redist this, so should get a late release. * Xalan * JUnit (stable) * Java === Projects that depend upon us, and their cutoff dates === * Eclipse 3.1 in June, would need Ant1.7 Monday May 9th, 2005 * NetBeans * IntelliJ IDEA (5.0 expected in the summer) * JEdit (less tightly coupled) = Features = == ''Must Have'' Features == These are the features that hold the build; fallbacks to be listed. To add something here you must be prepared to implement it, or know someone who is. Everything needs a name. * SVN support by exec [stefan] * Security on libraries, document task. [stevel] * Local variables in macrodef * Fix for key IDE bugs (see eclipse, netbeans bugzillas) [all] * flatten in libraries to WAR/EAR somehow (related to libraries) [stevel?] * classloader to allow adding of jars to the current classloader (would solve a ''lot'' of problems at the cost of some issues) http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 [peter] == ''Want'' Features == Less critical, but still nice. Adding here is also a statement of intent. * Java1.5 environment fetching. Ideally as part of a rework of Execute.getProcessEnv() * Doc improvements. * propertyfile in java tasks for loading properties straight from a file. * reduce number of outstanding bugzilla ''bugs'' by fixing them. * reduce number of outstanding bugzilla ''enhancements'' by implementing some, or closing them off. * include fetch.xml in redist package * improve diagnostics when something like junit wont instantiate. i.e. distinguish class not found from class not loadable and explain why the difference. Maybe allow for per-task diagnostics text through a static member function, or extra markup in the taskdef. == ''Like'' Features == Less important stuff. * libraries: multi repository support a la maven. * security hardening. locking down...or giving the opportunity to lock down; e.g. secure class loading, working with digital certs, etc... Rated as 'like' because of the difficulty. * Look at all SCM tasks and pull in pending patches for new features. Find people to test them. * rename junit.jar to junit-3.8.1 in SCM, for libraries integration. As this is only in lib/optional, effects should be minimal (i.e. rename wont be visible to end users). == WONTFIX == Definitely not in this release. Pull stuff down here when scrubbed from the previous lists. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Execute. getProcEnvironment()
seeing the install notes for eclipse shows up what they think are troublespots with ant, one of them being that property environment=env / hangs: http://issues.apache.org/bugzilla/show_bug.cgi?id=26770 I think we ought to take a look at this code, and rework it some more. It is all built around executing external code to find out env properties, when now, with Java1.5, we can get it from the system environment -execing programs should be our fallback on older systems. I have added it to the want list for Ant1.7 that I have just put up on the wiki. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33764] - available type=dir always fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33764. 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=33764 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 18:09 --- Steve, The problem with Ant -v is that it won't stop the build once a property has been overwriten. That is, it'll warn about it, but I'll never notice because it'll spew out 10,000 other lines of output. Is it possible to add a strict mode for Ant which causes it to die on warnings (I assume this is a warning)? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33764] - available type=dir always fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33764. 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=33764 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 18:36 --- The number of builds this behavior would break is so incalculable that I can't see us ever implementing this. If I were you and I really thought I wanted this, I would create a macro to do this for me. Attachment forthcoming... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33764] - available type=dir always fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33764. 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=33764 --- Additional Comments From [EMAIL PROTECTED] 2005-02-28 18:37 --- Created an attachment (id=14376) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14376action=view) buildfile containing a macro to fail on attempted reset of property value -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
a few questions
Steve Loughran wrote: James Fuller wrote: no, I have already gone through the input masking funits more about locking down...or giving the opportunity to lock down; e.g. secure class loading, working with digital certs, etc... to run ant secure you'd need to generate a JAR of everything in the tasks and tasks.optional packages and sign them. And merge in the tests before running them, as they are in the same packages. that would be troublesome. It's hard to retrofit that. agreed...though I think there is an opportunity with tasks (correct me if my understanding is wrong on this) are going to be seperated out as libraries, not sure what this means, but I think the first step getting the Ant core aligned core security principles would be an impromptu review of weakest links; any kind of anecdotal information...then start from there...tasks..be they core/optional are another thing alltogether. btw I have a few general developer questions...and before I start caning bugzilla I think - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
a few questions (sorry quite long)
btw I have a few general developer questions... before I start caning bugzilla I think any responses would be well appreciated; a few comments on usage of XDoclet to autodoc manual as someone who is a complete fan of XDoclet and avid user in enterprise java computing...I am surprised at myself at having reservations with its usage in task definitions having a single source from which documentation is generated is a 'good thing'...esp in defining task, its attributes, as well as general documentation, but how to deal with other potential documentation requirements, e.g. if we wanted to we could also embed build scripts, example input/output, and schema definitions as well...perhaps there is some traction to be gained by having a simple task markup language without thinking ?xml version=1.0 encoding=UTF-8? task name=echo xmlns:x=http://www.w3.org/1999/xhtml; attribute name=message required=true|false default= descthe message to echo./desc requiredYes, unless data is included in a character section within this element./required /attribute attribute name=file required=true|false default=the file to write the message to./attribute attribute name=append required=true|false default=falseAppend to an existing file?/attribute attribute name=level required=true|false values=error,warning,inf,verbose,debug default=warningControl the level at which this message is reported. One of error, warning, info, verbose, debug /attribute block name=description x:pEchoes a message to the current loggers and listeners which means System.out unless overridden. A level can be specified, which controls at what logging level the message is filtered at./x:p x:pThe task can also echo to a file, in which case the option to append rather than overwrite the file is available, and the level option is ignored/x:p /block usecase !-- could place example build scripts, along with inputs/outputs/expected -- /usecase dependencies !-- if we were smart we would have this in a getlibraries/ friendly format -- /dependencies schema type=relaxng|dtd|xmlschema href=/ /task we could use xinclude if we wanted to break things upalso we could assume that code takes precedent either overwriting, or where no source comments exist taken from this document for ant manual definition purposes...I really think given task writers the ability to combine the power XDoclet and and external task markup format. Also this format could be impregnated with dublincore for versioning; in addition we could choose xhtml as an additional format...in any event the more meta data the better. - a few general comments - getlibraries has no task definition that I can seecorrect me if I am wrong - exec task has floating html tag in manual - does scriptdef have namespace capability - i think its important to make sure developers for for DispatchTask...its seems to be buried - note: there is no 2005 copyright in ant manual/docs - is there a list of @ant.task category types anywhere ? - is abstractaccess optional task @ant.task category the right way to use this doc tag? also any list of ant.task category anywhere ? - couldnt find any logging/listener tests under testcases ? - MagicNames.java...whats the status and intended purpose ? - any update on webdav task some very boring and picky refactoring related thoughts I see a lot of Ant refactoring opportunities with respect to package naming...no doubt the twin poles of maintaining backwards compatibility with cutting edge functionality has caused a bit of chaos in the source tree. There are a few methods of mapping old package names (satisfy deprecated, older calls) to better logical structures...any thoughts re this ? if sothen a few suggestions on moving things around; Why not move things like -org/apache/tools/launch/Locator to -org/apache/tools/helper Why not move -org/apache/tools/NoBannerLogger, SubBuildListener, XMLLogger to -org/apache/tools/listener Why not move ? -main/org/apache/tools/bzip -main/org/apache/tools/bzip2 -main/org/apache/tools/mail -main/org/apache/tools/tar -main/org/apache/tools/zip excuse my ignorance here (well if u never ask questions...)are these are org.apache.tools packages used by other apache projects Also in testcases things are a bit messy...for example why not put dummy into -testcases/org/apache/tools/dummy along these lines, I find burying property files can sometimes be detrimental, for example in main source we have; -main/org/apache/tools/taskdef/defaults.properties -main/org/apache/tools/types/defaults.properties -main/org/apache/tools/listener/defaults.properties
DO NOT REPLY [Bug 33779] New: - jar NPEs when merging a manifest, when there is no file to merge into
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33779.
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=33779
Summary: jar NPEs when merging a manifest, when there is no
file to merge into
Product: Ant
Version: 1.7Alpha (nightly)
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
This snippet toasts the JVM:-
jar destfile=${target.jar}
index=true
filesetmanifest=merge
fileset dir=${build.dir}/classes/
metainf dir=src/META-INF//
manifest
attribute name=Built-By value=${user.name}/
attribute name=Sealed value=true/
attribute name=Built-On value=${timestamp.isoformat}/
attribute name=Main-Class value=${main.class}/
/manifest
/jar
Same if the manifest element is missing.
java.lang.NullPointerException
at org.apache.tools.ant.taskdefs.Zip.executeMain(Zip.java:556)
at org.apache.tools.ant.taskdefs.Zip.execute(Zip.java:385)
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
