Added Oracle test using a fork of testcontainers. #95
Conversation
npetzall
commented
May 27, 2017
npetzall
commented
- Using fork of TestContainers that allows assume on docker and sideloaded jdbcdriver jars.
- Which means if docker doesn't exist or drivers are missing the test is ignored.
- Added a TESTING.md which should be updated as we go along.
- Minor restructuring in test/resources
npetzall
force-pushed
the
oracle_testcontainer
branch
from
2b68738
to
2bc0ed3
Compare
|
Hello. TestContainers' co-maintainer is here. May I ask you not to use the fork? If TestContainers doesn't work for you, we're happy to adjust it for your use-case. TC is being actively developed, �and SchemaSpy would benefit from future features, but a fork will lock it to the specific version. Best Regards, |
|
@bsideup testcontainers/testcontainers-java#344 None of the issues were of interest so, I would suspect that "adjust it for your use-case" has been proven to be un-true. As the forker, I feel that your assuming that I won't keep it up-to-date, which I won't as long as the fork fills my needs. |
|
From testcontainers channel: I assume there hasn't been any coding involved for decoupling TestContainers from JUnit yet? |
|
@npetzall before I will merge you PR could you verify and resolve the conflicts ? Thank you very much. |
* Using fork of TestContainers that allows assume on docker and sideloaded jdbcdriver jars. * Which means if docker doesn't exist or drivers are missing the test is ignored. * Added a TESTING.md which should be updated as we go along. * Minor restructuring in test/resources * Added additional dumpAll to ResultSetDumper
npetzall
force-pushed
the
oracle_testcontainer
branch
from
2bc0ed3
to
4129c99
Compare
|
@rafalkasa Done |
| @ClassRule | ||
| public static OracleContainer oracleContainer = new OracleContainer<>() | ||
| .assumeDocker() | ||
| .withDrivers(driverPath); |
There was a problem hiding this comment.
@npetzall could you do something to not throw the exception when driverPath doesn't exist ?
In my opinion should be the possibility to skip integration test when some condition are not passed
There was a problem hiding this comment.
Now I'm receiving the exception as below:
[ERROR] org.schemaspy.testcontainer.OracleIT Time elapsed: 0.04 s <<< ERROR!
java.lang.ExceptionInInitializerError
at org.schemaspy.testcontainer.OracleIT.<clinit>(OracleIT.java:66)
There was a problem hiding this comment.
I'm stumped.
I've tested
docker on, missing dir
docker on, missing lib
docker off, lib exist
docker off, missing dir
docker off, missing lib
They all result in test ignored.
There was a problem hiding this comment.
Are you sure you've pulled the latest changes. I only ask since travis-ci, marked the test as skipped and not failed.
There was a problem hiding this comment.
I'm soon on windows and will test it again.
There was a problem hiding this comment.
@npetzall you need to notice that I only go to the project folder and run mvnw verify and after this issue occured
There was a problem hiding this comment.
@rafalkasa Verified, know what's wrong. I'm on it
|
Strange, I'll check it to night. Only tested happy path after conflict resolution. That was sloppy. |
|
My duty is check the thing twice before the merge with master 😄 |
|
Do you have more of the stacktrace? |
|
Since it's docker related and I know your on Windows I might have some problem recreating the error |
|
unfortunately not, this is only what appear :-( I don't have oracle driver and folder ext-lib/ maybe this is the issue |
npetzall
force-pushed
the
oracle_testcontainer
branch
from
c39da26
to
e53464b
Compare
|
@rafalkasa I've fixed an Issue. Should work better now. |
|
I can't test the changes because, I will don't have access to the computer to the end of the week. Maybe on Sunday I will have chance to look and verify |
|
Got it, no worries, i'll work on something else during the wait. |
|
@npetzall everything is working now after your last commit 😄 I reviewed your conversation related to the changes in testcontainer for java, as I understand we are using your forked testcontainer version instead original because of some limitation in existing implementation. What do you think ? Could you maintain your testcontainer-java and update after original project releases ? Maybe exist possibility to extend the testcontainer-java code instead fork the code and making changes inside. I'm thinking about built our own solution on top testcontainer-java and use original testcontainer as reference. Something like proxy api ? I don't know the details maybe you can explain more if it's possible ? |
|
@rafalkasa As for the driver loading issue 344. I'm gonna check and see if I can get it working by having maven adding it to classpath during integration test phase (not be able to run it from intellij, I'm guessing) So for the junit module for testcontainers I'm gonna add so that it ignores if jdbc-driver is missing. |
|
@rafalkasa we might be able to retire the usage of the fork if 343 is fixed. Was able to get failsafe working with additionalclasspathelement. Seems there was a magic setting missing. |
