Skip to content
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

build: relax constraints of Selenium dependencies versions #1606

Merged

Conversation

valfirst
Copy link
Collaborator

@valfirst valfirst commented Dec 2, 2021

Change list

In a favor of flexibility the constraints of selenium dependencies versions are relaxed.

Types of changes

What types of changes are you proposing/introducing to Java client?

  • No changes in production code.
  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Details

https://docs.gradle.org/current/userguide/dependency_downgrade_and_exclude.html: "conflicting strict dependencies will trigger a build failure that you have to resolve".

An attempt to use java-client:8.0.0-beta in conjunction with Selenium 4.1.0 leads to build failures, like:

   > Could not resolve org.seleniumhq.selenium:selenium-remote-driver:{strictly 4.0.0}.
     Required by:
         project :xxxxxxx > io.appium:java-client:8.0.0-beta

In a favor of flexibility the constraints of selenium dependencies versions are relaxed.

@mykola-mokhnach
Copy link
Contributor

We could try that, although there were already issues about several breaking selenium API updates because of incompatible changes in their API.

Basically the question is how big is the probability that the next selenium version (minor, major or patch) is going to be incompatible to the current Appium client. And from my perspective such probability could be pretty high, since we don't only use public APIs, but rather perform many reflective calls to private/protected stuff and hack selenium lib here and there.

@mykola-mokhnach
Copy link
Contributor

mykola-mokhnach commented Dec 3, 2021

Maybe for now we could declare a strict version range like in https://docs.gradle.org/current/userguide/single_versions.html (Example 2):

version {
           strictly '[4, 5)'
           prefer "${seleniumVersion}"
        }

@valfirst valfirst force-pushed the do-not-mark-selenium-dependencies-versions-as-strict branch from 7af7ff8 to ac02157 Compare December 3, 2021 07:21
@valfirst valfirst changed the title build: do not mark selenium dependencies versions as strict build: relax constraints of Selenium dependencies versions Dec 3, 2021
@valfirst
Copy link
Collaborator Author

valfirst commented Dec 3, 2021

@mykola-mokhnach thank you for your comments, I really appreciate them, I've updated the PR following your hints

build.gradle Outdated Show resolved Hide resolved
@valfirst valfirst force-pushed the do-not-mark-selenium-dependencies-versions-as-strict branch from ac02157 to 06fedd1 Compare December 3, 2021 09:39
build.gradle Outdated Show resolved Hide resolved
https://docs.gradle.org/current/userguide/dependency_downgrade_and_exclude.html: "conflicting strict dependencies will trigger a build failure that you have to resolve".

An attempt to use `java-client:8.0.0-beta` in conjunction with Selenium 4.1.0 leads to build failures, like:
```
   > Could not resolve org.seleniumhq.selenium:selenium-remote-driver:{strictly 4.0.0}.
     Required by:
         project :xxxxxxx > io.appium:java-client:8.0.0-beta
```
In a favor of flexibility the constraints of selenium dependencies versions are relaxed.
@valfirst valfirst force-pushed the do-not-mark-selenium-dependencies-versions-as-strict branch from 06fedd1 to bc72fec Compare December 3, 2021 12:59
@valfirst valfirst merged commit f64e34f into master Dec 3, 2021
@mykola-mokhnach mykola-mokhnach deleted the do-not-mark-selenium-dependencies-versions-as-strict branch December 3, 2021 16:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants