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

Move Kogito extension out of the Quarkus core repository #7815

Merged
merged 3 commits into from
Mar 16, 2020

Conversation

mariofusco
Copy link
Contributor

@mariofusco mariofusco commented Mar 12, 2020

The extension has been moved to the Kogito repository and is part of the Platform.

@boring-cyborg boring-cyborg bot added area/dependencies Pull requests that update a dependency file area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins area/infra-automation anything related to CI, bots, etc. that are used to automated our infrastructure area/kogito area/maven labels Mar 12, 2020
@geoand
Copy link
Contributor

geoand commented Mar 12, 2020

I assume that the docs need to be removed as well? And perhaps the references to kogito in some yaml metadata files?

@geoand
Copy link
Contributor

geoand commented Mar 12, 2020

Also, kogito needs to be removed from the CI configuration (which is why CI is failing)

@mariofusco
Copy link
Contributor Author

@geoand I just removed kogito from ci-actions.yml (and this was also the reason why Misc3 was failing). I cannot find any other yaml referencing it, am I missing something? Also couldn't we leave kogito documentation there even if the extension is now hosted in our codebase?

@gsmet
Copy link
Member

gsmet commented Mar 12, 2020

I think we should keep the doc in place (and adapt it if needed).

@geoand
Copy link
Contributor

geoand commented Mar 12, 2020

I believe we can leave the documentation but @maxandersen and @aloubyansky would have more to say about that case.

As for the YAML files, I found kogito mentioned in:
https://github.com/mariofusco/quarkus/blob/9d5f3455f92744815275ce1bfd3dc474a01280df/devtools/platform-descriptor-json/src/test/resources/fakeextensions.json#L1102

@maxandersen what does that file do?

@evacchi
Copy link
Contributor

evacchi commented Mar 12, 2020

I don't think this failure is related, wdyt @geoand ?

@geoand
Copy link
Contributor

geoand commented Mar 12, 2020

Yeah, the JVM 13 failure is known (it seems that sometimes CI can't install JVM 13)

@geoand
Copy link
Contributor

geoand commented Mar 12, 2020

This is +1 from me. I'm just waiting for @maxandersen and @aloubyansky to provide feedback on my question above

@evacchi
Copy link
Contributor

evacchi commented Mar 12, 2020

good let's just wait then, thanks!

@maxandersen
Copy link
Contributor

Earlier today we talked about this move to be something for 1.4 ? are we saying master is now ready for 1.4 and 1.3.x is branched ?

@maxandersen what does that file do?

its used for testing the parsing of a platform - not important and can be kept as is.

@maxandersen
Copy link
Contributor

btw. where is the new location ? and is that something that is releasable separate from kogito releases so we neither of us get stuck if we need to update the extension ?

@aloubyansky
Copy link
Member

Master is 1.4.

@evacchi
Copy link
Contributor

evacchi commented Mar 12, 2020

ouch we were hoping to include this in 1.3.0 :(

@geoand
Copy link
Contributor

geoand commented Mar 12, 2020

@gsmet ^

@gsmet
Copy link
Member

gsmet commented Mar 12, 2020

No. It won’t be in 1.3. It’s too late.

@gsmet
Copy link
Member

gsmet commented Mar 12, 2020

I was on my phone so here are more details:

  • you can't drop a PR like that the day before the Final release. We had 2 candidate releases for that.
  • I don't see any PR for the Platform? How will people install this extension? How will people migrate their existing applications?

As for the OptaPlanner fix, maybe it should be in a different PR so that we can include it in 1.3.1? That being said, I'm not sure it's the right fix because I'm worried people will have duplicate substitutions if they use both Kogito and OptaPlanner.

/cc @ge0ffrey

@geoand
Copy link
Contributor

geoand commented Mar 13, 2020

@gsmet the Optaplanner fix is only needed in the is PR because Kogito was bumped. It's not needed in the current master.

I agree that it is a little too late for 1.3

@evacchi
Copy link
Contributor

evacchi commented Mar 13, 2020

unfortunately we had delays with releasing 0.8.0. We understand it's too late, we thought there was more time before Final. There is no PR for platform because we were waiting for merging this first; the branch should be here https://github.com/mariofusco/quarkus-platform/tree/k1251 /cc @mariofusco

it's fine to merge this to master. As for the proper fix to the OptaPlanner extension, we are already discussing with @ge0ffrey on the matter

@geoand
Copy link
Contributor

geoand commented Mar 13, 2020

So I am +1 for merging this to master now (the sooner the better to give the most time possible to prepare the rest of the stuff that needs to be done to have Kogito in the platform for 1.4)

import com.oracle.svm.core.annotate.TargetClass;

@TargetClass(className = "org.drools.core.rule.builder.dialect.asm.ClassGenerator")
final class Target_org_drools_core_rule_builder_dialect_asm_ClassGenerator {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-1
This is a substitution that should happen in Kogito (= Drools), not in OptaPlanner. It's not OptaPlanner alone that will suffer from it. OptaPlanner should not work around it, Kogito should fix it. Kogito 0.8.0 is borked, we need a Kogito 0.8.1 release.

Copy link
Contributor

@geoand geoand Mar 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to get the PR in, there is no other way. If you folks want to wait for a Kogito release that doesn't suffer from this, that's up to you :).
But if you want it in no, there is no other way

Copy link
Contributor

@ge0ffrey ge0ffrey Mar 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am willing to comprise to merge it like this for Quarkus 1.3.0 as a temporarily workaround (*), if there's a commitment to revert it by Quarkus 1.3.1 by releasing and using Kogito 0.8.1. @mariofusco wdyt?

(*) Let's add a comment stating that it's a temporarily workaround.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In any case, this PR isn't making it into any 1.3.x line. We are talking purely for 1.4, whether it goes in as is, or with a new Kogito version

@ge0ffrey
Copy link
Contributor

ge0ffrey commented Mar 13, 2020

As for the OptaPlanner fix, maybe it should be in a different PR so that we can include it in 1.3.1? That being said, I'm not sure it's the right fix because I'm worried people will have duplicate substitutions if they use both Kogito and OptaPlanner.

/cc @ge0ffrey

@gsmet Master currently is fine, there is no bug there.
Just for the record: the "OptaPlanner fix" is not a bug in OptaPlanner, it's a regression in Kogito 0.8.0 from 0.7.1 that only surfaced in the OptaPlanner-Quarkus integration test.
This PR upgrade Kogito from 0.7.1 to 0.8.0 and contains a workaround, to get OptaPlanner to work, by Graal substituting something in Kogito-Drools. It does not fix the regression for other Kogito users, but they are less likely to run into it. I personally don't like this approach.
@mariofusco @evacchi I think the real fix is a hotfix Kogito 0.8.1 release asap that includes the substitution in Kogito-Drools itself. Wydt? Is that practical?

@gsmet
Copy link
Member

gsmet commented Mar 13, 2020

Well, there's no rush. This won't be in either 1.3.0 or 1.3.1. It will be merged to master for 1.4, planned in about a month (so 3 weeks for the CR).

That being said, I would recommend to follow up on this soon to avoid having the same issue for 1.4.

@evacchi
Copy link
Contributor

evacchi commented Mar 13, 2020

I think it's better if we merge this and then release the hotfix otherwise we can't still update the platform bom, which is the priority

@geoand
Copy link
Contributor

geoand commented Mar 13, 2020

I think it's better if we merge this and then release the hotfix otherwise we can't still update the platform bom, which is the priority

+1 from. @gsmet , @ge0ffrey ?

@maxandersen
Copy link
Contributor

+1 on merging into master sooner rather than later.

@gastaldi gastaldi added this to the 1.4.0 milestone Mar 13, 2020
@gastaldi
Copy link
Contributor

+1 to merge to master. Any objections @gsmet ?

import com.oracle.svm.core.annotate.TargetClass;

@TargetClass(className = "org.drools.core.rule.builder.dialect.asm.ClassGenerator")
final class Target_org_drools_core_rule_builder_dialect_asm_ClassGenerator {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the class name different from KogitoSubstitutions?

Copy link
Contributor

@geoand geoand Mar 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't really matter since it's going away really really soon 😎

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well yeah, it's just that it's confusing to look at this class and see another name :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea was that multiple substitutions might have been needed. For example like Netty.
It turned out that it wasn't needed 😊

@mariofusco
Copy link
Contributor Author

@ge0ffrey if this is ok for you can you please approve it asap? Thanks.

@geoand
Copy link
Contributor

geoand commented Mar 16, 2020

If @ge0ffrey approves, I'll merge it right away so the Kogito team can proceed

@gsmet
Copy link
Member

gsmet commented Mar 16, 2020

@ge0ffrey told he was ok with this here: #7815 (comment) so I would say let's proceed.

@mariofusco please follow up on the substitution though. We need a proper fix before 1.4 is released.

Thanks all.

@gsmet gsmet merged commit e5c3d91 into quarkusio:master Mar 16, 2020
@mariofusco
Copy link
Contributor Author

@gsmet thanks. The proper fix is already on kogito master and will be available with kogito 0.8.1.

@gsmet gsmet changed the title Remove Kogito extension from Quarkus codebase Move Kogito extension out of the Quarkus core repository Apr 14, 2020
@gsmet
Copy link
Member

gsmet commented Apr 14, 2020

@mariofusco did you change the GA of the extension? If so could you provide the new one as it requires a note in the migration guide.

Thanks!

@mariofusco
Copy link
Contributor Author

@gsmet the new GA is org.kie.kogito:kogito-quarkus

Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/dependencies Pull requests that update a dependency file area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins area/infra-automation anything related to CI, bots, etc. that are used to automated our infrastructure area/kogito area/maven release/noteworthy-feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants