This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 167966 - Setting "output" on <java> task no longer works
Summary: Setting "output" on <java> task no longer works
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 6.x
Hardware: PC All
: P3 blocker (vote)
Assignee: t_h
URL:
Keywords: REGRESSION
Depends on:
Blocks: 158492
  Show dependency tree
 
Reported: 2009-07-01 14:49 UTC by tthompson
Modified: 2009-07-30 15:06 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tthompson 2009-07-01 14:49:04 UTC
I have a free form web application project that runs a <java> task to compress Dojo JS source.  I stripped the build
file down to just this one target to demonstrate the issue:

<project name="test" default="build" basedir=".">
    <target name="build">
        <java jar="/tmp/custom_rhino.jar" fork="true">
            <arg value="-c"/>
            <arg path="/tmp/HtmlDragMove.js"/>

            <redirector output="/tmp/HtmlDragMove1.js"/>
        </java>
    </target>
</project>

When I run the script from inside NB with the Ant verbosity level set to debug, I get the following output for file I am
trying to compress:

Build sequence for target(s) `build' is [build]
Complete build sequence is [build, ]
build:
Executing '/usr/lib/jvm/java-6-sun-1.6.0.13/jre/bin/java' with arguments:
'-jar'
'/tmp/custom_rhino.jar'
'-c'
'/tmp/HtmlDragMove.js'
The ' characters around the executable and arguments are
not part of the command.
Output redirected to /tmp/HtmlDragMove1.js
Execute:Java13CommandLauncher: Executing '/usr/lib/jvm/java-6-sun-1.6.0.13/jre/bin/java' with arguments:
'-jar'
'/tmp/custom_rhino.jar'
'-c'
'/tmp/HtmlDragMove.js'
The ' characters around the executable and arguments are
not part of the command.
dojo.provide("swdojo.dnd.HtmlDragMove");
dojo.require("dojo.dnd.*");
dojo.declare("swdojo.dnd.HtmlDragMoveSource",dojo.dnd.HtmlDragSource,{onDragStart:function(){
var _1=new swdojo.dnd.HtmlDragMoveObject(this.dragObject,this.type);
....

It seems like the <java> task runs twice based on the output but the second time it runs, the output shows up in NB
instead of going to the file I specified.  The main problem with this is the output file, /tmp/HtmlDragMove1.js, ends up
as a zero byte file.

If I run this same build script in NB 6.5, the output is almost the same (I don't see the JavaScript output to the NB
output window) and I don't end up with a zero byte file:

Build sequence for target(s) `build' is [build]
Complete build sequence is [build, ]
build:
Executing '/usr/lib/jvm/java-6-sun-1.6.0.13/jre/bin/java' with arguments:
'-jar'
'/tmp/custom_rhino.jar'
'-c'
'/tmp/HtmlDragMove.js'
The ' characters around the executable and arguments are
not part of the command.
Output redirected to /tmp/HtmlDragMove1.js
Execute:Java13CommandLauncher: Executing '/usr/lib/jvm/java-6-sun-1.6.0.13/jre/bin/java' with arguments:
'-jar'
'/tmp/custom_rhino.jar'
'-c'
'/tmp/HtmlDragMove.js'
The ' characters around the executable and arguments are
not part of the command.
BUILD SUCCESSFUL (total time: 0 seconds)
Comment 1 t_h 2009-07-28 15:47:25 UTC
Caused by #6119721e07fb. Reverted in core-main #ab84b41d77ea
Comment 2 Quality Engineering 2009-07-29 06:00:20 UTC
Integrated into 'main-golden', will be available in build *200907290201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/ab84b41d77ea
User: Tomas Holy <t_h@netbeans.org>
Log: #167966: Setting 'output' on <java> task no longer works
Comment 3 tthompson 2009-07-29 19:44:20 UTC
I noticed the target milestone for this is 6.8.  Any chance this can go into 6.7 since it was a regression?
Comment 4 Jesse Glick 2009-07-30 15:06:47 UTC
Before we go backporting anything, I'd like to understand this better. It sounds like a near-duplicate of issue #168153,
fixed by 019b073dabbc as far as I know. So was the reversion of 6119721e07fb really necessary?