Home » Newcomers » Newcomers » 3.1.1: build.xml warning on unrslvd taskdef that is in classpath
| 3.1.1: build.xml warning on unrslvd taskdef that is in classpath [message #118567] |
Sat, 19 November 2005 18:34  |
Eclipse User |
|
|
|
Originally posted by: dmkarr.earthlink.net
I have a build.xml that defines an XMLBean Ant task. The build works
fine from the command line. The "build.properties" file in the current
directory defines a property which is the path to the xbean.jar file,
containing the Java class for the task. The taskdef references that
variable, and the build.xml has a "property" element pointing to that
properties file. Again, this works fine from the command line.
However, when I open that build.xml in Eclipse 3.1.1, it gives me a
warning on the taskdef, saying the implementation class for the taskdef
cannot be found.
|
|
| |
| Re: 3.1.1: build.xml warning on unrslvd taskdef that is in classpath [message #118587 is a reply to message #118581] |
Sat, 19 November 2005 22:48  |
| Eclipse User |
|
|
|
Ok, that gave me a clue to look for. I started up FileMon from
SysInternals, to monitor file I/O, and I monitored for
"*build.properties*". This showed me what's happening. The "basedir"
attribute is set to ".", as I set on 99% of the build files that I
write. The problem is that "." in Eclipse is my workspace directory,
not the directory where my application really is.
This gets to the root of something that bothers me about how workspaces
are set up. My original application was in one directory, and when I
started Eclipse, it asked me where the base of my workspaces would be.
It defaulted to a completely different directory. At the time, I
figured this would be where Eclipse-specific metadata would be stored,
so I didn't think it was important to try to force it to use my real
application root directory. I'm starting to think that I need to be
able to set my workspace directory to the root of my application tree.
However, I'm not sure how to do that (it doesn't appear to be
changeable), and I'm not sure what other impact that would have.
In any case, I would assume that you would still consider this behavior
a bug, as "." in the context of a build.xml rightly should be the
directory the build.xml is in.
Do you still need a test case for this, or are the circumstances obvious?
Darin Swanson wrote:
> My guess without seeing the buildfile would be that the basedir that is
> being used is not the same as from the commandline.
> Possibly the build.properties file is not being found?
>
> If this does not clear things up, can you log a simple, reproducible test
> case against platform ant and I will take a look
>
> Thanks
> Darins
>
> "David M. Karr" <dmkarr@earthlink.net> wrote in message
> news:437FB66A.2833752B@earthlink.net...
>
>>I have a build.xml that defines an XMLBean Ant task. The build works
>>fine from the command line. The "build.properties" file in the current
>>directory defines a property which is the path to the xbean.jar file,
>>containing the Java class for the task. The taskdef references that
>>variable, and the build.xml has a "property" element pointing to that
>>properties file. Again, this works fine from the command line.
>>
>>However, when I open that build.xml in Eclipse 3.1.1, it gives me a
>>warning on the taskdef, saying the implementation class for the taskdef
>>cannot be found.
>>
>
>
>
|
|
| | |
| Re: 3.1.1: build.xml warning on unrslvd taskdef that is in classpath [message #119315 is a reply to message #119050] |
Wed, 23 November 2005 12:51 |
| Eclipse User |
|
|
|
Darin Swanson wrote:
> Are both builds set to run in a separate JRE from the workspace?
> If you are running in the same JRE as Eclipse, the working directory would
> be the Eclipse install location.
> If you are running in a separate JRE from Eclipse, it would be the location
> of the buildfile.
I was not guessing when I said what it was using as the current directory.
When I ran Eclipse, I also ran the FileMon tool from SysInternals, and I
monitored the reference to the "build.properties" file. When I ran the
"Java Project from existing buildfile", it tried to find the
build.properties file in the Eclipse project directory, which was in
"C:/Documents and Settings/<myuid>/workspace/<projectname>", which was the
default Eclipse offered me for the workspace tree. Since I only created
this from an existing build file, it didn't put the "build.properties"
file in the project directory, so this did not find the file.
However, when I created the project as a plain Java project, and set it to
use an existing source tree (my application directory), when I run the
build, FileMon shows that it looks for the file in my application
directory, not my project directory, so the build succeeds.
> "David Karr" <david.karr@wamu.net> wrote in message
> news:05adec44ebfcff9364833faee9f76de2$1@www.eclipse.org...
>> I'm not sure exactly what's going on here, but I eventually tried creating
>> just a "Java project" from existing source instead of a "Java project from
>> an existing Ant buildfile". It appears when I run my build.xml from the
>> latter, the current directory is the "project" directory, but when I run
>> my build.xml from the former, it's the "application" directory. The
>> latter is unable to find my build.properties file, and the former is.
>>
|
|
|
Goto Forum:
Current Time: Tue May 13 07:37:28 EDT 2025
Powered by FUDForum. Page generated in 0.09518 seconds |
Home