Review if it makes sense to move the Quarkus extension back into this project.

[metacosm]

It's currently a maintenance burden to have two separate projects and also makes it confusing/difficult for users to figure out which version of the SDK is used for a given version of the Quarkus extension. It might therefore make sense to move the extension back here, provided the nice things we got by being part of the Quarkiverse can be ported over. /cc @maxandersen

[theishshah]

This was brought up at the community meeting today, I think we all agree it would make sense to consolidate the repos, noting that there may be some additional complexity for the build.

[maxandersen]

Didn't follow the comment on what version of operator sdk is used with what quarkus? What is that referring to? How would that change ?

About quarkiverse advantages it's mainly about automatic setup of quarkus registry and publish to maven central.

Other is doc publishing.

If we do it this way we would need to figure out how to handle the GAV/package rename.

Before that have you considered setting up direct testing and possible have the project as a sub module ?

[metacosm]

Didn't follow the comment on what version of operator sdk is used with what quarkus? What is that referring to? How would that change ?

Users have historically been confused about the Quarkus extension vs the SDK versions, i.e. if you're using the Quarkus extension at version 3.0.2, which version of the SDK are you using?

About quarkiverse advantages it's mainly about automatic setup of quarkus registry and publish to maven central. Other is doc publishing.

There's also participating in code.quarkus.io and eventually becoming part of the Quarkus platform (i.e. I don't want to move the extension back only to move it again down the line if it ever graduates to something more than it is now).

If we do it this way we would need to figure out how to handle the GAV/package rename.

People are not using the extension code directly so there shouldn't be an impact on users (at least, at first approximation) so I don't think that this would be a big deal.

Before that have you considered setting up direct testing and possible have the project as a sub module ?

Not sure I follow… if this comes to pass, the Quarkus extension would become a sub-module of the SDK maven project (but I suspect you're referring to a different kind of sub module (git, perhaps?)). The idea to move the extension back here would be to be able to work on both at the same time and that the SDK couldn't be released without the extension being up to date, which wouldn't be the case with a sub-module or simple testing integration to check for breakage.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[scrocquesel]

Don't know if it really matter or outweight the pros, but the quarkus extension sometimes needs to deal with quarkus platform version. A new version could be release without JOSDK improvement.

[metacosm]

This is indeed something we need to take into account, and while we could release new versions of JOSDK to deal with this, it definitely wouldn't be very elegant.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 14 days with no activity.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 14 days with no activity.