-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
launcher gets classpath from maven/gradle, #236 #419
Conversation
Signed-off-by: sriv <srikanth.ddit@gmail.com>
Signed-off-by: sriv <srikanth.ddit@gmail.com>
Signed-off-by: sriv <srikanth.ddit@gmail.com>
…sspath. Signed-off-by: Dharmendra Singh <dharmenn@thoughtworks.com>
…asspath. Signed-off-by: Dharmendra Singh <dharmenn@thoughtworks.com>
I have a concern with this patch, related to addressing the usage of the I finally got JQ, Maven, and all that installed so it would finally allow me to Please excuse my debugging attempts as I'm not familiar with this language. What I possibly have found is that
To try and see what the global:classpath is being set to, if it should be resolving a gauge_additional_libs of
As you can see, it does appear to have found the lib files, but it is putting them on the classpath all with in a "" string, separated by spaces. I'm assuming that syntax issue is why they are still not being found on the classpath. I played around with trying to alter the
which resulted in the following:
So that seems to have resolved the classpath issue, though there's still the weird So I'm not sure if I'm completely off base here, and I'm just doing something weird with trying to test this change out ahead of time, but I did want to bring it up just incase. |
Thanks for the analysis @taplar - I believe you may be on to something here. We'll investigate this and see how best to fix this. /cc @NivedhaSenthil |
Glad to hear I'm not completely off base! I do have a follow up with regards to the following error that was shown at the end of my last post.
I believe this error is related to the
I modified the
The thing I found interesting with that is that the file encoding option is ecapsulated in double quotes, while the value pulled from the gauge_jvm_args is just used as is. To test if this was the issue I modified the logic to the following. I created a new method to split the gauge_jvm_args value and add them each encapsulated with double quotes.
I then used it in the start task as follows.
Which, paired with my previous tinkering, resulted in the following.
So making the changes related to the gauge_additional_libs and the gauge_jvm_args resulted in my tests running again. |
This is great ... would you like to create a PR with these changes ? |
I could try to do so, however I am hesitant to do so for a few reasons. I am not familiar with the process for creating a PR for a public git repository and I would need to familiarize myself with any practices your project has in place. I am also not sure what issue number I would associate the change with for the commit message(s); if it would be this same one or a new one. Also, as I have previously stated, I am a novice when it comes to powershell scripts and from my point of view the changes I have tried were just to "get it working". I'm not confident enough with my proficiency of the language to know if there is a better way to do these changes, or to know if I am missing some edge case. |
( cat $GAUGE_GRADLE_BUILD_FILE; echo "task printCP { println sourceSets.test.runtimeClasspath.asPath }" ) > build.gradle.temp | ||
class_path=$(./gradlew -q -b build.gradle.temp printCP) | ||
rm build.gradle.temp | ||
class_path=$(./gradlew -q clean classpath) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a problem in windows with limits to classpath and command line length.
Although this on linux. I think there may be a limit in the output of $(./gradlew -q clean classpath)
long list of items with path to the jar file?
No description provided.