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 2008/11/24 14:02:42 UTC
DO NOT REPLY [Bug 46274] New: XSLT fails on empty nested fileset
https://issues.apache.org/bugzilla/show_bug.cgi?id=46274
Summary: XSLT fails on empty nested fileset
Product: Ant
Version: 1.7.0
Platform: PC
OS/Version: Windows Server 2003
Status: NEW
Severity: normal
Priority: P2
Component: Core tasks
AssignedTo: notifications@ant.apache.org
ReportedBy: gjfdh@yahoo.com
XSLT throws a build exception "no resources specified" when it is called with a
nested file set which is empty (has no matching files). This is inconsistent
because XSLT does not throw exceptions when the same fileset is given in an
implicit manner.
I believe that the code within the execute method of
org.apache.tools.ant.taskdefs.XSLTProcess.java is too harsh. Here is where the
exception is being thrown:
> if (useImplicitFileset) {
> ...
> } else { // only resource collections, there better be some
> if (resources.size() == 0) {
> throw new BuildException("no resources specified");
> }
> }
> processResources(xslResource);
I am uncertain exactly why resources is empty when the fileset is empty and not
empty otherwise. However, stopping the build is too drastic an action when a
simple log message would suffice as a warning. The processResources method
doesn't crash on an empty resources.
Below is an example build.xml which illustrates the problem. In my real
build.xml, I use an explicit fileset because I want to re-use a pre-defined
fileset through refid. XSLT works well when the refid'd fileset contains at
least one file; the build comes to a halt otherwise. This causes problems.
The XSLT task does not support refid attributes. And, even if it did, I would
prefer to use a nested fileset because there are too many attributes in that
task already.
------------------
C:\>type build.xml
<project>
<target name="foo">
<mkdir dir="junk"/>
<touch file="junk/temp.xsl"/>
<xslt
destdir="junk"
style="junk/temp.xsl"
basedir="junk"
>
<include name="missing-file"/>
</xslt>
<xslt
destdir="junk"
style="junk/temp.xsl"
useImplicitFileset="no"
>
<fileset file="junk/missing-file"/>
</xslt>
</target>
</project>
C:\>ant -v foo
Apache Ant version 1.7.0 compiled on December 13 2006
Buildfile: build.xml
Detected Java version: 1.5 in: C:\PROGRA~1\IBM\Java50\jre
Detected OS: Windows Server 2003
parsing buildfile C:\build.xml with URI = file:/C:/build.xml
Project base dir set to: C:\
Build sequence for target(s) `foo' is [foo]
Complete build sequence is [foo, ]
foo:
[antlib:org.apache.tools.ant] Could not load definitions from resource
org/apache/tools/ant/antlib.xml. It could not be found.
[mkdir] Created dir: C:\junk
[touch] Creating C:\junk\temp.xsl
[xslt] Using class org.apache.tools.ant.taskdefs.optional.TraXLiaison
[xslt] Transforming into C:\junk
[xslt] Using class org.apache.tools.ant.taskdefs.optional.TraXLiaison
BUILD FAILED
C:\build.xml:18: no resources specified
at
org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:367)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
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.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
at org.apache.tools.ant.Main.runBuild(Main.java:698)
at org.apache.tools.ant.Main.startAnt(Main.java:199)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
Total time: 0 seconds
C:\>
--
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 46274] XSLT fails on empty nested fileset
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46274
Stefan Bodewig <bo...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Stefan Bodewig <bo...@apache.org> 2008-11-26 06:24:25 PST ---
svn revision 720862 ( https://svn.apache.org/viewcvs.cgi?view=rev&rev=720862 ) adds a failOnNoResources attribute.
--
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 46274] XSLT fails on empty nested fileset
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46274
Stefan Bodewig <bo...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |notifications@ant.apache.org
AssignedTo|notifications@ant.apache.org|bodewig@apache.org
Severity|normal |enhancement
Target Milestone|--- |1.8.0
--- Comment #1 from Stefan Bodewig <bo...@apache.org> 2008-11-24 08:09:25 PST ---
While I agree that the behavior for resource collections and the implicit
fileset are different, resource collections have worked that way since 1.7.0
(i.e. since xslt supported them) and still do in 1.7.1.
If we changed the behavior to just log a warning, we might break existing
builds that rely on the process to fail.
We'll need a separate attribute to control behavior, I'm afraid.
--
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.