Closed sswaroopgupta closed 6 years ago
The question for me now is, whether the "let's scan the whole thing", to possibly find custom parsers, is actually useful.
a) there might be no custom parsers at all b) there might be one or few, but the whole classpath is quite big
so scanning (or at least try to scan) thousands of classes, to hope to find something seems for me in a second though not really meaningful.
So what is your opinion here ?
Wouldn't it makes more sense that there is a property in env/default/java.properties
, where I can enter the full name of all my parsers ?
Then gauge-java has the simple job of reading this property and initialising the classes.
It is one more thing for the user (as compared of just throwing the implementation in), but it is a small thing.
Any opinion?
PS: I do not know how you have done it for the other runners (or plan to), so this of course should be aligned, to avoid having different solutions
PPS: I assume the package_to_scan
property is actually the intention to address exactly this, but it feels like a fix for a symptom and not the cause
@jackperalta
The question for me now is, whether the "let's scan the whole thing", to possibly find custom parsers, is actually useful.
Your question is right. scanning everything is not since it will cause a performance issue. We already faced a huge performance issue after this in our test suite.
The reason for that was following -
The fix has been already done in gauge-java
ref https://github.com/getgauge/gauge-java/commit/4cde815078fba801e2a29e98587dec57c5abca6e.
Now the parsers are scanned only once per execution in the same location where the implementations are.
@sguptatw This has been fixed and should be availabe in latest guage-java nightly which is 26-04-2017
Please update your gauge-java dependency to following and check
<dependency>
<groupId>com.thoughtworks.gauge</groupId>
<artifactId>gauge-java</artifactId>
<version>0.6.7.nightly-2018-04-26</version>
<scope>test</scope>
</dependency>
I have the following version
$ gauge -v
Gauge version: 0.9.7
Commit Hash: bc9784c
Plugins
-------
html-report (4.0.3)
java (0.6.7.nightly-2018-04-27)
screenshot (0.0.1)
spectacle (0.1.2)
one a fresh java_maven_selenium
project with the dependencies as sguptatw writes, the project runs succcessfully, but prints hundreds of stacktraces, like
12:59:27.299 [main] WARN org.reflections.Reflections - could not get type for name groovy.lang.GroovyObject from any class loader org.reflections.ReflectionsException: could not get type for name groovy.lang.GroovyObject
(just a snippet from the full log.
So, it does work, but not as intented I guess ?!
PS: I have 0.6.7.nightly-2018-04-26
in pom.xml
with the same result
Expected behavior Should work seamlessly
Actual behavior Getting the exception
Steps to replicate
gauge init java_maven_selenium
Replace dependencies
Version
Related to issue https://github.com/getgauge/gauge-java/issues/140