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

get manifest data #71

Open
krishnaglodha opened this issue Nov 17, 2024 · 1 comment
Open

get manifest data #71

krishnaglodha opened this issue Nov 17, 2024 · 1 comment
Assignees

Comments

@krishnaglodha
Copy link
Collaborator

when we hit localhost:8080/geoserver/rest/about/manifest.json we get data as file manifest (2).json, for the pydantic, it is difficult to gauge
what might be the dictionary content, of each resource, should we just use dict for it ?

@ricardogsilva
Copy link
Collaborator

Looking at the manifest (here is a formatted snippet):

{
  "about": {
    "resource": [
      # other resources omitted for brevity
      {
        "@name": "GeographicLib-Java-1.49",
        "Archiver-Version": "Plexus Archiver",
        "Manifest-Version": 1,
        "Created-By": "Apache Maven 3.3.9",
        "Built-By": "ckarney",
        "Build-Jdk": "1.8.0_144"
      },
      {
        "@name": "JavaAPIforKml-2.2.0",
        "Archiver-Version": "Plexus Archiver",
        "Manifest-Version": 1,
        "Created-By": "Apache Maven",
        "Built-By": "flori",
        "Build-Jdk": "1.6.0_15"
      },
      {
        "@name": "aircompressor-0.27",
        "Implementation-Title": "aircompressor",
        "Specification-Version": 0.27,
        "Build-Time": "2024-05-20T14:15:10-0700",
        "Implementation-Version": 0.27,
        "Manifest-Version": 1,
        "Created-By": "Maven Jar Plugin 3.2.0",
        "Build-Jdk-Spec": 21,
        "Specification-Title": "aircompressor",
        "Git-Commit-Id": "e139a31be059855a5a70f6994a4ecaa0adbbea7a"
      }
    ]
  }
}

it seems to be a representation of the standard Java manifest files:

Therefore these do have a strict schema that we can use to build our pydantic models.

Would we want to do this though?

I think we should keep only the relevant bits of this payload - and at the moment I'm not sure what those would be. Perhaps we can start by keeping only the @name property (as this seems to be a combination of the Implementation-Title and Implementation-Version properties).

With this in mind, perhaps geoserverx would simply return a list of strings, where each string would be the @name property of the original response payload.

@ricardogsilva ricardogsilva moved this from Backlog to Todo in geoserverx Jan 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

3 participants