DO NOT REPLY [Bug 45499] DirectoryScanner infinitely recurses on symlinks to parent directories
https://issues.apache.org/bugzilla/show_bug.cgi?id=45499 --- Comment #5 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 00:50:38 PST --- Matt: yes, I think it is doable, even without too many or too big changes, but we need to think through some scenarios first to decide what to do. I'll take that to the dev list later (after coding up some AntUnit tests as use cases). Tim: hasBeenScanned only receives the relative path which will be different each time the directory is encountered again. I was thinking about a case where we have a structure like this A/ |--- B/ |- C.txt D/ |- E (symlink pointing to A) Let's say we set basedir to D and scan with an include pattern of E/B/C.txt - should it match the file or should we skip going upwards (we wouldn't rescan D since it isn't matched by an include pattern)? I haven't checked, but we may even get the file in fast mode and an infinite loop in slow mode (when the client asks for the not-included files/dirs). The good thing is that we don't need to think about backwards compatibility for the cases where Ant could run into an infinite loop 8-) Like I said, I'll move the discussion over to the dev list. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 45739] New: Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739
Summary: Problems with BaseDir when the ant is started as Java
library from Java Application
Product: Ant
Version: 1.7.1
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: blocker
Priority: P2
Component: Core
AssignedTo: notifications@ant.apache.org
ReportedBy: [EMAIL PROTECTED]
I try to start ant script using ant as java library from Java application. The
start is realized as follow:
File buildXmlFile = new File(C:\a\b\z.xml);
ListString command = new ArrayListString();
...
command.add(...);
...
command.add(-buildfile);
command.add(buildXmlFile.getAbsolutePath());
Main ant = new Main();
ant.startAnt(command.toArray(new String[command.size()]), null, null);
The content of build xml file is:
?xml version=1.0 encoding=UTF-8?
project name=SSHAntScriptTest default=default basedir=.
descriptionBuild file for SSH Ant Script tests./description
scp file=test.txt todir=${username}:[EMAIL PROTECTED]:/home/bc/
/project
The xml build file location is different from the execution directory.
When that execution is initiated from the command prompt like that everything
is OK:
c:\somedirant -buildfile c:\anotherdirbuildfile.xml
When I try to start the same with the same parameters as java library the
text.txt file can not be founded. Ant looks for the file in execution directory
c:\somedir\test.txt instead in buildfile directory c:\anotherdir\test.txt.
To fix this at the moment the following changes are made:
1. The user.dir is changed:
File dir = buildXmlFile.getParentFile();
System.getProperties().put(user.dir, dir.getAbsolutePath());
2. The method runBuild from the Main class is fixed as follow:
private void runBuild(ClassLoader coreLoader) throws BuildException {
...
project.init();
// 2008-Sep-04: Bug Fix from Miro.
project.getBaseDir();
I try to put that fix before project.init() without result.
If you need I can send you one small project as test case.
The big problem is that I do some changes in System Properties and that the
application is multi-thread and multi-tasking and because System Properties are
global (static) for all instances in the current JVM.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45740] New: SSHBase to be able to use external Session instead everytime to create new one
https://issues.apache.org/bugzilla/show_bug.cgi?id=45740
Summary: SSHBase to be able to use external Session instead
everytime to create new one
Product: Ant
Version: 1.7.1
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: enhancement
Priority: P2
Component: Optional Tasks
AssignedTo: notifications@ant.apache.org
ReportedBy: [EMAIL PROTECTED]
I notice that SSHBase which is base class for ssh copy, execute, sft, etc.
creates Session everytime instead to use some existing ssh session. This can be
corrected very easy with adding 2nd constructor with one Session parameter and
get/set session like that:
public SSHBase(Session session)
{
this.session = session;
}
public Session getSession()
{
if(session == null || !session.isConnected())
{
session = openSession();
}
return session;
}
public void setSession(Session session)
{
this.session = session;
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Severity|blocker |normal --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 05:48:56 PST --- blocker might a bit high as a priority since it isn't really blocking any usage Ant has been designed for 8-) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45740] SSHBase to be able to use external Session instead everytime to create new one
https://issues.apache.org/bugzilla/show_bug.cgi?id=45740 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Target Milestone|--- |1.8.0 --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 05:50:16 PST --- *** This bug has been marked as a duplicate of bug 43083 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43083] [SUBMIT] sshsession task
https://issues.apache.org/bugzilla/show_bug.cgi?id=43083 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #9 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 05:50:16 PST --- *** Bug 45740 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 45741] New: fileset follows symlink if basedir is link and followsymlink is false
https://issues.apache.org/bugzilla/show_bug.cgi?id=45741 Summary: fileset follows symlink if basedir is link and followsymlink is false Product: Ant Version: 1.8Alpha (nightly) Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: notifications@ant.apache.org see testBasedirIsSymlinkNoFollow in http://svn.apache.org/repos/asf/ant/core/trunk/src/tests/antunit/core/dirscanner-symlinks-test.xml -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 45742] New: delete fails if directory contains symlinks pointing back
https://issues.apache.org/bugzilla/show_bug.cgi?id=45742
Summary: delete fails if directory contains symlinks pointing
back
Product: Ant
Version: 1.8Alpha (nightly)
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Core tasks
AssignedTo: notifications@ant.apache.org
ReportedBy: [EMAIL PROTECTED]
run the target -link-to-parent in
http://svn.apache.org/repos/asf/ant/core/trunk/src/tests/antunit/core/dirscanner-symlinks-test.xml
delete dir=${input}/
fails after that.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45743] New: symlink action=delete fails for links pointing to parents
https://issues.apache.org/bugzilla/show_bug.cgi?id=45743
Summary: symlink action=delete fails for links pointing to
parents
Product: Ant
Version: 1.8Alpha (nightly)
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Optional Tasks
AssignedTo: notifications@ant.apache.org
ReportedBy: [EMAIL PROTECTED]
after running -link-to-parent in
http://svn.apache.org/repos/asf/ant/core/trunk/src/tests/antunit/core/dirscanner-symlinks-test.xml
symlink fails to delete the link ${base}/A.
The reason is that symlink first renames the directory linked to and then tries
to remove the link - but that way the link's name has changed and the File
object points to a no longer existant file.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 36658] Delete task follows symlinks - bad behavior
https://issues.apache.org/bugzilla/show_bug.cgi?id=36658 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added CC||notifications@ant.apache.org AssignedTo|notifications@ant.apache.org|[EMAIL PROTECTED] -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
DO NOT REPLY [Bug 44013] Add delete-dir-only-if-empty FAQ entry
https://issues.apache.org/bugzilla/show_bug.cgi?id=44013 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 06:13:10 PST --- svn revision 692000, thanks! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44655] symlink delete fails
https://issues.apache.org/bugzilla/show_bug.cgi?id=44655 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 06:14:43 PST --- *** This bug has been marked as a duplicate of bug 41525 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 41525] Unable to delete symlink when permissions incorrect on target
https://issues.apache.org/bugzilla/show_bug.cgi?id=41525 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 06:14:43 PST --- *** Bug 44655 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 19252] untar does not untar symbolic links properly
https://issues.apache.org/bugzilla/show_bug.cgi?id=19252 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #3 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 06:26:26 PST --- *** Bug 43187 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43187] untar does not create symlinks
https://issues.apache.org/bugzilla/show_bug.cgi?id=43187 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 06:26:26 PST --- *** This bug has been marked as a duplicate of bug 19252 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 36658] Delete task follows symlinks - bad behavior
https://issues.apache.org/bugzilla/show_bug.cgi?id=36658 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #2 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 06:31:57 PST --- *** Bug 22632 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 36658] Delete task follows symlinks - bad behavior
https://issues.apache.org/bugzilla/show_bug.cgi?id=36658 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 22632] Delete follows symbolic links to directories
https://issues.apache.org/bugzilla/show_bug.cgi?id=22632 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Comment #9 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 06:31:57 PST --- even though bug 36658 I mark them this way around since the later contains a (not yet evaluated) patch. *** This bug has been marked as a duplicate of bug 36658 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43689] Need a way to add symlinks to a tar
https://issues.apache.org/bugzilla/show_bug.cgi?id=43689 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #5 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 06:32:59 PST --- *** This bug has been marked as a duplicate of bug 40059 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 40059] Add method to explicitly define symlinks in tar task
https://issues.apache.org/bugzilla/show_bug.cgi?id=40059 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 06:32:59 PST --- *** Bug 43689 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 41285] delete and symlink tasks do not delete a symlink if its target does not exist
https://issues.apache.org/bugzilla/show_bug.cgi?id=41285 --- Comment #10 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 07:28:25 PST --- symlink action=delete .../ should work with svn revision 692047 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 45499] DirectoryScanner infinitely recurses on symlinks to parent directories
https://issues.apache.org/bugzilla/show_bug.cgi?id=45499 --- Comment #6 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 07:30:05 PST --- dev thread started http://marc.info/?l=ant-devm=122053158307830w=2 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 45743] symlink action=delete fails for links pointing to parents
https://issues.apache.org/bugzilla/show_bug.cgi?id=45743 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 Version|1.8Alpha (nightly) |1.7.1 --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 07:57:19 PST --- fixed with svn revision 692081 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 41525] Unable to delete symlink when permissions incorrect on target
https://issues.apache.org/bugzilla/show_bug.cgi?id=41525 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added CC||notifications@ant.apache.org AssignedTo|notifications@ant.apache.org|[EMAIL PROTECTED] -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
DO NOT REPLY [Bug 41525] Unable to delete symlink when permissions incorrect on target
https://issues.apache.org/bugzilla/show_bug.cgi?id=41525 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #2 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 08:44:48 PST --- fixed with svn revisions 692082 and 692115 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 45746] New: task sql with child fileset that has child include with if attribute could not work properly
https://issues.apache.org/bugzilla/show_bug.cgi?id=45746
Summary: task sql with child fileset that has child include with
if attribute could not work properly
Product: Ant
Version: 1.7.1
Platform: PC
OS/Version: Windows Vista
Status: NEW
Severity: critical
Priority: P2
Component: Core tasks
AssignedTo: notifications@ant.apache.org
ReportedBy: [EMAIL PROTECTED]
my build.xml can not work properly, all attaches as below.
if I remove attribute if , it works OK. and the output as below :
---
[sql] connecting to jdbc:oracle:thin:@192.168.1.22:1521:ORCL
[sql] Loading oracle.jdbc.driver.OracleDriver using AntClassLoader with
classpath
---
if I remain attribute if, but add code at position (1) in build.xml, the ant
not work, the output show same error.
---inserted code
property name=local.dbinit.exist1 value=true /
property name=local.dbinit.exist2 value=true /
property name=local.dbinit.exist3 value=true /
property name=local.dbinit.exist4 value=true /
then I trace into ant's code, the last method code is below, and behavior ==
ADD, so if condition is false and fileset object ignored:
void store(Object parent, Object child)
throws InvocationTargetException, IllegalAccessException,
InstantiationException {
if (behavior == ADD_CONFIGURED) { // real value of behavior is 1,
jumped
istore(parent, child);
}
}
call stack is:
=IntrospectionHelper$AddNestedCreator.store#1293
=IntrospectionHelper$Creator.store#1201
=UnknownElement.java#570
==disk file tree (vista tree output)
D:\work\platform\frrp
│ .project
│ .tomcatplugin
│ build-win.properties
│ build.properties
│ build.xml
│ hbm.properties
│
├─design
│ db-frrp-oracle.sql
│ init-frrp.sql
│
└─work
tldCache.ser
=== my build.xml =
!-- =
target: dbinit
= --
target name=dbinit depends=_dbconfig description=== init and
load data
echo message=LOAD DATA USING: ${db.driver}
${db.connection.url} /
!-- position (0), add debug code here --
available property=local.dbinit.exist1
file=${output.db.script.dir}/db-${project.name}-${db.server.type}-extra.sql
/
available property=local.dbinit.exist2
file=${output.db.script.dir}/db-${project.name}-extra.sql /
available property=local.dbinit.exist3
file=${output.db.script.dir}/init-${project.name}-${db.server.type}.sql /
available property=local.dbinit.exist4
file=${output.db.script.dir}/init-${project.name}.sql /
sql driver=${db.driver} url=${db.connection.url}
userid=${db.user} password=${db.pass} onerror=continue
classpath refid=test-classpath /
fileset dir=${output.db.script.dir}
include
name=db-${project.name}-${db.server.type}-extra.sql
if=${local.dbinit.exist1} /
include name=db-${project.name}-extra.sql
if=${local.dbinit.exist2} /
include
name=init-${project.name}-${db.server.type}.sql if=${local.dbinit.exist3}
/
include name=init-${project.name}.sql
if=${local.dbinit.exist4} /
/fileset
/sql
/target
!-- _dbconfig only set some property value about jdbc and hibernate(it will
auto check hibernate version) --
target name=_dbconfig depends=__db_config,__init_hibernate
/target
target name=__init_hibernate
depends=___check_hibernate,___init_hibernate2,___init_hibernate3
taskdef name=schemaexport
classname=${db.hibernate.tool.package}.SchemaExportTask
classpathref=hibernate_classpath /
taskdef name=schemaupdate
classname=${db.hibernate.tool.package}.SchemaUpdateTask
classpathref=hibernate_classpath/
echouse hibernate class:/echo
echo
db.hibernate.schemaexporttask=${db.hibernate.tool.package}.SchemaExportTask/echo
echo db.hibernate.dialect=${db.hibernate.dialect}/echo
/target
target name=___check_hibernate depends=_init_classpath
available
classname=net.sf.hibernate.tool.hbm2ddl.SchemaExportTask
classpathref=classpath
property=hibernate2_support /
available
classname=org.hibernate.tool.hbm2ddl.SchemaExportTask
classpathref=classpath
property=hibernate3_support /
path id=hibernate_classpath
path
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739 --- Comment #2 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 23:25:03 PST --- There are two different places where basedirs might get resolved. One is in Project#setBaseDir which may be invoked with . if Project#getBasedir is called before the Project instance knows its basename. This would resolve relative to the current working directory and not the location of the build file. The other place is ProjectHelper2#onStartElement which is invoked while the build file gets parsed, this will resolve relative to the location of the build file. My guess is that something in your code invokes project.getBasedir() before the project's build file has been parsed. The most common reason for this is a BuildListener invoking getBaseDir in the buildStarted event which is fired before the build file gets parsed. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45746] task sql with child fileset that has child include with if attribute could not work properly
https://issues.apache.org/bugzilla/show_bug.cgi?id=45746
Stefan Bodewig [EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-04 23:37:56 PST
---
the if attribute expects the name of the property to be tested, not its value.
Use if=local.dbinit.exist1 instead of if=${local.dbinit.exist1}.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739
--- Comment #3 from Miroslav Nachev [EMAIL PROTECTED] 2008-09-04 23:39:33
PST ---
(In reply to comment #2)
My guess is that something in your code invokes project.getBasedir() before
the
project's build file has been parsed. The most common reason for this is a
BuildListener invoking getBaseDir in the buildStarted event which is fired
before the build file gets parsed.
If you see my code where I am resolving the problem you will see that I call
project.getBaseDir(). In principle this is not good kind of programming but I
haven't time to re-write the whole Apache ant code.
Unfortunately the second problem with System Properties is still existing. This
can be solved very easy with one helper class SystemUtil which to be instanced
for each ant instance. All calls to/from the System Properties in the existing
ant code to be replaced with that class like systemUtil.getUserDir():
public class SystemUtil
{
private String userDir;
public String getUserDir()
{
if(userDir == null)
{
userDir = System.getProperty(user.dir);
}
return userDir;
}
public void setUserDir(String userDir)
{
this.userDir = userDir;
}
}
With that code the problem with multi-tasking and multi-threads will be solved.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739 --- Comment #4 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-05 00:11:17 PST --- I think you misunderstood me. Your code, the code starting Ant, must be calling getBasedir before it is safe to do so, right now I don't see anything wrong in Ant (moving getBasedir to runBuild would break a lot of other things and simply is wrong). I don't think Ant explicity reads user.dir anyplace, it just does a 'new File(.)' which is resolved relative to user.dir on some VM implementations on some operating systems (other VMs don't consult that property but the OS process' knowledge about its current working directory and setting user.dir won't help). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739 --- Comment #5 from Miroslav Nachev [EMAIL PROTECTED] 2008-09-05 00:36:43 PST --- When I am calling project.getBaseDir() before project.init() which is located in runBuild the problem is not solved because the retrieved directory is the place from where the application is started instead to be the parent directory of the build file. I need baseDir to be parent directory of build file. Also I am not agree that in the code System.getProperty(user.dir) is not used. The actual usage is: System.getProperty(user.dir) - 10 times 1 time in org.apache.tools.ant.Main 1 time in org.apache.tools.ant.launch.Locator 1 time in org.apache.tools.ant.taskdefs.Execute 1 time in org.apache.tools.ant.taskdefs.optional.ejb.IPlanetEjbc 1 time in org.apache.tools.ant.types.Path 1 time in org.apache.tools.ant.util.FileUtils 1 time in org.apache.tools.ant.ProjectTest 3 times in org.apache.tools.ant.util.FileUtilsTest System.getProperties().put(user.dir, ...) - 2 times 2 times in org.apache.tools.ant.taskdefs.Execute -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739 --- Comment #6 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-05 01:04:05 PST --- I'm not suggesting you should invoke project.getBasedir earlier (prior to project.init), quite the opposite. Something is calling getBasedir on your project instance before it is safe to do so, i.e. before the XML file has been parsed which doesn't happen before ProjectHelper.configureProject in runBuild. Yes, user.dir may be read in some places but neither is directly related to setting the basedir. On a related note, changing the current working directory within a Java process is almost impossible to do 8and impossible to do in a portable way). If you change user.dir it probably doesn't have the desired effect on tasks like exec. Just take a look at the many silly things the Execute class does to be able to invoke an executable inside a different working directory than the one of the current process - simple as long as you can stick with a specific JVM on a specific OS. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739
--- Comment #7 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-05 01:18:15 PST
---
Let's see.
Test.java is
import org.apache.tools.ant.Main;
public class Test {
public static void main(String[] args) throws Exception {
System.out.println(user.dir is + System.getProperty(user.dir));
System.out.println(args[0] is + args[0]);
new Main().startAnt(new String[] {-f, args[0]}, null, null);
}
}
x.xml is
project basedir=.
echo${user.dir}/echo
echo${basedir}/echo
/project
C:\Tempc:\j2sdk1.4.2_18\bin\java.exe -classpath
..\OSS\ant\build\lib\ant.jar;..
\OSS\ant\build\lib\ant-launcher.jar;. Test x.xml
user.dir is C:\Temp
args[0] is x.xml
Buildfile: C:\Temp\x.xml
[echo] C:\Temp
[echo] C:\Temp
BUILD SUCCESSFUL
Total time: 0 seconds
C:\Tempcopy x.xml ..
1 Datei(en) kopiert.
C:\Tempc:\j2sdk1.4.2_18\bin\java.exe -classpath
..\OSS\ant\build\lib\ant.jar;..
\OSS\ant\build\lib\ant-launcher.jar;. Test ..\x.xml
user.dir is C:\Temp
args[0] is ..\x.xml
Buildfile: C:\x.xml
[echo] C:\Temp
[echo] C:\
BUILD SUCCESSFUL
Total time: 0 seconds
so basedir is the directory of the build file and not the current working
directory in my case.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739 --- Comment #8 from Miroslav Nachev [EMAIL PROTECTED] 2008-09-05 01:24:43 PST --- Yes, user.dir may be read in some places but neither is directly related to setting the basedir. I am not agree with that again. The true is that when I set this value my problem is solved which means that somewhere user.dir is used for setting of basedir. Look at method onStartElement of ProjectHelper2.ProjectHandler class: project.setBaseDir(FILE_UTILS.resolveFile(context.getBuildFileParent(), baseDir)); It is similar in ProjectHelperImpl, etc. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739
--- Comment #9 from Miroslav Nachev [EMAIL PROTECTED] 2008-09-05 01:44:07
PST ---
(In reply to comment #7)
x.xml is
project basedir=.
echo${user.dir}/echo
echo${basedir}/echo
/project
The build xml file is not full. Place one file inside like that:
scp file=test.txt todir=${username}:[EMAIL PROTECTED]:/home/bc/
When scp try to find the file, the file will miss because ant will try to find
it in user.dir instead basedir.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739
--- Comment #10 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-05 02:06:20
PST ---
(In reply to comment #8)
Yes, user.dir may be read in some places but neither is directly related to
setting the basedir.
I am not agree with that again. The true is that when I set this value my
problem is solved which means that somewhere user.dir is used for setting of
basedir.
That somewhere most likely is the Java class library when it it asked to
resolve File(.).
(In reply to comment #9)
The build xml file is not full. Place one file inside like that:
Oh yes, it is. It shows that basedir is set correctly.
scp file=test.txt todir=${username}:[EMAIL PROTECTED]:/home/bc/
If you really need that, OK. Same Test.java as before
x.xml now is
project basedir=.
echo${user.dir}/echo
echo${basedir}/echo
scp file=x.xml todir=stefan:[EMAIL PROTECTED]:/home/stefan/
/project
C:\Tempdir x.xml
Volume in Laufwerk C: hat keine Bezeichnung.
Volumeseriennummer: 1027-F564
Verzeichnis von C:\Temp
Datei nicht gefunden
C:\Tempc:\j2sdk1.4.2_18\bin\java.exe -classpath
.;..\OSS\ant\build\lib\ant.jar;
..\OSS\ant\build\lib\ant-launcher.jar;..\OSS\ant\build\lib\ant-jsch.jar;..\OSS\a
nt\lib\optional\jsch-0.1.29.jar Test ..\x.xml
user.dir is C:\Temp
args[0] is ..\x.xml
Buildfile: C:\x.xml
[echo] C:\Temp
[echo] C:\
[scp] Connecting to HOST:22
[scp] done.
BUILD SUCCESSFUL
Total time: 2 seconds
The Datei nicht gefunden as response to dir above means file not found
- have to live with a German OS, sorry - and shows that scp would have failed
if the file was resolved according to user.dir.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739
--- Comment #11 from Miroslav Nachev [EMAIL PROTECTED] 2008-09-05 02:09:06
PST ---
?xml version=1.0 encoding=UTF-8?
project name=SSHAntScriptTest basedir=.
descriptionBuild file for SSH Ant Script tests./description
echo${user.dir}/echo
echo${basedir}/echo
scp file=test.txt todir=${username}:[EMAIL PROTECTED]:/home/bc/
/project
Main ant = new Main();
ant.startAnt(command.toArray(new String[command.size()]), null, null);
INFO: Connecting to dzver4:22
Buildfile:
D:\Works.NB\Java\BundleCloud\bundlecloudpoc\modules\bundlecloudpoc-SSHUtil\src\test\java\com\prosyst\util\ssh\ant\impl\AntScript.xml
[echo]
D:\Works.NB\Java\BundleCloud\bundlecloudpoc\modules\bundlecloudpoc-SSHUtil
[echo]
D:\Works.NB\Java\BundleCloud\bundlecloudpoc\modules\bundlecloudpoc-SSHUtil
[scp] Connecting to dzver4:22
BUILD FAILED
java.io.FileNotFoundException:
D:\Works.NB\Java\BundleCloud\bundlecloudpoc\modules\bundlecloudpoc-SSHUtil\test.txt
(The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:106)
at
org.apache.tools.ant.taskdefs.optional.ssh.ScpToMessage.sendFileToRemote(ScpToMessage.java:232)
at
org.apache.tools.ant.taskdefs.optional.ssh.ScpToMessage.doSingleTransfer(ScpToMessage.java:160)
at
org.apache.tools.ant.taskdefs.optional.ssh.ScpToMessage.execute(ScpToMessage.java:144)
at org.apache.tools.ant.taskdefs.optional.ssh.Scp.upload(Scp.java:304)
at org.apache.tools.ant.taskdefs.optional.ssh.Scp.execute(Scp.java:203)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at
org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:142)
at
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:93)
at org.apache.tools.ant.Main.runBuild(Main.java:743)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at
com.prosyst.util.ssh.ant.impl.AntScriptImpl.build(AntScriptImpl.java:79)
at
com.prosyst.util.ssh.ant.impl.AntScriptImplTest.testBuild(AntScriptImplTest.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at
org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at
org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at
org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at
org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at
org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at
org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at
org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at
org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739 --- Comment #12 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-05 02:18:52 PST --- would you please try my Test.java instead of a different Java class run from a JUnit test run form Maven 8-) The later really leaves too many unknowns around. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739 --- Comment #13 from Miroslav Nachev [EMAIL PROTECTED] 2008-09-05 03:03:16 PST --- Yes, when the test is not in maven and is not started from JUnit (4.x) the result is OK. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45750] New: URI support as source
https://issues.apache.org/bugzilla/show_bug.cgi?id=45750 Summary: URI support as source Product: Ant Version: 1.7.1 Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: Optional Tasks AssignedTo: notifications@ant.apache.org ReportedBy: [EMAIL PROTECTED] At the moment in all SSH elements (scp, etc.) only file is supported as source. It is good URI to be supported also because in many cases the web link will be the source. Now we must copy that web link on the local machine and then to pass as file parameter. It is good all ant source files to support URI. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45612] [Patch] Subproject Addressing and Simulation Mode
https://issues.apache.org/bugzilla/show_bug.cgi?id=45612 --- Comment #5 from Oran Fry [EMAIL PROTECTED] 2008-09-07 17:05:58 PST --- The basic idea of the Addressing feature is that it allows a user to see the project tree, and make use of its structure. It is an general tool which could have many uses, and users may find new ways to use it that even I haven't thought of. It's not just about resuming a build; that is only one way it can help. Here are some of the uses I have put addressing to: * Viewing the structure of an unfamiliar project (e.g., one downloaded from the internet) * Resuming a failed build that is not well designed to avoid repeat operations * Resuming even well designed builds which inevitably take time to skip over operations which are already done (especially when the checks involve checking files on the internet) * Stepping through a build, to examine the state of files etc. as the build progresses * Executing the first part of a build in preparation to execute the second part later (E.g., If I'm waiting for the files needed for the second part) * Skipping over an unstable or problematic part of a build without having to modify the build file. (e.g., If an build is failing at a particular target but you are able to perform that operation manually.) * Expressing the relationship between targets. Addressing lets the user see which targets are being called as dependencies and which are being called as subprojects. If do-b and do-c are subprojects of do-a, this expresses that b and c they are *part of* the process a. If do-b and do-c are dependencies of do-a, this expresses that b and c are things which must be done *before* process a. For a user, seeing these relationships makes a build easier to understand. * Avoiding repeat execution of init targets. Rather than making every target depend on init, I just make the entry point target(s) depend on init. Since the build is always entered from the entry point target, the init target will always be executed when the build is invoked. And it will only ever be executed once, unlike in some projects where it is executed multiple times as a result of the absence of backwards propagation in ant. It also saves you putting 'depends=init' on every target. * Checking for links in an antfile to other antfiles (i.e., use of the ant task. Done by using ant -sim -addressing.) * Addressing works for any ant file, whether the developers are aware of addressing or not. But if the developers are aware of addressing, they can design their builds to make special use of it and so get the most out of it. I have found the addressing option (in conjunction with the sim option) a pleasure to use as I have developed and used the nightly release snapshot system for Greenstone. It is actually very simple as far as the code changes are concerned - I have added just two if blocks to check whether a call to a task should proceed in light of the addressing and sim options specified on the command line, and the rest is just the code to pass those options around, some display stuff, and a class to represent an address. It has many uses, and I have had good feedback about it. So I think there is a lot of bang for your buck! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45739] Problems with BaseDir when the ant is started as Java library from Java Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=45739 --- Comment #15 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-08 03:18:48 PST --- do you think there is anything else we can do or should I close this as WORKSFORME? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 41285] delete and symlink tasks do not delete a symlink if its target does not exist
https://issues.apache.org/bugzilla/show_bug.cgi?id=41285 --- Comment #12 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-08 05:45:41 PST --- svn revision 693081 fixes a bug I introduced with 692047 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 43114] package-info.java repeatedly compiled
https://issues.apache.org/bugzilla/show_bug.cgi?id=43114 Marek Novotny [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Severity|minor |major --- Comment #11 from Marek Novotny [EMAIL PROTECTED] 2008-09-09 00:29:46 PST --- (In reply to comment #8) Our build scenario is as follows: 1. Copy the complete source tree to a temporary location. 2. Compile everything in the temporary location. After upgrading from 1.7.0 to 1.7.1, our package-info.java files don't get compiled any more, and this breaks our JAXB code. The reason for this may be because the copy preserves the file timestamps but not the folder timestamps, the latter are therefore more recent. Due to this change in behavior, we cannot use 1.7.1 at this point. With all this said, I personally don't understand how this change went into 1.7.1. Peter Reilly stated on April 18 that the change committed introduced serious regression and that this had to be resolved before releasing 1.7.1. I suspect this has not been done because the bug is still open. I strongly urge you to reconsider the changes for 1.7.2. I have the similar issue, I tried build with ant 1.7.1 and some package-info.java files weren't compiled at all even if in debug log ant says that this file will be compiled. Concrete compiled class isn't there, I mean in output dir for compiled classes. Ant 1.7.0 works fine. I can't believe that this change is only marked as minor, because for me it is blocker for using 1.7.1 version. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45002] javac using GCJ compiler ignores classpath
https://issues.apache.org/bugzilla/show_bug.cgi?id=45002 --- Comment #2 from RLVJ [EMAIL PROTECTED] 2008-09-09 02:33:24 PST --- Created an attachment (id=22544) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=22544) Trivial Java code and ant build script. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45002] javac using GCJ compiler ignores classpath
https://issues.apache.org/bugzilla/show_bug.cgi?id=45002 RLVJ [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|ASSIGNED --- Comment #3 from RLVJ [EMAIL PROTECTED] 2008-09-09 02:34:09 PST --- I've run a trivial test, which I'm uploading, code and all. I tested with Ant 1.6.5 on Linux and 1.7.1 with MinGW. The bug described did not reproduce. I only tested (this time) with a classpath element, not attribute. I speculate that the path I had used when I filed this bug was invalid and automatically removed from the classpath. Entries inherited remained and it appeared that the classpath was unaffected by the ant build script. What seems to be another bug does appear in the attached test. Inspite of includeAntRuntime includeJavaRuntime being set to false, the classpath contains inherited entries. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45002] javac using GCJ compiler ignores classpath
https://issues.apache.org/bugzilla/show_bug.cgi?id=45002 RLVJ [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID --- Comment #4 from RLVJ [EMAIL PROTECTED] 2008-09-09 03:09:37 PST --- I see that the bug I described last (about inherited classpath entries) is bug 34638 and that it is fixed later than ant 1.7.1 , which I used to test. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45499] DirectoryScanner infinitely recurses on symlinks to parent directories
https://issues.apache.org/bugzilla/show_bug.cgi?id=45499 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.8.0 --- Comment #7 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-10 08:44:32 PST --- the infinite loop should be gone with svn revision 693870. fileset now has a new attribute currently named maxLevelsOfsymlinks that currently defaults to 1. It controls how often a given symlink will be followed. Not yet documented (that's why I don't close the report) since attribute name and default value are up for discussion. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 32638] Enhancement to macrodef to support new feature.
https://issues.apache.org/bugzilla/show_bug.cgi?id=32638 Christoph Dittberner [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 32638] Enhancement to macrodef to support new feature.
https://issues.apache.org/bugzilla/show_bug.cgi?id=32638 --- Comment #6 from Christoph Dittberner [EMAIL PROTECTED] 2008-09-11 07:27:50 PST --- Created an attachment (id=22555) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=22555) patch to set local macro-properties for defined elements and attributs as described in paragraph 1 of the feature request Hi, I was looking after a feature like this since I started to use macrodefs in our ant-based build-environment. After a lot of reading through the mailinglists I found this feature request and I implemented the paragraph 1) on current 1.7.1-sources. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 41647] ConditionBase and TaskContainer do not work together since ant 1.6.0
https://issues.apache.org/bugzilla/show_bug.cgi?id=41647 --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-16 05:43:41 PST --- ConditionBase has public void add(Condition) since Ant 1.6 and thus the related IntrospectionHelper instance returns true in supportsNestedElement (addTypeMethods.size() == 1). This in turn makes UnknownElement's handleChild method assume a child by that name must exist and invoke getElementCreator on IntrospectionHelper which does a more thorough check in createAddTypeCreator and realizes that echo is not a condition. This again makes handleChild throw an exception instead of returning false which would trigger the addTask logic in handleChildren. I see two options: (1) make IntrospectionHelper#supportsNestedElement only return true when getElementCreator would return something or (2) catch the exception in UnknownElement#handleChild and return false. (1) would probably be cleaner but I'm afraid the method doesn't get all the context it would need to be able to tell the truth. You, Peter, should be at least as familiar as myself with the code so I'll wait for your input ;-) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 42208] Move AntLib.createAntLib to use project helper reference for parsing
https://issues.apache.org/bugzilla/show_bug.cgi?id=42208 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #2 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-16 06:21:51 PST --- fixed in svn revision 695865. if your ProjectHelper extends projectHelper2, things should work OOTB, otherwise you have to override two new methods in ProjectHelper. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 42219] Inefficient code in Union, DirectoryScanner makes large copy tasks very slow
https://issues.apache.org/bugzilla/show_bug.cgi?id=42219 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #7 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-16 06:33:14 PST --- DirectoryScanner is pretty much bound to Vector in several protected attributes so we can't change too much. Most other cases should have been replaced by now (findFile and isSymlink could be replaced but I'm not convinced we'd win much). Union is addressed by svn revision 581394 which is part of Ant 1.7.1. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45830] New: Cannot overwrite the older entry in the archive
https://issues.apache.org/bugzilla/show_bug.cgi?id=45830 Summary: Cannot overwrite the older entry in the archive Product: Ant Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Build Process AssignedTo: notifications@ant.apache.org ReportedBy: [EMAIL PROTECTED] I create jar file. Roll back system time and try to update a jar and merge one file (config.properties). This doesn't work. If it is ok why copy command has attribute overwrite and jar command doesn't? How to reproduce: 1. Create folders ant_test, classes and file config.properties 2. Created jar archive jar cvf ant_test.jar *.* 3. rollback system time 4. modified config.properties (incremented value of property max.size=2) 5. Executed ant task in build file target name=update_jar jar destfile=ant_test.jar update=true fileset dir=ant_test/ /jar /target 6. I get warning ( [jar] Warning: classes modified in the future.) and cannot update config.properties file. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45836] New: [PATCH] For correct empty CBzip2OutputStream handling
https://issues.apache.org/bugzilla/show_bug.cgi?id=45836
Summary: [PATCH] For correct empty CBzip2OutputStream handling
Product: Ant
Version: 1.8Alpha (nightly)
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Other
AssignedTo: notifications@ant.apache.org
ReportedBy: [EMAIL PROTECTED]
Created an attachment (id=22604)
-- (https://issues.apache.org/bugzilla/attachment.cgi?id=22604)
Patch to fix empty CBzip2OutputStream
In 1.7.1, creating and then closing a CBzip2OutputStream without writing any
dya to it would incorrectly result in an ArithmeticException being thrown (bug
32200). The code in svn has been modified so this no longer happens. However,
the resulting compressed output is no longer valid and won't decompress with
bunzip2 after prepending BZ to the stream.
Here's a patch against the code in svn that fixes the problem correctly as far
as I can tell.
Here's a test program:
$ cat X.java
import org.apache.tools.bzip2.CBZip2OutputStream;
class X {
public static void main(String[] args) throws Exception {
new CBZip2OutputStream(System.out).close();
}
}
Example incorrect 1.7.1 behavior:
$ java X
Exception in thread main java.lang.ArithmeticException: / by zero
at
org.apache.tools.bzip2.CBZip2OutputStream.mainSort(CBZip2OutputStream.java:1135)
at
org.apache.tools.bzip2.CBZip2OutputStream.doReversibleTransformation(CBZip2OutputStream.java:1347)
at
org.apache.tools.bzip2.CBZip2OutputStream.endBlock(CBZip2OutputStream.java:438)
at
org.apache.tools.bzip2.CBZip2OutputStream.close(CBZip2OutputStream.java:389)
at X.main(X.java:5)
Example incorrect behavior of current code:
$ (echo -n BZ; java X) | bunzip2
bunzip2: Data integrity error when decompressing.
Input file = (stdin), output file = (stdout)
It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.
You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.
Behavior with this patch applied, bunzip2 creates zero-length output as
expected:
$ (echo -n BZ; java -cp .:/tmp/ant-svn/src/main X) | bunzip2 | wc -c
0
Note that last is set to -1 only in initBlock() which is called only from the
constructor and from writeRun(). However, after initBlock() is called from
writeRun(), writeRun() calls itself again and last is guaranteed not to be -1
afterwards. Therefore my last == -1 check is true only if the stream is empty,
and in all other cases the behavior is not changed.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45841] New: Classloader task - move log message
https://issues.apache.org/bugzilla/show_bug.cgi?id=45841 Summary: Classloader task - move log message Product: Ant Version: 1.7.1 Platform: PC OS/Version: Windows XP Status: NEW Severity: trivial Priority: P2 Component: Core tasks AssignedTo: notifications@ant.apache.org ReportedBy: [EMAIL PROTECTED] These two lines in execute(): acl.addPathElement(f.getAbsolutePath()); log(Adding to class loader + acl + + f.getAbsolutePath(), Project.MSG_DEBUG); should be reversed. Currently the path is added, then when the log message is displayed, the toString() of acl spits out the acl's full classpath, which already includes the path. This makes it look like it is already in there when adding. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45841] Classloader task - move log message
https://issues.apache.org/bugzilla/show_bug.cgi?id=45841 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-19 07:51:41 PST --- committed as svn rev 697116, thanks. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45836] [PATCH] For correct empty CBzip2OutputStream handling
https://issues.apache.org/bugzilla/show_bug.cgi?id=45836 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-19 08:05:11 PST --- patch committed as svn revision 697122, thanks! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45845] New: Possibly remove reverse() in Classloader task
https://issues.apache.org/bugzilla/show_bug.cgi?id=45845
Summary: Possibly remove reverse() in Classloader task
Product: Ant
Version: 1.7.1
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Core tasks
AssignedTo: notifications@ant.apache.org
ReportedBy: [EMAIL PROTECTED]
Can we drop one of these, I was trying both not realizing that they were
changing the same property, but in reverse.
/**
* Set reverse attribute.
* @param b if true reverse the normal classloader lookup.
*/
public void setReverse(boolean b) {
this.parentFirst = !b;
}
/**
* Set reverse attribute.
* @param b if true reverse the normal classloader lookup.
*/
public void setParentFirst(boolean b) {
this.parentFirst = b;
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 39189] signjar should permit selection of alternate executable
https://issues.apache.org/bugzilla/show_bug.cgi?id=39189 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added CC||notifications@ant.apache.org AssignedTo|notifications@ant.apache.org|[EMAIL PROTECTED] -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
DO NOT REPLY [Bug 39189] signjar should permit selection of alternate executable
https://issues.apache.org/bugzilla/show_bug.cgi?id=39189 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #3 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-19 08:28:51 PST --- supported starting with svn revision 697133. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 45820] IsSigned conditions doesn't work correctly for alias with invalid characters
https://issues.apache.org/bugzilla/show_bug.cgi?id=45820 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-19 08:53:38 PST --- svn revision 697139 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 45846] New: Ant 1.7.1 resolves UNC path file imports incorrectly on windows
https://issues.apache.org/bugzilla/show_bug.cgi?id=45846 Summary: Ant 1.7.1 resolves UNC path file imports incorrectly on windows Product: Ant Version: 1.7.1 Platform: PC OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: Core AssignedTo: notifications@ant.apache.org ReportedBy: [EMAIL PROTECTED] Hi, I have a core build file deployed on a network file system that is accessible from both windows and unix. This core build file is imported and used by a number of other project builds that just provide properties to configure the core build for usage. The core build file imports a number of other files containing utility macrodefs etc. These are deployed in the same directory as the core build (I use the dirname task to construct the import path for the other files). It uses UNC style paths to do this, for example: import file=//u/some/path/accessible/from/windows/and/unix/machines/build.xml/ Paths like this were handled without issue in ant 1.6.5. On unix the extra forward slash was irrelevant and on windows the path seps were flipped by java to yield a valid UNC path. However, if I run the following import on windows under a Java 6 VM with ant 1.7.1 I now get this error: Cannot find build-utils.xml imported from C:\u\some\path\accessible\from\windows\and\unix\machines\build.xml I have seen a related problem if I put ant on the path using a UNC path (e.g. if I deploy my ant install on a network drive). When I run ant I get this exception. java.lang.ClassNotFoundException: org.apache.tools.ant.Main at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:255) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) This goes if I map a network drive to the ant deployment directory and put it on the path using a path via this drive instead. Does anyone know what's going one here? Thanks, Miles -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45854] New: [PATCH] echoproperties: character encoding for text output
https://issues.apache.org/bugzilla/show_bug.cgi?id=45854
Summary: [PATCH] echoproperties: character encoding for text
output
Product: Ant
Version: 1.7.1
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Optional Tasks
AssignedTo: notifications@ant.apache.org
ReportedBy: [EMAIL PROTECTED]
I would like to modify only one line for the internationalization of
'echoproperties' optional task.
EchoProperties.java
508 protected void jdkSaveProperties(Properties props, OutputStream os,
509 String header) throws IOException {
510try {
511props.store(os, header);
512
513} catch (IOException ioe) {
511props.store(new OutputStreamWriter(os, UTF8), header);
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45499] DirectoryScanner infinitely recurses on symlinks to parent directories
https://issues.apache.org/bugzilla/show_bug.cgi?id=45499 --- Comment #9 from Tim Whittington [EMAIL PROTECTED] 2008-09-22 03:17:53 PST --- I downloaded and built the ant_20080922041906.tar.gz snapshot, and ran it against my build, and the compile now appears to complete successfully. I'd really like not to be spammed as much for my one offending symlink though (there's a bit of exponential explosion going on with the potential paths it gets to skip) In a probably unrelated issue, my build is now failing with the new snapshot (it appears to have broken a fairly innocuous looking AntX foreach, complaining the loop property isn't set). Log excerpt follows. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Home -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.4/Home/bundle/Home/bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.4/Home/bundle/Home/shared_bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.4/Home/shared_bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.4.1/Home/bundle/Home/bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.4.1/Home/bundle/Home/shared_bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.4.1/Home/shared_bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.4.2/Home/bundle/Home/bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.4.2/Home/bundle/Home/shared_bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.4.2/Home/shared_bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.5/Home/bundle/Home/bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.5/Home/bundle/Home/shared_bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.5/Home/shared_bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.5.0/Home/bundle/Home/bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.5.0/Home/bundle/Home/shared_bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.5.0/Home/shared_bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.6/Home/bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.6/Home/shared_bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.6.0/Home/bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/1.6.0/Home/shared_bundle -- too many levels of symbolic links. [javac] skipping symbolic link /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bundle/Home/shared_bundle/Versions/CurrentJDK/Home/bundle -- too many levels of symbolic links
DO NOT REPLY [Bug 45858] New: AntXtras foreach tasks fail with undefined loop variables
https://issues.apache.org/bugzilla/show_bug.cgi?id=45858
Summary: AntXtras foreach tasks fail with undefined loop
variables
Product: Ant
Version: 1.8Alpha (nightly)
Platform: PC
OS/Version: Mac OS X 10.4
Status: NEW
Severity: blocker
Priority: P1
Component: Other
AssignedTo: notifications@ant.apache.org
ReportedBy: [EMAIL PROTECTED]
Using nightly snapshot ant_20080922041906.tar.gz, my builds are failing where
they use the AntXtras (http://antxtras.sourceforge.net) callforeach/foreach
tasks (and possibly others - there's a heirarchy of tasks starting at 'call'
that this could apply to).
I'm using AntXtras 0.5.1 (the latest available build).
What appears to be happening is that the loop variable (defined as i= in the
task) is not being set.
This same build script works with Ant 1.6.x and 1.7.x.
Example build file that demonstrates this issue is:
?xml version=1.0?
project name=AntXTest default=build basedir=.
xmlns:antx=antlib:com.idaremedia.antx
description
Demonstrates breakage of Antx foreach task on Ant SVN snapshot
/description
property name=build.dir value=${basedir}/
!-- AntXtras Tasks from com/idaremedia/antx/antlib.xml --
taskdef resource=com/idaremedia/antx/antlib.xml
uri=antlib:com.idaremedia.antx
classpath
fileset dir=${build.dir}/antx
include name=JWare_apis.jar/
include name=AntX_tasks.jar/
/fileset
/classpath
/taskdef
target name=build
antx:foreach i=loop list=1,2,3,4 mode=local
echo message=Index is ${loop}/
/antx:foreach
/target
/project
And a verbose log of the foreach task failing to work:
Apache Ant version 1.8.0alpha compiled on September 22 2008
Buildfile:
/Users/archie/Projects/OrionPlatform/Tools/com.orchestral.common.hibernate3/build.xml
Detected Java version: 1.6 in:
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Detected OS: Mac OS X
parsing buildfile
/Users/archie/Projects/OrionPlatform/Tools/com.orchestral.common.hibernate3/build.xml
with URI =
file:/Users/archie/Projects/OrionPlatform/Tools/com.orchestral.common.hibernate3/build.xml
Project base dir set to:
/Users/archie/Projects/OrionPlatform/Tools/com.orchestral.common.hibernate3
parsing buildfile
jar:file:/Users/archie/Downloads/ant/dist/lib/ant.jar!/org/apache/tools/ant/antlib.xml
with URI =
jar:file:/Users/archie/Downloads/ant/dist/lib/ant.jar!/org/apache/tools/ant/antlib.xml
parsing buildfile
jar:file:/Users/archie/Projects/OrionPlatform/Tools/com.orchestral.common.hibernate3/antx/AntX_tasks.jar!/com/idaremedia/antx/antlib.xml
with URI =
jar:file:/Users/archie/Projects/OrionPlatform/Tools/com.orchestral.common.hibernate3/antx/AntX_tasks.jar!/com/idaremedia/antx/antlib.xml
[antlib:com.idaremedia.antx] Could not load definitions from resource
com/idaremedia/antx/antlib.xml. It could not be found.
[presetdef] defining preset antlib:com.idaremedia.antx:macrolocals
[presetdef] defining preset antlib:com.idaremedia.antx:macroisolate
[presetdef] defining preset antlib:com.idaremedia.antx:looplocals
[presetdef] defining preset antlib:com.idaremedia.antx:loopisolate
[presetdef] defining preset antlib:com.idaremedia.antx:pathproperty
[presetdef] defining preset antlib:com.idaremedia.antx:true
Build sequence for target(s) `build' is [build]
Complete build sequence is [build, ]
build:
[macrodef] creating macro foreach622517_macrodef
Property loop has not been set
[echo] Index is ${loop}
Property loop has not been set
[echo] Index is ${loop}
Property loop has not been set
[echo] Index is ${loop}
Property loop has not been set
[echo] Index is ${loop}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45860] New: Optional classpath entry support for FTP task
https://issues.apache.org/bugzilla/show_bug.cgi?id=45860 Summary: Optional classpath entry support for FTP task Product: Ant Version: 1.7.1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P1 Component: Optional Tasks AssignedTo: notifications@ant.apache.org ReportedBy: [EMAIL PROTECTED] Using the optional FTP tasks, requires the installation of optional libraries into Ant's classpath. I would suggest enhancing the FTP task, so that the optional libraries can be referenced with a classpath entry element in the same way as the JUnit task. I will be happy to make the enhancement. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45861] New: Add new ant.host.* properties (code included)
https://issues.apache.org/bugzilla/show_bug.cgi?id=45861
Summary: Add new ant.host.* properties (code included)
Product: Ant
Version: 1.7.1
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: enhancement
Priority: P2
Component: Core
AssignedTo: notifications@ant.apache.org
ReportedBy: [EMAIL PROTECTED]
Can we add these useful properties:
MagicNames.java
public static final String ANTHOSTADDRESS_PROPERTY =
ant.host.address;
public static final String ANTHOSTNAME_PROPERTY = ant.host.name;
public static final String ANTHOSTQNAME_PROPERTY = ant.host.qname;
Project.java
import java.net.InetAddress;
public void initProperties() throws BuildException {
{
...
try
{
InetAddress rInetAddress =
InetAddress.getLocalHost();
System.setProperty(ANTHOSTADDRESS_PROPERTY,
rInetAddress.getHostAddress());
System.setProperty(ANTHOSTNAME_PROPERTY,
rInetAddress.getHostName());
System.setProperty(ANTHOSTFULLNAME_PROPERTY,
rInetAddress.getCanonicalHostName());
}
catch (UnknownHostException e)
{
System.setProperty(ANTHOSTADDRESS_PROPERTY, 0.0.0.0);
System.setProperty(ANTHOSTNAME_PROPERTY, localhost);
System.setProperty(ANTHOSTQNAME_PROPERTY, localhost);
}
...
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 29683] Jar task with zipgroupfileset always builds the jar file
https://issues.apache.org/bugzilla/show_bug.cgi?id=29683 Emmanuel Bourg [EMAIL PROTECTED] changed: What|Removed |Added Version|1.6.1 |1.7.1 --- Comment #4 from Emmanuel Bourg [EMAIL PROTECTED] 2008-09-23 03:45:37 PST --- Here is the trace when Ant is run with the -v option: [jar] foo omitted as C:\anttest\foo.jar:foo/ is up to date. [jar] foo\Bar.java omitted as C:\anttest\foo.jar:foo/Bar.java is up to date. [jar] foo added as foo/ is outdated. [jar] foo\BarTest.java omitted as C:\anttest\foo.jar:foo/BarTest.java is up to date. [jar] Building jar: C:\anttest\foo.jar [jar] adding directory META-INF/ [jar] adding entry META-INF/MANIFEST.MF [jar] adding directory foo/ [jar] adding entry foo/Bar.java [jar] adding entry foo/BarTest.java [jar] No Implementation-Title set.No Implementation-Version set.No Implementation-Vendor set. [jar] Location: C:\anttest\build.xml:6: The foo directory in src/test is more recent than foo in src/main, that may explain why the task thinks it has been updated and rebuilds the jar. If the two fileset are inverted the jar is no longer rebuild. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 29683] Jar task with zipgroupfileset always builds the jar file
https://issues.apache.org/bugzilla/show_bug.cgi?id=29683 Emmanuel Bourg [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #3 from Emmanuel Bourg [EMAIL PROTECTED] 2008-09-23 03:35:17 PST --- This is not specific to zipfileset, it also happens with filesets having similar directory structures. For example, considering this simple project layout: /src/main/foo/Bar.java /src/test/foo/BarTest.java The following build file will always build the jar file: ?xml version=1.0 encoding=iso-8859-1? project name=Bug 29683 testcase default=jar basedir=. target name=jar jar jarfile=foo.jar fileset dir=src/main/ fileset dir=src/test/ /jar /target /project This was verified on Windows XP with Ant 1.7.1 and Java 5 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 29683] Jar task with zipgroupfileset always builds the jar file
https://issues.apache.org/bugzilla/show_bug.cgi?id=29683 --- Comment #5 from Emmanuel Bourg [EMAIL PROTECTED] 2008-09-23 04:23:23 PST --- Another workaround is to set the filesonly attribute to 'true' on the jar task: jar jarfile=foo.jar filesonly=true fileset dir=src/main/ fileset dir=src/test/ /jar -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43586] java.io.FileNotFoundException: /home/***/apache-ant-1.7.0/junitvmwatcher *** .properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=43586 Gerry Plummer [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #11 from Gerry Plummer [EMAIL PROTECTED] 2008-09-23 06:11:46 PST --- I have stumbled on what I believe may be another common cause of this bug. This can happen if Ant's junit task is run with fork=yes in default forkmode, and you pass in a jvmarg element which has an empty string as value. We have a common Ant framework script used by multiple projects, with properties driving the specific project's behavior. E.g. our build uses this fragment: jvmarg value=junit.jvmarg.project/ jvmarg value=junit.jvmarg.internal/ where the latter is always defined (by the framework) and the former can be supplied by users. When we split the jvmargs into these two elements, of course there was a reason, and at the time both properties had values. Subsequent usages sometimes broke, because the client project did not provide a property definition of junit.jvmarg.project with a non-empty value (the project's definition being seen first, the framework's definition having the empty string as default value). That was a recipe for the issue reported in this bug. The specific Ant/Junit problem can be seen when running Ant with the -debug option, producing output like this (---scrubbed---): [junit] Executing '/usr/java/jdk1.6.0_07/jre/bin/java' with arguments: [junit] '' [junit] '-Dcom.foo=NONE [junit] '-classpath' [junit] --- classpath elements here --- [junit] 'org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner' [junit] --- Test class here --- [junit] 'filtertrace=true' [junit] 'haltOnError=false' [junit] 'haltOnFailure=false' [junit] 'formatter=org.apache.tools.ant.taskdefs.optional.junit.SummaryJUnitResultFormatter' [junit] 'showoutput=false' [junit] 'outputtoformatters=true' [junit] 'logtestlistenerevents=true' [junit] 'formatter=org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormatter,/---Test xml file here --- [junit] 'crashfile=/---some-path-here---/junitvmwatcher602965515.properties' [junit] 'propsfile=/---some-path-here---/junit1771756651.properties' [junit] [junit] The ' characters around the executable and arguments are [junit] not part of the command. Note the empty string on the line immediately after the Executing. That is the empty string contributed by the first jvmarg element, from the empty-string-valued junit.jvmarg.project property. The line with -Dcom.foo=NONE was contributed by the second jvmarg element, the junit.jvmarg.internal having this (phony) value. The JVM crashed because of this empty (1st) argument. If we define a non-empty value for junit.jvmarg.project the problem goes away (the empty line being replaced by something the JVM will swallow, like -Djunk=ignore. The underlying Ant problem (yes I think there is one) is that it doesn't check for empty arguments like this before running the JVM. I think it should do so, because the consequences are so pernicious and difficult to debug, and their seem to be no benefit. Specifically, I suggest the CommandlineJava class (instances of which are used by JUnitTask.executeAsForked() to represent the forked JVM command to run) should, somewhere in the conversion of the constituents of the command to a List of command elements (Strings), if there is an empty string it should perhaps be skipped over. Or, more narrowly, te Java13CommandLauncher inner class could deal with the issue since it's that launcher that seems to be the last place to do so. Furthermore, it seems that some improved error handling could be used here. There are no failures detected by the Execute nor JUnitTask classes in running the JVM which summarily exits. But (as is seen at the top of this bug) neither is there valid information about a JVM crash in the junitvmwatcher*.properties file (which doesn't exist). We simply see an exception from Ant with no hint to the uninitiated (and a lot of debugging for those who may be). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45845] Possibly remove reverse() in Classloader task
https://issues.apache.org/bugzilla/show_bug.cgi?id=45845 --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-25 04:57:20 PST --- we can deprecate one but drop neither since they are part of the published public API and we try to not break backwards compatibility. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45845] Possibly remove reverse() in Classloader task
https://issues.apache.org/bugzilla/show_bug.cgi?id=45845 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45830] Cannot overwrite the older entry in the archive
https://issues.apache.org/bugzilla/show_bug.cgi?id=45830 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45847] Classloader task - duplicate path elements added
https://issues.apache.org/bugzilla/show_bug.cgi?id=45847 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-25 05:26:50 PST --- the second block only isn't needed if the task isn't modifying an existing classloader. fixed in svn rev 698943. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45850] Built in properties list needs 2 updates
https://issues.apache.org/bugzilla/show_bug.cgi?id=45850 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-25 05:44:57 PST --- svn revision 698949, thanks! won't appear online before Ant 1.8.0 has been released, though. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45854] [PATCH] echoproperties: character encoding for text output
https://issues.apache.org/bugzilla/show_bug.cgi?id=45854 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-25 05:47:39 PST --- Properties#store(Writer, String) has been introduced in JDK 1.6, which is way to recent for Ant's JDK compatibility rules (Ant 1.8.0 must be compatible with 1.4 IIRC). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45499] DirectoryScanner infinitely recurses on symlinks to parent directories
https://issues.apache.org/bugzilla/show_bug.cgi?id=45499 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-25 05:55:46 PST --- more recent versions will allow the same symlink to be traversed more often (to reduce the performance and memory impact of the tests), so your build will consume a bit more memory. We might lower the log priority, by writing the message to System.out, but it would probably remain visible anyway. I'm afraid there isn't much we can do. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 42275] running ant off a network share can cause Ant to fail
https://issues.apache.org/bugzilla/show_bug.cgi?id=42275 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] ||om --- Comment #9 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-25 06:47:32 PST --- *** Bug 45846 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45846] Ant 1.7.1 resolves UNC path file imports incorrectly on windows
https://issues.apache.org/bugzilla/show_bug.cgi?id=45846 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Target Milestone|--- |1.8.0 --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-25 06:47:32 PST --- I can confirm this behavior in 1.7.1 and can confirm it is fixed in trunk. *** This bug has been marked as a duplicate of bug 42275 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 40457] failureproperty not set by TestSuite
https://issues.apache.org/bugzilla/show_bug.cgi?id=40457
Stefan Bodewig [EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||WORKSFORME
--- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-25 07:17:46 PST
---
it may be the specific TestSuite, but with
public class ATest extends TestSuite {
public ATest() {
super(test.ATest.class);
}
public void testFail() {
Assert.assertTrue(false);
}
}
I get a failureproperty. See the testFailurePropertyOnTest(Suite|Case) tests
in
http://svn.apache.org/repos/asf/ant/core/trunk/src/tests/antunit/taskdefs/optional/junit/junit-test.xml
works in trunk, at least.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
DO NOT REPLY [Bug 45848] AntClassLoader missing a test before adding a path component
https://issues.apache.org/bugzilla/show_bug.cgi?id=45848
--- Comment #2 from Robert Flaherty [EMAIL PROTECTED] 2008-09-25 07:18:56
PST ---
Sure, I really meant the contains test. So I assume you changed to:
if (pathComponents.contains(file)) {
pathComponents.addElement(pathComponent);
}
Maybe it would be cleaner for the two to be in sync and have addPathComponent
do that also.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45845] Possibly remove reverse() in Classloader task
https://issues.apache.org/bugzilla/show_bug.cgi?id=45845 --- Comment #2 from Robert Flaherty [EMAIL PROTECTED] 2008-09-25 07:22:52 PST --- The only reason I thought drop was b/c it was listed as EXPERIMENTAL in the comment block. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45044] CBZip2OutputStream does not work in combination with ByteArrayOutputStream
https://issues.apache.org/bugzilla/show_bug.cgi?id=45044
Stefan Bodewig [EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||WORKSFORME
Target Milestone|--- |1.7.1
--- Comment #5 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-25 07:39:58 PST
---
project
echo file=TestBZip.java![CDATA[
import org.apache.tools.bzip2.*;
import java.io.*;
public class TestBZip {
public static void main(String[] args) throws Throwable {
BufferedInputStream in = new BufferedInputStream(new
FileInputStream(bzip.xml));
ByteArrayOutputStream byteOut = new ByteArrayOutputStream();
CBZip2OutputStream outFail = new CBZip2OutputStream(byteOut);
FileOutputStream fos = new FileOutputStream(bzip.xml.bz2);
CBZip2OutputStream outOk = new CBZip2OutputStream(fos);
byte[] bs = new byte[1024];
int l = in.read(bs);
while (l == 1024)
{
outFail.write(bs);
outOk.write(bs);
l = in.read(bs);
}
if (l 0)
{
outFail.write(bs, 0, l);
outOk.write(bs, 0, l);
}
outFail.flush();
outOk.flush();
in.close();
// FAIL
// at this point, byteOut.toByteArray() has always length 1
outFail.close();
outOk.close();
int len = byteOut.toByteArray().length;
System.out.println(length: + len);
if (len 1) {
System.exit(0);
} else {
System.exit(1);
}
}
}
]]/echo
javac srcdir=. destdir=. includes=TestBZip.java/
java classname=TestBZip classpath=.;${java.class.path} fork=true/
/project
with Ant 1.7.1 leads to
$ ant -f ../../Temp/bzip.xml
Buildfile: ..\..\Temp\bzip.xml
[javac] Compiling 1 source file to c:\Temp
[java] length: 650
BUILD SUCCESSFUL
Total time: 0 seconds
which looks OK since the file is 650 bytes as well.
Seems to have been fixed for 1.7.1.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45845] Possibly remove reverse() in Classloader task
https://issues.apache.org/bugzilla/show_bug.cgi?id=45845 --- Comment #3 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-25 07:44:10 PST --- sure, we thought that would scare people away from the class. But still some seem to have found and even started to report bugs against it ;-) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45845] Possibly remove reverse() in Classloader task
https://issues.apache.org/bugzilla/show_bug.cgi?id=45845
--- Comment #4 from Robert Flaherty [EMAIL PROTECTED] 2008-09-25 08:05:08
PST ---
I know I know, actually I was desperate and searched the code b/c I couldn't
find what I needed in the published manual tasks. And actually, someone else
put in a bug report for it a few days after I started working up a workaround
with the classloader task. I'll submit that in a few days, as it will be quite
lengthy I think (getting FTP to work without ANT_HOME/lib or
${user.home}/.ant/lib, but rather classloader, path, classpath, etc).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DO NOT REPLY [Bug 45094] Token substitution problem - where file includes literal character the same as the token
https://issues.apache.org/bugzilla/show_bug.cgi?id=45094 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-25 08:28:31 PST --- I can see the reason. when looking for the begin token in username@@@HOST@@ ant will stop at the first two @ and determine that it doesn't have a replacement for @HOST and continues looking for a begin token after the last candidate begin token - while your real begin token actually starts inside the first candidate token. fixed in svn rev 699002. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45845] Possibly remove reverse() in Classloader task
https://issues.apache.org/bugzilla/show_bug.cgi?id=45845 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-26 02:53:42 PST --- OK, reverse is deprecated now. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44726] selectors on remote FTP directories
https://issues.apache.org/bugzilla/show_bug.cgi?id=44726 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added CC||notifications@ant.apache.org AssignedTo|notifications@ant.apache.org|[EMAIL PROTECTED] Severity|normal |enhancement Keywords||PatchAvailable Target Milestone|--- |1.8.0 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
DO NOT REPLY [Bug 44873] Mapper behaviour is different when using Java 6
https://issues.apache.org/bugzilla/show_bug.cgi?id=44873 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added CC||notifications@ant.apache.org AssignedTo|notifications@ant.apache.org|[EMAIL PROTECTED] Status|ASSIGNED|NEW -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
DO NOT REPLY [Bug 45716] UpToDate logging is misleading
https://issues.apache.org/bugzilla/show_bug.cgi?id=45716 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added CC||notifications@ant.apache.org AssignedTo|notifications@ant.apache.org|[EMAIL PROTECTED] -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
DO NOT REPLY [Bug 44873] Mapper behaviour is different when using Java 6
https://issues.apache.org/bugzilla/show_bug.cgi?id=44873 --- Comment #4 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-26 03:37:51 PST --- The composite mapper has two results, since one glob mapper and the identity mapper match. copy only uses the first result (enablemultiplemappings is false by default). The documentation of composite mapper doesn't talk about the order of results and in fact it uses a set in its implementation, making sort order depend on the Java VM (or the phase of the moon). We could fix that without breaking anything, and I think I'll do that. In your case you really want something else, you want some sort of composite mapper where only the first match is used. We don't have anything like this in Ant right now. Therefore I will first create a stable sort order and then change this report to an enhancement request for a different kind of composite mapper. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 44873] Add a firstmatch composite mapper
https://issues.apache.org/bugzilla/show_bug.cgi?id=44873 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement Summary|Mapper behaviour is |Add a firstmatch composite |different when using Java 6 |mapper Target Milestone|--- |1.8.0 --- Comment #5 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-26 03:52:53 PST --- compositemapper's sort order is stable with svn revision 699263. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 45716] UpToDate logging is misleading
https://issues.apache.org/bugzilla/show_bug.cgi?id=45716 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #1 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-26 04:36:08 PST --- svn revision 699282. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 44873] Add a firstmatch composite mapper
https://issues.apache.org/bugzilla/show_bug.cgi?id=44873 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-26 05:01:05 PST --- firstmatchmapper is in svn rev 699288. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 45181] Added a timeout option to get task
https://issues.apache.org/bugzilla/show_bug.cgi?id=45181 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #2 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-26 06:55:38 PST --- used a different implementation that I hope to be more robust. svn revision 699324. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 44726] selectors on remote FTP directories
https://issues.apache.org/bugzilla/show_bug.cgi?id=44726 Stefan Bodewig [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Stefan Bodewig [EMAIL PROTECTED] 2008-09-26 07:20:55 PST --- a slightly modified version of your patch (mainly making it more compliant with our predominant coding style) went in as svn revision 699336. Thanks! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 45902] New: Up-to-date checks for JARs broken due to comparison of dir timestamps
https://issues.apache.org/bugzilla/show_bug.cgi?id=45902 Summary: Up-to-date checks for JARs broken due to comparison of dir timestamps Product: Ant Version: 1.7.1 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Core tasks AssignedTo: notifications@ant.apache.org ReportedBy: [EMAIL PROTECTED] If you follow the (rather complex) instructions in http://www.netbeans.org/nonav/issues/show_bug.cgi?id=142466 you can (sometimes) reproduce a regression in Ant 1.7.1; samples/admin/target/useradmin-shared.jar is recreated during incremental builds. The log for this jar task says net/java omitted as /tmp/genesis-3.1/samples/admin/target/useradmin-shared.jar:net/java/ is up to date. net/java/dev omitted as /tmp/genesis-3.1/samples/admin/target/useradmin-shared.jar:net/java/dev/ is up to date. net/java/dev/genesis omitted as /tmp/genesis-3.1/samples/admin/target/useradmin-shared.jar:net/java/dev/genesis/ is up to date. net omitted as /tmp/genesis-3.1/samples/admin/target/useradmin-shared.jar:net/ is up to date. net/java omitted as /tmp/genesis-3.1/samples/admin/target/useradmin-shared.jar:net/java/ is up to date. net/java/dev omitted as /tmp/genesis-3.1/samples/admin/target/useradmin-shared.jar:net/java/dev/ is up to date. net/java/dev/genesis omitted as /tmp/genesis-3.1/samples/admin/target/useradmin-shared.jar:net/java/dev/genesis/ is up to date. net added as net/ is outdated. net/java added as net/java/ is outdated. net/java/dev added as net/java/dev/ is outdated. net/java/dev/genesis added as net/java/dev/genesis/ is outdated. The problem occurs only when directories are added to the JAR file. Uncommenting if (target.isDirectory()) return false; from ResourceUtils.selectOutOfDateSources' ResourceSelector.isSelected impl causes the issue not to appear; the problem seems to relate to a ZipResource .../admin/target/useradmin-shared.jar:net/ always being OOD relative to a FileResource .../admin/modules/shared/target/hibernate/net. Of course uncommenting that line would regress performance of many tasks. I'm not sure why we are even checking timestamps on ZIP folders; surely these do not matter to begin with? There is if (doFilesonly) resources = selectFileResources(resources); in Zip.java but I do not understand why this is conditional; seems to me that this should be run even if !doFilesonly. Making this unconditional might fix the issue for me; I am not sure because now I can no longer reproduce the original problem (seems to come and go). The build script is too complex for me to follow. The problem may be ultimately due to some user error in the script. But I think I am out of my depth with the new resource collection code which I can barely follow. BTW (probably unrelated to this bug): peterreilly changed my code in SelectorUtils.isOutOfDate to create a sourceExists local variable - but it is unused! Perhaps there is a missing if (!sourceExists) return false; ? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45902] Up-to-date checks for JARs broken due to comparison of dir timestamps
https://issues.apache.org/bugzilla/show_bug.cgi?id=45902 Michel Graciano [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
