You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Jay Glanville <di...@nortelnetworks.com> on 2001/05/16 15:57:00 UTC
RE: how to get more debug information [SEMI-SOLUTION!]
First, let me apologize for cross-posting between the user and dev
distribution lists, but I feel that this should probably move into the dev
arena. Sorry.
I have found a solution that works for me!!!! It actually isn't a solution
to the lack of error text, but a solution to the bigger problem: getting
javadoc to work. It appears to be a problem with path statements, in
relation to base directories.
The following is a "cvs diff -u Javadoc.java" of my solution:
-----8<-------------------------------------------------
Index: Javadoc.java
===================================================================
RCS file:
/home/cvspublic/jakarta-ant/src/main/org/apache/tools/ant/taskdefs/Javadoc.j
ava,v
retrieving revision 1.48
diff -u -r1.48 Javadoc.java
--- Javadoc.java 2001/05/11 06:22:44 1.48
+++ Javadoc.java 2001/05/16 13:14:31
@@ -898,7 +898,8 @@
JavadocOutputStream err = new
JavadocOutputStream(Project.MSG_WARN);
Execute exe = new Execute(new PumpStreamHandler(out, err));
exe.setAntRun(project);
- exe.setWorkingDirectory(project.getBaseDir());
+ // force the working directory to be the current working directory.
+ exe.setWorkingDirectory(null);
try {
exe.setCommandline(toExecute.getCommandline());
int ret = exe.execute();
-----8<-------------------------------------------------
Basically, all I did was force the external executer to use the current
working directory, as opposed to the project's base directory.
I am afraid to submit this as a patch to the current load. The reason why
is I haven't been able to do enough testing. I have performed tests on both
SunOS 5.6 and WinNT 4.0 platforms, using package names (as opposed to file
names). Everything works 100% as expected for the stated scenarios.
One of the reasons why I feel that this patch won't break anyone else, is
because the <javadoc> task resolves all the filenames and paths into
absolute paths, but the task executer doesn't try to get the absolute path
for the javadoc executable itself.
Can anyone think of how this patch might break current accepted usage? Can
anyone help me with the testing (by making this small change and testing in
your environment)? If so, I'd greatly appreciate the peace of mind before
submitting this patch.
JDGlanville
PS: Thanks to all the responses to my previous posts. They helped point me
in the "right" direction.
> --- Jay Glanville <di...@nortelnetworks.com> wrote:
> > Ok. I STILL need help with this problem. Please help,
> before I start
> > sending pictures of myself on my knees begging! ;-)
> >
> > Here's the situation so far:
> > - uname -sr = SunOS 5.6
> > - trying to run javadoc, but it continuously returns -1
> (see original
> > posting below)
> > - I tried running the command on the command line without
> success (it
> > seems
> > that sh on SunOS has a 256 character limit.
> > - to solve the previous problem, I made changes to my version of
> > <javadoc>
> > so that it would use the @file command line parameter to shorten the
> > javadoc
> > command line
> > - the javadoc task still fails, but if I cut and paste the
> command into
> > an
> > xterm, it succeeds.
> > - the major problem that I'm having with the javadoc task
> is not that
> > it's
> > failing, but that it's not telling me why it's failing (it
> just shows
> > "return -1")
> > - I've tried to make changes to Javadoc.java and Execute.java (the
> > actual
> > class that runs the javadoc command) to properly redirect the error
> > output
> > from the command so that I can see why it fails, but totally without
> > success. Can anyone point me to the right place to make
> the changes so
> > that
> > I can properly capture the output?
> >
> > Please, please, how do I find out why the command is
> failing? Heck, I
> > wouldn't care about why, as much as how to solve the problem (but I
> > really
> > can't do that until I find out why ...)
> >
> > So, please, don't make me send pictures ... please help. ;-)
> >
> > JDGlanville
> >
> > > -----Original Message-----
> > > From: Stephane Bailliez [mailto:sbailliez@imediation.com]
> > > Sent: Thursday, May 10, 2001 3:27 PM
> > > To: ant-user@jakarta.apache.org
> > > Subject: RE: how to get more debug information
> > >
> > >
> > >
> > > Try running the javadoc in the command line with the same
> > > options. With luck
> > > you may have more information.
> > >
> > > I have had problem myself on Solaris and javadoc via ant but
> > > didn't had time
> > > to dig into the code and find the problem. It had problem with the
> > > windowtitle and title which were amazingly unquoted (and
> > > there was space in
> > > it) while the line was ok under nt.
> > >
> > > --
> > > Stéphane Bailliez
> > > Software Engineer, Paris - France
> > > iMediation - http://www.imediation.com
> > > Disclaimer: All the opinions expressed above are mine and
> > > not those from my
> > > company.
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jay Glanville [mailto:dickon@nortelnetworks.com]
> > > > Sent: Thursday, May 10, 2001 8:26 PM
> > > > To: Ant-User (text)
> > > > Subject: how to get more debug information
> > > >
> > > >
> > > > I'm trying to run a javadoc command and it's failing. So, in
> > > > an attempt to
> > > > determine why it's failing, I run ant with a -debug option to
> > > > get all the
> > > > information. The following is a snippet of the resulting log:
> > > >
> > > > [javadoc] Generating Javadoc
> > > > [javadoc] Source path = /vobs/SiteManager/src
> > > > [javadoc] Packages = [com.nortel.smfw.*]
> > > > [javadoc] Exclude Packages = []
> > > > [javadoc] Javadoc args: javadoc -d
> > > /vobs/SiteManager/build/javadocs
> > > > -extdirs /vobs/SiteManager/lib -J-Xmx128m -classpath
> > > > /vobs/SiteManager/src
> > > > -sourcepath /vobs/SiteManager/src -version -author
> > > > com.nortel.smfw.base
> > > > [...snipped...]
> > > > [javadoc] Javadoc execution
> > > > Execute:Java13CommandLauncher: javadoc -d
> > > > /vobs/SiteManager/build/javadocs
> > > > -extdirs /vobs/SiteManager/lib -J-Xmx128m -classpath
> > > > /vobs/SiteManager/src
> > > > -sourcepath /vobs/SiteManager/src -version -author
> > > > com.nortel.smfw.base
> > > > [...snipped...]
> > > >
> > > > BUILD FAILED
> > > >
> > > > /vobs/SiteManager/bin/build.xml:247: Javadoc returned -1
> > > >
> > > >
> > > > What is causing the -1? I know that javadoc is in my path
> > > > because the shell
> > > > script that I use to start ant sets up the necessary path for
> > > > me. How can I
> > > > find more information?
> > > >
> > > > --
> > > > Jay Dickon Glanville
> > > > P068 - SiteManager Development, Nortel Networks
> > > > 613-765-1144 (ESN 395-1144)
> > > > MS: 045/55/A05
> > > > E-Mail: dickon@nortelnetworks.com
> > > >
> > >
> >
>
>
> =====
> (holtdl@yahoo.com)
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
>
Re: how to get more debug information [SEMI-SOLUTION!]
Posted by Jesse Glick <Je...@netbeans.com>.
Jay Glanville wrote:
> [major snip]
> --- Javadoc.java 2001/05/11 06:22:44 1.48
> +++ Javadoc.java 2001/05/16 13:14:31
> @@ -898,7 +898,8 @@
> [snip]
> - exe.setWorkingDirectory(project.getBaseDir());
> + // force the working directory to be the current working directory.
> + exe.setWorkingDirectory(null);
>
> Basically, all I did was force the external executer to use the current
> working directory, as opposed to the project's base directory.
Or just:
- exe.setWorkingDirectory(project.getBaseDir());
Why should the working directory be set at all? What difference does it make?
I don't see any reason why this line of code should be there.
-Jesse
--
Jesse Glick <ma...@netbeans.com>
NetBeans, Open APIs <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR