-
Notifications
You must be signed in to change notification settings - Fork 251
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
extensions: implement catalog for data management api #1195
extensions: implement catalog for data management api #1195
Conversation
|
||
import java.util.concurrent.CompletableFuture; | ||
|
||
public interface CatalogService { |
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 already a CatalogService
interface. Shouldnt those be merged?
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.
I'm not sure it would be a good idea, they serve different purposes and have different dependencies
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.
Since we decided to have the *Service
notation on the data management api, probably the other could be named differently, like CatalogProvider
or CatalogGenerator
@Override | ||
public CompletableFuture<Catalog> getByProviderUrl(String providerUrl) { | ||
var request = CatalogRequest.Builder.newInstance() | ||
.protocol("ids-multipart") |
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.
Do we really want to hardcode this? Maybe a setting with a default value being "ids-multipart" should be preferred?
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.
I just moved the functionality from control
api to data-management
, so I prefer to not put too much stuff in there. I see that "ids-multipart" is hardcoded pretty much everywhere, so maybe it's a thing to be addressed in another issue.
...lipse/dataspaceconnector/api/datamanagement/catalog/CatalogApiControllerIntegrationTest.java
Outdated
Show resolved
Hide resolved
...java/org/eclipse/dataspaceconnector/api/datamanagement/catalog/CatalogApiControllerTest.java
Outdated
Show resolved
Hide resolved
...rg/eclipse/dataspaceconnector/api/datamanagement/catalog/service/CatalogServiceImplTest.java
Outdated
Show resolved
Hide resolved
...ain/java/org/eclipse/dataspaceconnector/api/datamanagement/catalog/CatalogApiController.java
Outdated
Show resolved
Hide resolved
...java/org/eclipse/dataspaceconnector/api/datamanagement/catalog/CatalogApiControllerTest.java
Outdated
Show resolved
Hide resolved
...rg/eclipse/dataspaceconnector/api/datamanagement/catalog/service/CatalogServiceImplTest.java
Outdated
Show resolved
Hide resolved
...-test/runner/src/test/java/org/eclipse/dataspaceconnector/test/e2e/EndToEndTransferTest.java
Show resolved
Hide resolved
Codecov Report
@@ Coverage Diff @@
## main #1195 +/- ##
============================================
+ Coverage 58.31% 58.38% +0.07%
- Complexity 2708 2717 +9
============================================
Files 694 697 +3
Lines 15431 15453 +22
Branches 1047 1047
============================================
+ Hits 8999 9023 +24
+ Misses 6009 6007 -2
Partials 423 423
Continue to review full report at Codecov.
|
What this PR changes/adds
Introduce Data Management API for catalog
Why it does that
To provide an api module for the
catalog
feature.Further notes
/catalog
api accept is theproviderUrl
EndToEndTest
pass through the/catalog
request, to have a more complete E2E scenarioLinked Issue(s)
Closes #1118
Checklist
no-changelog
)