Closed smlambert closed 3 years ago
a place where member distributors can market their binaries, essentially a centralized location on a website
We should document what vendors can expect because that also influences the design of the website. I assume that the more we treat the vendor's binaries like Temurin, the more attractive the marketplace will be.
Criteria?
:+1:
(And: no bickering like "our binary is better than yours" :smirk: )
How can these be served up?
That's a great proposal. I like to expand it with some details (my proposal, some parts might be controversial, therefore up for discussion):
<productname>-<version>-binaries
, for example temurin-11-binaries
or dragonwell-8-binaries
) is created in the Adoptium GitHub org where the vendor can upload their binaries to [vendor neutrality is ensured, no problems because we have to obtain binaries from somewhere].
adoptium/dragonwell:11
or `adoptium/temurin:11
.The Linux packages are already being prepared to work like that. MSI (Windows), PKG (macOS) would need separate jobs that aren't embedded into the build pipeline. Notarization on macOS might need some attention because resigning might break the jmods.
I will add this topic to the Adoptium WG agenda for discussion
CC @johnoliver as he starts to think about API design
some notes from working group call on Thursday March 25th:
Notes from Thursday, April 1st WG call:
Additional note raised in Community call regarding APIv4 planning:
Further to this @johnoliver believes the new API at Adoptium could map an Adoptium API request to the vendor API or implement a binary discovery mechanism in the case where there is no API available. There would not necessarily be a need to ask vendors to store their binaries in GitHub releases.
Another option is to back onto foojay.io's API (pros and cons to that).
We have to let vendors serve up their own binaries. Adoptium is just one of the vendors. So conceptually there is the current role and a new role for our API when moved to Adoptium:
the current API role, much as it exists today (assets|binaries|info|etc), remains the way to get details about and download Temurin builds. The jvm_impl
becomes a lot less interesting, as it will only return useful data for hotspot. For backwards compatibility I'd be inclined to keep the parameter, and have it return the empty set for openj9;
The "market API" is likely a new path through the same api.adoptium.net - that’s an implementation detail :-) But it should be clear when you are asking for information about the available binaries listed in the vendor marketplace, and when you are asking about info for Temurin binaries. As such, I would suggest not trying to update all the existing API paths to accommodate other vendors' information. Just populate a new marketplace catalog and include Temurin in there.
I think we're going to need some concrete examples in the form of HTTP Get requests to ensure we are walking the correct line in each case.
closing as this has now moved to https://github.com/adoptium/adoptium/issues/7
Based on some conversation both in working group, transition meetings and the Adoptium community call, let's put down some additional details about an Adoptium marketplace and start to flush out implementation details and challenges.
What is a marketplace?
Criteria?
How can these be served up?
It may be useful to look at the diagram from https://github.com/AdoptOpenJDK/TSC/issues/158#issuecomment-641708282 where the JDK production swim lane is owned by the member who in the publish stage pushes to a releases repo.
Then the installers and docker images swim lane could (potentially) be a mechanism of the marketplace rather than expect members to each deliver unique solutions for these artifacts.