You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by bu...@apache.org on 2010/07/15 14:48:11 UTC
DO NOT REPLY [Bug 49596] New: preceding / modifies fileset result
https://issues.apache.org/bugzilla/show_bug.cgi?id=49596
Summary: preceding / modifies fileset result
Product: Ant
Version: 1.8.1
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: critical
Priority: P2
Component: Core
AssignedTo: notifications@ant.apache.org
ReportedBy: vlad.balan@gmail.com
Hello,
this is the xml file:
<?xml version="1.0" encoding="UTF-8"?>
<project name="bug-fileset">
<property name="input_place" value="d:/kits/test" />
<patternset id="firstFiles">
<include name="/beta/**/*.txt" />
<exclude name="/beta/**/*_*.txt" />
</patternset>
<fileset id="input_fileSet" dir="${input_place}">
<patternset refid="firstFiles" />
</fileset>
<target name="echo">
<echo>Content of input_fileSet: ${toString:input_fileSet}</echo>
</target>
</project>
Steps to reproduce
1. on the file system in "d:kits/test/", create some files like
"beta/beta.txt", "beta/gamma/gamma.txt", "beta/gamma/gamma_2.txt"
Results with the preceding "/" in "include":
[echo] Content of input_fileSet: beta\beta.txt
Conclusion: the filset above (<include name="/beta/**/*.txt" />
) will LIMIT the search to the "beta" folder's direct child files, even if
there is a "**/" after it indicating to search the subdirs. If you remove the
starting slash, than it goes in beta's subdirectories, like it should:
[echo] Content of input_fileSet: beta\beta.txt;beta\gamma\gamma.txt
This does not appear to happen for the "exclude". With or without the starting
"/" in exclude, it searches the subdirs too. I can see this because
"beta/gamma/gamma_2.txt" never shoes when the "include" searches the subdirs
(not starting with "/")
This is a bug because the starting "/" cannot have an effect on a subsequent
"/**".
--
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 49596] preceding / modifies fileset result
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49596
--- Comment #9 from vlad.balan@gmail.com 2010-08-08 04:29:08 EDT ---
(In reply to comment #8)
> Vlad, please use the user mailing list for questions, the issue tracker is the
> wrong place for this.
OK, i know your are right.
> I don't know which question about an error you need to get answered. You point
> out an error in the manual but don't tell us which page of the manual contains
> the error (the URL you've given is the URL of a frameset that doesn't identify
> the individual page).
I'm sorry, i didn't see in copies the url of the framset. The page is this:
List of types/ File Mappers. The error in the 3rd example from the bottom that
i suspect is this:
... from="src${file.separator}*.file" ... should be ...
from="{file.separator}*.file" ...
Look at this one and at the last who says
... redirect STDIN; fileset collects relative to its dir, but we need ...
... relative to basedir ...
<inputmapper type="glob" from="*" to="src/*"/>
> WRT comment 7:
> If the nested mapper returns an absolute path, then dest is ignored. And like
> the manual says, if you don't provide a dest attribute, the mapper must return
> absolute paths.
> The case of outputmapper is different since the outputmapper doesn't know the
> dest attribute at all - to work reliably the outputmapper should always return
> absolute paths.
Thank you.
--
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 49596] preceding / modifies fileset result
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49596
--- Comment #6 from vlad.balan@gmail.com 2010-08-08 03:58:21 EDT ---
There's a question (about an error) and a request for confirmation (what a
mapper receives and gives).
Thank you very much for the confirmation. Now it remains the question.
--
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 49596] preceding / modifies fileset result
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49596
Stefan Bodewig <bo...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Version|1.8.1 |1.7.1
Resolution| |FIXED
Target Milestone|--- |1.8.0
--- Comment #4 from Stefan Bodewig <bo...@apache.org> 2010-08-07 16:50:32 EDT ---
(In reply to comment #3)
> Sorry to post this here hoping you will be reading this.
> I think there is a error in the 3rd example from the bottom on this manual page
>
> http://ant.apache.org/manual/index.html
which one?
> Apparenlty a mapper receives a file in the form of its segments of the file
> name after the fileset's dir.
>
> Ex: for a file "D:a/b/c.txt" obtained from <fileset dir="D:/a"
> includes="**/*.txt"/>
>
> the mapper will receive "b/c.txt"
In case of a fileset, yes. For other resource collections it may receive the
absolute path.
> In contrast, the nesting task of a fileset, like the "apply" task for example,
> knows to obtain the complete file name: "D:a/b/c.txt".
Yes, the task resolves it (with the help of fileset.getDir())
--
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 49596] preceding / modifies fileset result
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49596
--- Comment #3 from vlad.balan@gmail.com 2010-08-07 16:45:16 EDT ---
Sorry to post this here hoping you will be reading this.
I think there is a error in the 3rd example from the bottom on this manual page
http://ant.apache.org/manual/index.html
regarding: from="src${file.separator}*.file"
Look at this one and at the last who says
<!-- redirect STDIN; fileset collects relative to its dir, but we need -->
<!-- relative to basedir -->
<inputmapper type="glob" from="*" to="src/*"/>
So in the 3rd example there should be: from="{file.separator}*.file"
Apparenlty a mapper receives a file in the form of its segments of the file
name after the fileset's dir.
Ex: for a file "D:a/b/c.txt" obtained from <fileset dir="D:/a"
includes="**/*.txt"/>
the mapper will receive "b/c.txt"
In contrast, the nesting task of a fileset, like the "apply" task for example,
knows to obtain the complete file name: "D:a/b/c.txt".
Is this conclusion right?
--
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 49596] preceding / modifies fileset result
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49596
--- Comment #2 from vlad.balan@gmail.com 2010-08-07 16:18:22 EDT ---
(In reply to comment #1)
> Created an attachment (id=25861)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25861) [details]
> more complete testcase
> The attachment is your originial build file plus a mkdir and three touch-tasks
> to set up the environment.
> Things are different on Windows than Unix and this is to be expected.
> On Unix the leading slash turns the patterns into absolute paths and so they
> are mo longer resolved relative to ${input_place}. You don't expect to match
> anything with slashes and expect beta.txt and gamma.txt to be matched without
> the leading slashes and this is just what happens.
> On Windows I've replaced /tmp with C:/temp and I get the same result - beta.txt
> and gamma.txt with and without leading slashes. I cannot reproduce what you
> describe.
You are right, it works on 1.8, it only happened on Ant 1.7.1 20090120. The
other bug i had tested it on 1.8 and 1.7.1 and failed on both.
the point is to have a preceding "/", like this: <include name="/beta/**/*.txt"
/>
If it is of any interest you can test on this version.
Pls. excuse me for your time.
--
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 49596] preceding / modifies fileset result
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49596
vlad.balan@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vlad.balan@gmail.com
--
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 49596] preceding / modifies fileset result
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49596
--- Comment #5 from vlad.balan@gmail.com 2010-08-08 03:53:09 EDT ---
Here's my message again:
Sorry to post this here hoping you will be reading this.
I think there is a error in the 3rd example from the bottom on this manual page
http://ant.apache.org/manual/index.html
regarding: from="src${file.separator}*.file"
Look at this one and at the last who says
... redirect STDIN; fileset collects relative to its dir, but we need ...
... relative to basedir ...
<inputmapper type="glob" from="*" to="src/*"/>
So in the 3rd example there should be: from="{file.separator}*.file"
Apparenlty a mapper receives a file in the form of its segments of the file
name after the fileset's dir.
Ex: for a file "D:a/b/c.txt" obtained from <fileset dir="D:/a"
includes="**/*.txt"/>
the mapper will receive "b/c.txt"
In contrast, the nesting task of a fileset, like the "apply" task for example,
knows to obtain the complete file name: "D:a/b/c.txt".
Is this conclusion right?
--
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 49596] preceding / modifies fileset result
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49596
--- Comment #8 from Stefan Bodewig <bo...@apache.org> 2010-08-08 04:19:09 EDT ---
Vlad, please use the user mailing list for questions, the issue tracker is the
wrong place for this.
I don't know which question about an error you need to get answered. You point
out an error in the manual but don't tell us which page of the manual contains
the error (the URL you've given is the URL of a frameset that doesn't identify
the individual page).
WRT comment 7:
If the nested mapper returns an absolute path, then dest is ignored. And like
the manual says, if you don't provide a dest attribute, the mapper must return
absolute paths.
The case of outputmapper is different since the outputmapper doesn't know the
dest attribute at all - to work reliably the outputmapper should always return
absolute paths.
--
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 49596] preceding / modifies fileset result
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49596
--- Comment #10 from vlad.balan@gmail.com 2010-08-08 04:41:11 EDT ---
Again i missled you, the page is that of the exec task, not of the file
mappers.
--
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 49596] preceding / modifies fileset result
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49596
--- Comment #1 from Stefan Bodewig <bo...@apache.org> 2010-08-07 15:28:33 EDT ---
Created an attachment (id=25861)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25861)
more complete testcase
The attachment is your originial build file plus a mkdir and three touch-tasks
to set up the environment.
Things are different on Windows than Unix and this is to be expected.
On Unix the leading slash turns the patterns into absolute paths and so they
are mo longer resolved relative to ${input_place}. You don't expect to match
anything with slashes and expect beta.txt and gamma.txt to be matched without
the leading slashes and this is just what happens.
On Windows I've replaced /tmp with C:/temp and I get the same result - beta.txt
and gamma.txt with and without leading slashes. I cannot reproduce what you
describe.
--
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 49596] preceding / modifies fileset result
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49596
--- Comment #7 from vlad.balan@gmail.com 2010-08-08 04:05:21 EDT ---
Comming a little back to your reply about the request for confirmation:
> Yes, the task resolves it (with the help of fileset.getDir())
1. In the case of "apply"'s nested mapper (for computing the so called
dependency le), it's with the help of the "dest" attribute or, in the absence
of dest, the base directory, right? Rather than the dir of the fileset.
2. And in the case of a mapper nested in a redirector, like outputmapper, it's
with the help of the base directory only, like the last example in that manual
page says.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.