sqlunit.dtd exists in etc directory.
build.xml exists in sqlunit directory, which calls mysqltest in the tests directory.
mysqltest.xml has:
<!DOCTYPE sqlunit SYSTEM "file:../etc/sqlunit.dtd">
This is the relative location of the dtd from the test file. When I run the ant build.xml script, I always get "I/O error (java.io.FileNotFoundException): ..\etc\sqlunit.dtd". It would appear that the relative path is starting from the build.xml directory instead of mysqltest.xml directory.
Is there a problem with how SQLUnit is using JDOM or is this a general problem with resolving relative paths within JDOM?
I'm going to integrate these tests into our CruiseControl builds in a totally different project, so using an absolute path for the DTD is an impossibility.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you supply the relative form of the url, ie:
file:docs/sqlunit.dtd
It implies that it is relative to the current location where you are calling the code from, in this case, the top level directory where the build.xml file resides. I dont think this is a problem with JDOM or SQLUnit, its just the way relative file paths are supposed to work.
You may want to try this:
cd tests
ant -f ../build.xml [whatever_target]
and then specifying the SYSTEM as
file:../etc/sqlunit.dtd
should work, though I havent tried this myself.
However, you can also provide an absolute path, such as this:
file:///var/opt/somewhere/sqlunit.dtd
or even a URL: http://somehost/offset/sqlunit.dtd
The last two would be what you probably want to use from within cruisecontrol.
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see what you mean. It may help to think of the SQLUnit xml files as configuration rather than command files. The actual command is the sqlunit task, so things have to be relative to that.
That said, I did find something that looks like we may be able to bypass this relative/absolute file naming altogether by specifying this as a resource and including the DTD in the jar file. It requires a custom EntityResolver class, and I have never written such a thing before, but it seems interesting to do.
Since this is not a big blocker type issue, I would like to do this for the next release. I will update this thread when I am done.
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Putting in the EntityResolver turned out to be simpler than I thought, so I have added this in to cvs and will be available in the 4.8 release, which I am building right now.
Thanks for pointing the problem out.
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have the following structure
sqlunit
|
-- etc
|
-- tests
sqlunit.dtd exists in etc directory.
build.xml exists in sqlunit directory, which calls mysqltest in the tests directory.
mysqltest.xml has:
<!DOCTYPE sqlunit SYSTEM "file:../etc/sqlunit.dtd">
This is the relative location of the dtd from the test file. When I run the ant build.xml script, I always get "I/O error (java.io.FileNotFoundException): ..\etc\sqlunit.dtd". It would appear that the relative path is starting from the build.xml directory instead of mysqltest.xml directory.
Is there a problem with how SQLUnit is using JDOM or is this a general problem with resolving relative paths within JDOM?
I'm going to integrate these tests into our CruiseControl builds in a totally different project, so using an absolute path for the DTD is an impossibility.
Hi Greg,
If you supply the relative form of the url, ie:
file:docs/sqlunit.dtd
It implies that it is relative to the current location where you are calling the code from, in this case, the top level directory where the build.xml file resides. I dont think this is a problem with JDOM or SQLUnit, its just the way relative file paths are supposed to work.
You may want to try this:
cd tests
ant -f ../build.xml [whatever_target]
and then specifying the SYSTEM as
file:../etc/sqlunit.dtd
should work, though I havent tried this myself.
However, you can also provide an absolute path, such as this:
file:///var/opt/somewhere/sqlunit.dtd
or even a URL:
http://somehost/offset/sqlunit.dtd
The last two would be what you probably want to use from within cruisecontrol.
-sujit
Interesting....I had always believed relative URIs are relative to the location of the resource within which the declaration occurs.
Hi Greg,
I see what you mean. It may help to think of the SQLUnit xml files as configuration rather than command files. The actual command is the sqlunit task, so things have to be relative to that.
That said, I did find something that looks like we may be able to bypass this relative/absolute file naming altogether by specifying this as a resource and including the DTD in the jar file. It requires a custom EntityResolver class, and I have never written such a thing before, but it seems interesting to do.
Since this is not a big blocker type issue, I would like to do this for the next release. I will update this thread when I am done.
-sujit
Hi Greg,
Putting in the EntityResolver turned out to be simpler than I thought, so I have added this in to cvs and will be available in the 4.8 release, which I am building right now.
Thanks for pointing the problem out.
-sujit