jfrog / jfrog/artifactory-client-java

listRemoteFolderItems can be accessed in multiple ways

Open
#337 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

question
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 RemoteRepository object and uses the value defined for the RepositorySettings object.

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.