DO NOT REPLY [Bug 25776] - Ant requires

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25776

Ant requires 
tag, since it needs to inspect it to find the encoding of the file and then it 
needs to restart reading using the proper encoding. So I do not think the spec 
allows putting an undetermined amount of white chars before the tag.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25777] - [PATCH] [REGRESSION] Cannot pass composite path reference between scripts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25777

[PATCH] [REGRESSION] Cannot pass composite path reference between scripts





--- Additional Comments From [EMAIL PROTECTED]  2003-12-29 11:17 ---
I defenitely think that Peter removal of the toString() was the right thing to 
do. This was not just some optimization, it was a superflous call causing a 
20% time increase in some builds. Not peanuts at all. (And maskerading a real 
bug, the one you have found).

I would like to find a solution that applies to all references, not only Paths.
It seem to me what is missing is for  to call some form of "resolve" 
method, when passing a reference. So, instead of just a call to clone() we 
would do a call to something like cloneAndResolve() that will perhaps use 
something simillar to dieOnCircularReference to resolve all inner references 
of the object.

I guess in principle you only need to do this when references are passed 
explicitly and inheritRefs=false; when inheritRefs=true, it may not be needed.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory utilization on ANT 1.6.0

[Jose Alberto Fernandez]

I think the two ways of reusing tasks that you point below
are fair usage, however that do not answer my question about
.

For the issue of reusability itself, let me point how I think it
should work on the cases you mentioned:

(1) If one IDs a task, we are really setting the ID on the 
UnknownObject(?) since we cannot resolve it at parsing time.
So when a script accesses the reference the resolution process
will create the actual task instance. As long as the script keeps
the actual task, well it will not be reclaimed. But if the 
reference is acessed on the project instance again, then you should get
a new task (i.e., UnknownObject should not keep internal references, 
it should be stateless).

(2) If your java task creates another task directly and uses it,
well it is upto you to make sure you dispose of it when you are
finish with it (i.e., do not keep it in some static table forever),
whether a task is design to be executed multiple times or not
is part of the task behaviour and is a separate issue.

My point is that ANT itself should not be keeping around
objects that it will not access again. I guess I am suggesting
to stop having resolved tasks and unresolve UnknownObjects as part
of the project tree, and instead have UnknownObjects all across.
It is really our DOM tree after all. 

> From: Dominique Devienne [mailto:[EMAIL PROTECTED] 
> 
> 
> I can see two ways for a task to be reused:
> 
> 1) thru the controversial use of IDs on tasks,
>which can then be executed by 

XML Namespace avoids collision between xml vocabularies was RE: a comment about xml namespace

[Jim Fuller]

> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> Sent: 23 December 2003 11:44
> Subject: RE: a comment about xml namespace

> Given the above, what do you mean by namespaces "ANT does not know"

[Jim Fuller] Ant has no concept of what to do with 'other' namespaces
other then treat them as an error. XML namespaces is being used as an
abstraction to assist Ant extensibility, e.g. with respect to Antlib
etc... . XML namespaces were originally conceived as a method to allow
for multiple xml vocabularies to co-exist in the same XML document w/o
collision. A tertiary argument for allowing xml namespaces is that it
naturally segregates work to xml vocabularies that are more adept at
some purposethats why we have the wide range of ML's around today;
why continually add more elements to Ant when other xml vocabularies
will do? 

> about? Given (3) ANT cannot just ignore it, since it may be
> a typo of some sort. There is not such a thing as an ignorable

[Jim Fuller] Ant could 'ignore' it if it had a schema or DTD which Ant
would use ( perhaps it does, have not plumbed that deep into the code
yet)...since Ant does use an xml build file, why not validate it against
a schema...ok perhaps the problem here would be keeping up with schema
definition with extended tasks...or asking developers to provide
one...though XML Schema could simply accommodate for build file specific
macrodef, presetdef, antlib, taskdef situationsperhaps I am speaking
out of turn and all of this is in the pipeline for future versions.

> namespace (unless we define a way to tell to ANT to ignore it).

[Jim Fuller] I would propose to have an 'explicit' definition which
declares exactly what xml namespaces ant will process with all other
namespaced xml ( that may exist in an ant build file )to be ignored by
Ant. There maybe a few other Ant commandline switches or properties
needed to control this behavior.
 
> I see two ways here:
> 1) The already mentioned task Or type
>  or better  in which you may be able to include any 
> XML you like. And hence keep anotations away boxed-off.
> 
>   
> ...
>   

[Jim Fuller] yuk...why use namespaces at all if the intentions is to
introduce 'yet another mechanism' to avoid collision ??? I have
mentioned only a few use cases...pls don't think that they are purely
annotations(yes meta data) i.e. use cases are not necessarily benign
passive creatures, I see an benefit of Ant interacting with many other
XML vocabularies, standalone or otherwise generated by other software
development tools. I can understand that development effort should focus
on Ant functionality, and naturally will be Antcentric...I just think
for very little effort you can have a build.xml file that plays nice
within other XML processing environments, as well as bolstering Ant to
reuse XML technologies or at the very least respect the core reason why
xml namespaces exist...to avoid collision between elements and
attributes. I would think that with all the java code generation
happening from schemas (and vice versa) would see Ant building getting
very cozy with schema validation and processing...

> 2) Alternatively, one could think of using XML processing-instructions

> to tell ANT that some particular namespace should be ignored by ANT.
> 
>   
>   ...

[Jim Fuller] XML PI's double yukwhy not just define an external xml
file which defines how namespaces are processedI believe that you
could use/extend something like James Clark Namespace routing language
(http://www.thaiopensource.com/relaxng/nrl.html) as a format for such a
document. This would allow you to have a standard definition for Ant
processing as general, though gives a nice logical abstraction for
extensibility. I would be interested in assisting here, as EXSLT and my
other xml bits/bobs are tapering off with XSLT 2.0 approaching. Though
perhaps there is a bit of WIKI work would be logical first stop.
 
> The different approaches may produce quite different functionality, 
> while in (1) all foreign URIs segregated appart from the rest of the 
> ANT lingo, on (2) we could actually intermix them freely:
> 
>   
>   
> ...
> 
>   
> This is a comment inside the code
> 
>   
> 
>   
> 
> Which would produce a very powerful intermingling capability, but it 
> may be too powerful (i.e., too confising for the uninitiated).

[Jim Fuller] having just xml with different namespaces is all you
need...and yes xml namespaces can be confusing, which his why you have
the default namespace always process in Ant...
 
> (1) should be trivial to do in 1.7, (2) would require changes in 
> ProjectHelper to implement the processing-instruction.

> This I do not buy (yet). Certaintly you can resolve this by having the

> sensitive info in an encripted file and having a task that loads the 
> information during the execution of the build. You can write the task 
> to use whatever technology you want it to use.

[Jim Fuller] I think the oper

DO NOT REPLY [Bug 25798] New: - Locator.java can't find tools.jar if CLASSPATH is in uppercase-letters and pointing to JRE

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25798

Locator.java can't find tools.jar if CLASSPATH is in uppercase-letters and 
pointing to JRE

   Summary: Locator.java can't find tools.jar if CLASSPATH is in
uppercase-letters and pointing to JRE
   Product: Ant
   Version: 1.6.0
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


when ant is started with "-lib %CLASSPATH%", Locator.java is not able to find
tools.jar if the system property "java.home" is in uppercase and pointing to the
JRE (e.g. "C:\J2SDK\JRE").

on line 208 of Locator.java, the condition checks if the JRE is in the
classpath. unfortunately, String.endsWith() is case-sensitive!!

to avoid the message "Unable to locate tools.jar .." i changed line 208 into

if (javaHome.endsWith("jre") || javaHome.endsWith("JRE")) {

like this, ant finds tools.jar and works fine.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: XML Namespace avoids collision between xml vocabularies was RE: a comment about xml namespace

[Jose Alberto Fernandez]

> From: Jim Fuller [mailto:[EMAIL PROTECTED] 
> 
> 
> > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > Sent: 23 December 2003 11:44
> > Subject: RE: a comment about xml namespace
> 
> > about? Given (3) ANT cannot just ignore it, since it may be
> > a typo of some sort. There is not such a thing as an ignorable
> 
> [Jim Fuller] Ant could 'ignore' it if it had a schema or DTD 
> which Ant would use ( perhaps it does, have not plumbed that 
> deep into the code yet)...since Ant does use an xml build 
> file, why not validate it against a schema...ok perhaps the 
> problem here would be keeping up with schema definition with 
> extended tasks...or asking developers to provide one...though 
> XML Schema could simply accommodate for build file specific 
> macrodef, presetdef, antlib, taskdef situationsperhaps I 
> am speaking out of turn and all of this is in the pipeline 
> for future versions.
> 

There is no fix schema for ANT. It all depends on what tasks from which
third
parties you have. And all this is independent of namespaces.
We have tasks that can look at the buildfile and generate an appropriate
DTD for it, which can then be used to validate it. I am not sure if
it has been updated to manage NS. Maybe we need one task to generate
XMLSchemata but it still will not adress your situation.

> > 2) Alternatively, one could think of using XML 
> processing-instructions
> 
> > to tell ANT that some particular namespace should be ignored by ANT.
> > 
> >   
> >   ...
> 
> [Jim Fuller] XML PI's double yukwhy not just define an 
> external xml file which defines how namespaces are 
> processedI believe that you could use/extend something 
> like James Clark Namespace routing language
> (http://www.thaiopensource.com/relaxng/nrl.html) as a format 
> for such a document. This would allow you to have a standard 
> definition for Ant processing as general, though gives a nice 
> logical abstraction for extensibility. I would be interested 
> in assisting here, as EXSLT and my other xml bits/bobs are 
> tapering off with XSLT 2.0 approaching. Though perhaps there 
> is a bit of WIKI work would be logical first stop.
>  
Ant external file? Yuk! Wait a minute. 
Why should ANT become a multilingual routing processor
for XML? I think it is a fantastic project but it is not the ANT
project.
I do not see anyone asking XSLT engines to do this kind of thing. 
The XSLT XML processing is for the XSLT, not for doing all for all
XML dialects. Same for ANT.

The only thing here is to allow a way to anotate ANT to give other
XML processors some space. Therefore the point of having a PI.
But we do not need to complicate ANT just for this extreme use case
that you are describing. I think other tools should be developed for
that.

I think you have here a terrific idea for a new project "polyglote"
but that is a different project, not ANT.

> > The different approaches may produce quite different functionality,
> > while in (1) all foreign URIs segregated appart from the 
> rest of the 
> > ANT lingo, on (2) we could actually intermix them freely:
> > 
> >   
> >   
> > ...
> > 
> >   
> > This is a comment inside the code
> > 
> >   
> > 
> >   
> > 
> > Which would produce a very powerful intermingling capability, but it
> > may be too powerful (i.e., too confising for the uninitiated).
> 
> [Jim Fuller] having just xml with different namespaces is all 
> you need...and yes xml namespaces can be confusing, which his 
> why you have the default namespace always process in Ant...
>  

Since ANT can use an unlimited number of namespaces, things are not as
simple.
I in particular do not like the business of a programming language
(which is
what ANT XML really is) where non-understood things are silently
ignored. (-1)
I think that causes more harm than good. I think stuff that must be
ignored
(ant the writer knows about it) must be somehow marked as such (e.g.,
). 

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25767] - Performance issues in JAXPUtils' use of SAXParser & SAXParserFactory

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25767

Performance issues in JAXPUtils' use of SAXParser & SAXParserFactory

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Minor   |Enhancement

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25776] - Ant requires

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25776

Ant requires  instruction in an
xml file - this is reported both xerces and crimson.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25770] - FixCRLF "preserveLastModified"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25770

FixCRLF "preserveLastModified"





--- Additional Comments From [EMAIL PROTECTED]  2003-12-29 16:04 ---
for clarity, i wasn't suggesting breaking backwards compatability but rather 
introducing a new use case...

preserveLastModified; attribute[optional]::boolean; default = 'false'

[example patch - note: it's tiny, but does FileUtils.setFileLastModified need 
the synchronized Java1.1 workaround anymore?]

Index: FixCRLF.java
===
RCS 
file: /home/cvspublic/ant/src/main/org/apache/tools/ant/taskdefs/FixCRLF.java,v
retrieving revision 1.54.2.1
diff -u -r1.54.2.1 FixCRLF.java
--- FixCRLF.java14 Oct 2003 13:20:11 -  1.54.2.1
+++ FixCRLF.java29 Dec 2003 15:47:06 -
@@ -157,6 +157,8 @@
 
 private File srcDir;
 private File destDir = null;
+
+private boolean preserveLastModified = false;
 
 private FileUtils fileUtils = FileUtils.newFileUtils();
 
@@ -329,6 +331,14 @@
 ctrlz = ADD;
 }
 }
+
+/**
+ * Specifies whether Ant should preserve the lastModified timestamp
+ * on any modified files.
+ */
+public void setPreserveLastModified(boolean preserve) {
+   this.preserveLastModified = preserve;
+}
 
 /**
  * Specifies the encoding Ant expects the files to be in -
@@ -566,6 +576,9 @@
 
 if (destIsWrong) {
 fileUtils.rename(tmpFile, destFile);
+if (this.preserveLastModified) {
+   destFile.setLastModified(srcFile.lastModified());
+}
 tmpFile = null;
 }

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25777] - [PATCH] [REGRESSION] Cannot pass composite path reference between scripts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25777

[PATCH] [REGRESSION] Cannot pass composite path reference between scripts





--- Additional Comments From [EMAIL PROTECTED]  2003-12-29 17:27 ---
It does look like the removal of the toString causes a BC issue.

However, the use of toString() in Project#addReference() to resolve
dependences looks like an unintended side-effect.

The problem is that Project a exports reference r which has a reference
to a non-exported reference c, this appears to only work for paths in 1.5
due to the implementation of "toString()".

The patch to Path however causes some unit tests to fail.
PathTest#testEmptyElementIfIsReference
AddTypeTest#testConditionConditionTask,testAddConfigured

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: XML Namespace avoids collision between xml vocabularies was RE: a comment about xml namespace

[Steve Loughran]

Jose Alberto Fernandez wrote:
Why should ANT become a multilingual routing processor
for XML? I think it is a fantastic project but it is not the ANT
project.
I do not see anyone asking XSLT engines to do this kind of thing. 
The XSLT XML processing is for the XSLT, not for doing all for all
XML dialects. Same for ANT.


If you are interested in this kind of thing, point your browser at 
http://1060.org and d/l a build of NetKernel -preferably 2.1 when it 
ships shortly. This is definitely a generic XML processor engine which 
does plenty much magic, like (in v2.1) autobinding a database select to 
an XML document for later xformation.

I am debating moving all my statically/dynamically generated content to 
this system, though need to get a bit better at xpointer first.

Returning to Ant, we are a build tool, not a generic workflow engine 
-even if a lot of the XML workflow/PI stuff at the w3c shows ant 
experience. The problem of getting project to ship roughly what was 
asked for, on or before the date promised, is hard enough without 
introducing more complexity

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25800] New: - Jar indexing does not handle jars in manifest Class-Path

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25800

Jar indexing does not handle jars in manifest Class-Path

   Summary: Jar indexing does not handle jars in manifest Class-Path
   Product: Ant
   Version: 1.6.0
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The SDKs 'jar' command produces index entries for not only a given jar but also 
the jars listed in the jar's manifest's Class-Path entry.

The  task only produces index entries for the jar itself not those in its 
Class-Path entry.

This inconsistency will lead me to continue using  and 'jar' rather than 
 even though 1.6.0 has brought 's performance in line with the 'jar' 
command line utility.  [In previous versions,  was *much* slower when the 
includes list was very long, e.g. when all entries are listed explicitly.]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/docs/manual/api index.html packages.html

[bruce]

bruce   2003/12/29 10:40:54

  Modified:docs/manual/api index.html packages.html
  Log:
  Back out javadoc-generated overwrite of our online version of the Ant API 
docs. This has happened before. Please be careful.
  
  Revision  ChangesPath
  1.6   +10 -25ant/docs/manual/api/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/ant/docs/manual/api/index.html,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- index.html6 Sep 2003 08:50:20 -   1.5
  +++ index.html29 Dec 2003 18:40:54 -  1.6
  @@ -1,26 +1,11 @@
  -http://www.w3.org/TR/html4/frameset.dtd";>
  -
  -
  -
  -
  -
  -Apache Ant API
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -Frame Alert
  +
  +
  +
  +Apache Ant API
  +
  +
  +Redirecting to Apache Ant API ...
  +
  +
  +
   
  -
  -This document is designed to be viewed using the frames feature. If you see 
this message, you are using a non-frame-capable web client.
  -
  -Link toNon-frame version.
  -
  -
  -
  
  
  
  1.9   +19 -34ant/docs/manual/api/packages.html
  
  Index: packages.html
  ===
  RCS file: /home/cvs/ant/docs/manual/api/packages.html,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- packages.html 6 Sep 2003 08:50:20 -   1.8
  +++ packages.html 29 Dec 2003 18:40:54 -  1.9
  @@ -1,37 +1,22 @@
  -http://www.w3.org/TR/html4/loose.dtd";>
  -
  -
  -
  -
  -
  - (Apache Ant API)
  -
  +
  +
  +Apache Ant API
  +
  +
  +Apache Ant API has not been generated
  +
  +If you see this page online at http://ant.apache.org";>ant.apache.org, it is not a bug, but
  +on purpose.  We do not provide an online version of the API docs, they
  +are included with all our distributions, including the nightly
  +builds.
  +
  +If you want to see the API docs for the latest code, they are
  +generated by http://jakarta.apache.org/gump/";>Apache Gump
  +and linked from http://nagoya.apache.org/gump/javadoc/ant/build/javadocs/index.html";>http://nagoya.apache.org/gump/javadoc/ant/build/javadocs/index.html.
   
  +
  +
   
  -
   
  -
  -function windowTitle()
  -{
  -parent.document.title=" (Apache Ant API)";
  -}
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -The front page has been relocated.Please see:
  -
  -  Frame version
  -
  -  Non-frame version.
  -
  -
  -
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25801] New: - filelist used in selector example with task

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25801

filelist used in selector example with  task

   Summary: filelist used in selector example with  task
   Product: Ant
   Version: 1.6.0
  Platform: Other
   URL: http://ant.apache.org/manual/CoreTypes/selectors.html
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


there are a few uses of filelist used in conjunction with  task in the 
selector documentation, for example;

'Here are some examples of how to use the Modified Selector:

DO NOT REPLY [Bug 25544] - record task overwrites existing log file (doc says it appends)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25544

record task overwrites existing log file (doc says it appends)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2003-12-29 18:46 ---
Doc has been updated. Tested in 1.6. Appending works fine.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25605] - record task logfile has wildly inaccurate duration

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25605

record task logfile has wildly inaccurate duration

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2003-12-29 18:47 ---
Fixed in 1.6.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25777] - [PATCH] [REGRESSION] Cannot pass composite path reference between scripts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25777

[PATCH] [REGRESSION] Cannot pass composite path reference between scripts





--- Additional Comments From [EMAIL PROTECTED]  2003-12-29 19:07 ---
[To Jose] Not sure whether the method should be clone() or cloneAndResolve().
Probably only needed when some refs are passed explicitly (not quite obvious to
me). And yes, removing toString() in Peter's patch was definitely desirable; it
is just that it exposed some underlying bugs.

[To Peter] The only side-effect of toString() here is that it sets the checked
flag for circular refs. If you call dieOnCircularRefs with the first project, it
succeeds; with the second project, it fails. So if you call toString() on the
path before passing it, dOCR succeeds and sets checked; otherwise, it is called
later when the Path is used, with the wrong project (project #2), and fails.
Path.list() gives the correct result so long as dOCR does not prevent it from
returning!

(BTW all unit tests passed for me with the original patch, not sure why it would
be different for you.)

[Generally] The essence of the problem is this: Reference is meaningless without
a Project context; Path (e.g.) potentially keeps a bunch of Reference's around,
and also one Project. The Reference should be resolved w.r.t. the Project in
which it was defined, which is normally held by the Path which is also holding
the Reference.

Path.dieOnCircularReference() is buggy because it passes a single Project
through the whole recursive call tree, which is nonsense. Each nested Path may
have its own Project. Attaching a patch which corrects this (for Path only -
should not be hard to generalize for other data types). It seems to fix the
observed problem. Note that DataType.dieOnCircularReference should just not take
a Project parameter at all - it is useless, since a correct subclass would not
use it except to recurse.

Yet another solution is to just keep a Project pointer in Reference to begin
with. I will attach a different patch that follows this approach. Again, the
patch only corrects Path. However it should be much easier to generalize to
other data types than the original patch: just do a global search-and-replace of
getReferencedObject(...something...) with getReferencedObject(), plus some
sanity checking of course, and fix the handful of explicit uses of new
Reference(...) to take a Project parameter. The patch introduces two API changes
of note:

1. Reference now has a bean field 'project' of type Project, and a constructor
taking Project, and a method getReferencedObject() with no args. Making a
Reference without an associated Project, or derefering the ref with a different
project, becomes deprecated.

2. IntrospectionHelper can assign attribute values based not only on types with
a constructor taking String, but also for those taking the pair
(Project,String). Path was already doing this with a special case which is
generalized by the patch.

I think I like this patch best since it addresses the core problem directly and
more understandably, without any apparent overhead. Seems to fix the reported
bug. Does not break existing unit tests (for me).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25777] - [PATCH] [REGRESSION] Cannot pass composite path reference between scripts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25777

[PATCH] [REGRESSION] Cannot pass composite path reference between scripts





--- Additional Comments From [EMAIL PROTECTED]  2003-12-29 19:07 ---
Created an attachment (id=9729)
Fix for buggy Path.dieOnCircularReference

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25777] - [PATCH] [REGRESSION] Cannot pass composite path reference between scripts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25777

[PATCH] [REGRESSION] Cannot pass composite path reference between scripts





--- Additional Comments From [EMAIL PROTECTED]  2003-12-29 19:08 ---
Created an attachment (id=9730)
Recommended patch - changes Reference to keep track of which Project it is 
associated with

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25777] - [PATCH] [REGRESSION] Cannot pass composite path reference between scripts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25777

[PATCH] [REGRESSION] Cannot pass composite path reference between scripts





--- Additional Comments From [EMAIL PROTECTED]  2003-12-29 19:12 ---
Note that the third patch also makes the Project parameter to
DataType.dieOnCircularReference superfluous.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25745] - ClearCase Update task does not allow usage of the -force flag when invoked

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25745

ClearCase Update task does not allow usage of the -force flag when invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-12-29 20:44 ---
Created an attachment (id=9738)
Implements the -force cmd line option to the cleartool update task

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]