Re: camel-restdsl-openapi-plugin 4.4.0 does not support openApi 3.1.0 specs: Unsupported document type: io.apicurio.datamodels.models.openapi.v31.OpenApi31DocumentImpl
Hi Yes 3.1 is not supported. You are welcome to create a JIRA and are also welcome to implement the code and send a PR On Mon, Feb 26, 2024 at 7:13 PM Ja Li wrote: > Hi there, > > I was trying to use the most up-to-date version of the following Maven > plugin to generate the REST routes and DTOs for a given openApi 3.1.0 spec: > org.apache.camel > camel-restdsl-openapi-plugin > 4.4.0 > > with default settings in the section and using the option: > "camel-restdsl-openapi:generate". > > Unfortunately it gave me this error: > [ERROR] Failed to execute goal > org.apache.camel:camel-restdsl-openapi-plugin:4.4.0:generate-with-dto > (generate-sources) on project openapi-test: Execution generate-sources of > goal org.apache.camel:camel-restdsl-openapi-plugin:4.4.0:generate-with-dto > failed: Unsupported document type: > io.apicurio.datamodels.models.openapi.v31.OpenApi31DocumentImpl > > (The Maven plugin camel-restdsl-openapi-plugin uses apicurio version 2.0.3 > (see: > > https://github.com/apache/camel/blob/main/tooling/openapi-rest-dsl-generator/pom.xml > => > > https://github.com/apache/camel/blob/e248d5cd78912c0b12f41565b44193f6d2db0008/parent/pom.xml > ) > but this apicurio version already contains/supports an openApi 3.1 > datamodel. It's just that this plugin seems not to be able to handle this > data model) > > So isn't the plugin compatible with openApi Spec 3.1.0? I can't see that > restriction from the plugin documentation here: > > https://github.com/apache/camel/blob/main/tooling/maven/camel-restdsl-openapi-plugin/src/main/docs/camel-restdsl-openapi-plugin.adoc > > > Thanks and kind regards > > Jacob > -- Claus Ibsen - @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
camel-restdsl-openapi-plugin 4.4.0 does not support openApi 3.1.0 specs: Unsupported document type: io.apicurio.datamodels.models.openapi.v31.OpenApi31DocumentImpl
Hi there, I was trying to use the most up-to-date version of the following Maven plugin to generate the REST routes and DTOs for a given openApi 3.1.0 spec: org.apache.camel camel-restdsl-openapi-plugin 4.4.0 with default settings in the section and using the option: "camel-restdsl-openapi:generate". Unfortunately it gave me this error: [ERROR] Failed to execute goal org.apache.camel:camel-restdsl-openapi-plugin:4.4.0:generate-with-dto (generate-sources) on project openapi-test: Execution generate-sources of goal org.apache.camel:camel-restdsl-openapi-plugin:4.4.0:generate-with-dto failed: Unsupported document type: io.apicurio.datamodels.models.openapi.v31.OpenApi31DocumentImpl (The Maven plugin camel-restdsl-openapi-plugin uses apicurio version 2.0.3 (see: https://github.com/apache/camel/blob/main/tooling/openapi-rest-dsl-generator/pom.xml => https://github.com/apache/camel/blob/e248d5cd78912c0b12f41565b44193f6d2db0008/parent/pom.xml ) but this apicurio version already contains/supports an openApi 3.1 datamodel. It's just that this plugin seems not to be able to handle this data model) So isn't the plugin compatible with openApi Spec 3.1.0? I can't see that restriction from the plugin documentation here: https://github.com/apache/camel/blob/main/tooling/maven/camel-restdsl-openapi-plugin/src/main/docs/camel-restdsl-openapi-plugin.adoc Thanks and kind regards Jacob
Re: Excessive use on the "git-websites" runners?
Hi all, I don't really remember why pull request builds were enabled on Jenkins, we use Jenkins for the ability to publish the website only. Anyhow, https://ci-builds.apache.org/job/Camel/job/Camel.website/ should now only build for changes on `main`. zoran On Mon, Feb 26, 2024 at 9:55 AM Christofer Dutz wrote: > > Yeah … that’s a good idea … also what we are doing in other projects. > > Generally, we only build on Jenkins for utilizing the ability to deploy > artifacts (SNAPSHOTS) or update our website on Jenkins. > So, I like this idea. > > Chris > > Von: Claus Ibsen > Datum: Freitag, 23. Februar 2024 um 12:43 > An: dev@camel.apache.org > Betreff: Re: Excessive use on the "git-websites" runners? > Claus Ibsen > - > @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > > > On Fri, 23 Feb 2024 at 12.34, Zoran Regvart > wrote: > > > Hi Chris, Cameleers, > > chiming in a bit late, apologies for that. I don't think we need to > > build PR builds on Jenkins. We already build on GitHub Actions and > > (when netlify CLI gets fixed) get previews there. I'd like to disable > > building branches other than main on Jenkins. I think this should help > > quite a bit with the queue depth on Jenkins. > > > > Thoughts? > > > > Yes that is a good idea > > > > zoran > > > > On Tue, Feb 20, 2024 at 11:13 AM Christofer Dutz > > wrote: > > > > > > Hi all, > > > > > > Guess our release is out and the website was updated before that … so > > guess I’m fine. > > > And if you say that this is an unusual case, I also see no problems. > > > From my perspective it just looked as if every PR was blocking a runner > > and that would have been a problem, of course. > > > > > > If that’s not the case, I guess there’s no big problem. But limiting the > > parallel usage of these runners is of course a good idea anyway. > > > > > > Chris > > > > > > Von: Claus Ibsen > > > Datum: Montag, 19. Februar 2024 um 13:43 > > > An: dev@camel.apache.org > > > Betreff: Re: Excessive use on the "git-websites" runners? > > > Hi > > > > > > Yeah ideally those CVEs should be in 1 merge to main - so they were > > > released together. > > > > > > And frankly the website is rebuild from scratch each time, instead of > > being > > > able to update only parts of it. > > > The CVEs only affect the security page + a new page per CVE. > > > > > > I stopped one of the builds, as there is a 2nd build in the queue to > > > publish the last CVE. > > > That should put your job ahead of ours. > > > > > > > > > > > > > > > > > > On Mon, Feb 19, 2024 at 1:37 PM Andrea Cosentino > > wrote: > > > > > > > I don't think it would work on our website, but Zoran could have more > > > > information about this. > > > > > > > > What we could do, it's maybe limit the number of builds on git-websites > > > > nodes concurrently. > > > > > > > > Il giorno lun 19 feb 2024 alle ore 13:30 Christofer Dutz < > > > > christofer.d...@c-ware.de> ha scritto: > > > > > > > > > Hi, > > > > > > > > > > as the PLC4X build also uses that, perhas what we did would be also > > an > > > > > option for you? > > > > > We build the website on our own VM, but stash the built website … > > then on > > > > > the git-websites agent, we simply unstash what was built on our VM > > and > > > > > deploy that … this reduces the lock we have on shared infra to the > > > > minimum > > > > > … We’re also doing the same with deploying snapshots: We build on > > our VM > > > > > and use one of the ubuntu agents to deploy. > > > > > > > > > > Cause running a build on a PR, should probably not require staging of > > > > > website changes … as soon as the PR is merged, then of course. > > > > > > > > > > Chris > > > > > > > > > > > > > > > Von: Andrea Cosentino > > > > > Datum: Montag, 19. Februar 2024 um 13:20 > > > > > An: dev > > > > > Betreff: Re: Excessive use on the "git-websites" runners? > > > > > Usually there is not that much activities. There were 3 PRs related > > to > > > > cves > > > > > and some related to the last release done during the weekend. So this > > > > > should be just a temporary saturation. We don't have other way of > > > > > publishing the website except using that mechanism. > > > > > > > > > > Il lun 19 feb 2024, 13:13 Christofer Dutz > > ha > > > > > scritto: > > > > > > > > > > > Hi all, > > > > > > > > > > > > I’m currently trying to finish up some stuff for the upcoming PLC4X > > > > > > release. However am having problems because every time I want to > > update > > > > > our > > > > > > website, I have to wait a long, long time, because all 3 runners > > in the > > > > > > “git-websites” class (websites1, websites2 and websites3) are > > blocked > > > > > with > > > > > > really long running builds of Apache Camel. > > > > > > > > > > > > Most all have the tags associated with PRs … so I am asking > > myself: Do > > > > > > these builds have to be on git-websites? If not … it would be > > > > appreciated > > > > > > if you wouldn’t keep on
AW: Excessive use on the "git-websites" runners?
Yeah … that’s a good idea … also what we are doing in other projects. Generally, we only build on Jenkins for utilizing the ability to deploy artifacts (SNAPSHOTS) or update our website on Jenkins. So, I like this idea. Chris Von: Claus Ibsen Datum: Freitag, 23. Februar 2024 um 12:43 An: dev@camel.apache.org Betreff: Re: Excessive use on the "git-websites" runners? Claus Ibsen - @davsclaus Camel in Action 2: https://www.manning.com/ibsen2 On Fri, 23 Feb 2024 at 12.34, Zoran Regvart wrote: > Hi Chris, Cameleers, > chiming in a bit late, apologies for that. I don't think we need to > build PR builds on Jenkins. We already build on GitHub Actions and > (when netlify CLI gets fixed) get previews there. I'd like to disable > building branches other than main on Jenkins. I think this should help > quite a bit with the queue depth on Jenkins. > > Thoughts? > Yes that is a good idea > zoran > > On Tue, Feb 20, 2024 at 11:13 AM Christofer Dutz > wrote: > > > > Hi all, > > > > Guess our release is out and the website was updated before that … so > guess I’m fine. > > And if you say that this is an unusual case, I also see no problems. > > From my perspective it just looked as if every PR was blocking a runner > and that would have been a problem, of course. > > > > If that’s not the case, I guess there’s no big problem. But limiting the > parallel usage of these runners is of course a good idea anyway. > > > > Chris > > > > Von: Claus Ibsen > > Datum: Montag, 19. Februar 2024 um 13:43 > > An: dev@camel.apache.org > > Betreff: Re: Excessive use on the "git-websites" runners? > > Hi > > > > Yeah ideally those CVEs should be in 1 merge to main - so they were > > released together. > > > > And frankly the website is rebuild from scratch each time, instead of > being > > able to update only parts of it. > > The CVEs only affect the security page + a new page per CVE. > > > > I stopped one of the builds, as there is a 2nd build in the queue to > > publish the last CVE. > > That should put your job ahead of ours. > > > > > > > > > > > > On Mon, Feb 19, 2024 at 1:37 PM Andrea Cosentino > wrote: > > > > > I don't think it would work on our website, but Zoran could have more > > > information about this. > > > > > > What we could do, it's maybe limit the number of builds on git-websites > > > nodes concurrently. > > > > > > Il giorno lun 19 feb 2024 alle ore 13:30 Christofer Dutz < > > > christofer.d...@c-ware.de> ha scritto: > > > > > > > Hi, > > > > > > > > as the PLC4X build also uses that, perhas what we did would be also > an > > > > option for you? > > > > We build the website on our own VM, but stash the built website … > then on > > > > the git-websites agent, we simply unstash what was built on our VM > and > > > > deploy that … this reduces the lock we have on shared infra to the > > > minimum > > > > … We’re also doing the same with deploying snapshots: We build on > our VM > > > > and use one of the ubuntu agents to deploy. > > > > > > > > Cause running a build on a PR, should probably not require staging of > > > > website changes … as soon as the PR is merged, then of course. > > > > > > > > Chris > > > > > > > > > > > > Von: Andrea Cosentino > > > > Datum: Montag, 19. Februar 2024 um 13:20 > > > > An: dev > > > > Betreff: Re: Excessive use on the "git-websites" runners? > > > > Usually there is not that much activities. There were 3 PRs related > to > > > cves > > > > and some related to the last release done during the weekend. So this > > > > should be just a temporary saturation. We don't have other way of > > > > publishing the website except using that mechanism. > > > > > > > > Il lun 19 feb 2024, 13:13 Christofer Dutz > ha > > > > scritto: > > > > > > > > > Hi all, > > > > > > > > > > I’m currently trying to finish up some stuff for the upcoming PLC4X > > > > > release. However am having problems because every time I want to > update > > > > our > > > > > website, I have to wait a long, long time, because all 3 runners > in the > > > > > “git-websites” class (websites1, websites2 and websites3) are > blocked > > > > with > > > > > really long running builds of Apache Camel. > > > > > > > > > > Most all have the tags associated with PRs … so I am asking > myself: Do > > > > > these builds have to be on git-websites? If not … it would be > > > appreciated > > > > > if you wouldn’t keep on blocking all runners. Of is currently > something > > > > out > > > > > of the ordinary going on? > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > -- > > Claus Ibsen > > - > > @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > -- > Zoran Regvart >
