jfrog / jfrog/artifactory-client-java
listRemoteFolderItems can be accessed in multiple ways
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 331
- Forks
- 163
- Avg merge
- 20h 9m
- Merged PRs (30d)
- 1
Description
In the Java API there are two ways to get or set a remote repository's listRemoteFolderItems property, one via the RemoteRepository class, and one via the RepositorySettings class. E.g.:
RemoteRepository repo = /* ... a generic remote repository ...*/;
repo.isListRemoteFolderItems(); // 1
((GenericRepositorySettings)repo.getRepositorySettings()).getListRemoteFolderItems(); // 2
When I check the REST API of Artifactory, there's only a single related property, so it's a bit confusing to have two ways of accessing it.
More importantly, it seems that the two properties work a differently:
- When I read a remote repository from Artifactory, both properties are set according to the value on the server.
- When I write the repository, it ignores the property on the
RemoteRepositoryobject and uses the value defined for theRepositorySettingsobject.
Which of these properties should be used? Is it ok in all cases to just use the property in the RepositorySettings object and simply ignore the property on the RemoteRepository?
If so, would it be possible to change artifactory-client-java and remove the unnecessary one?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the RemoteRepository and RepositorySettings APIs and compare their listRemoteFolderItems accessors with the single related Artifactory REST property described in the issue. Determine which accessor is authoritative for reads and writes, then define whether the redundant API should be removed; done means the Java API has one unambiguous behavior consistent with REST.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100