Closed fjtirado closed 8 months ago
@porcelli I think you are misunderstanding the change. Build has to be disable (as the test) becuase oracle driver is being removed But once you setup an example with the driver (required) and quarkus build goal (which is done for all examples projects), the addon will still work. so the build removal is not changing anything besided disabling the test, it is just achieving whay you were trying to do with your PR (because that build is only needed for the quarkus IT phase)
PR job #5
was: UNSTABLE
Possible explanation: This should be test failures
Please look here: https://ci-builds.apache.org/job/KIE/job/kogito/job/main/job/pullrequest_jobs/job/kogito-apps-pr/job/PR-1971/5/display/redirect
Test results:
Those are the test failures:
The newer Oracle JDBC drivers are released with FDHUT license https://download.oracle.com/otn-pub/otn_software/jdbc/FDHUT_LICENSE.txt?AuthParam=1706622347_ab29e2dc8dd1eb1814a13b41e7e8094f
These JDBC driver are easy to download and use from Maven central like any other JARs.
It may be good to get ASF legal to check this license.
@davsclaus we have this issue with LEGAL, Justin McLean provided his perspective on the license there.
Spark member seems to have a different interpretation;
The KIE codebase seems to already depend on the latest Oracle JDBC driver.
@porcelli I don't think we are infringing any legal aspects here. We are completely removing Oracle driver references and won't build or release this component. @fjtirado maybe we also have to remove it from the parent POM/BOM.
After 10.x we can move this code to a contrib repo and let it there be maintained by other members of the community, having their release pacing. Similar to what Quarkus Extensions do.
@porcelli As discusse Im working on a test refactor, moving the PR to draft
I uploaded a test refactor version that still have oracle. The next move is to change oracle by h2 (a common relational) and remove oracle container from runtimes. I guess we should also remove the oracle container, isnt it?
yes, we need also remove container. expect to have another PR for the runtime repo that also have Oracle references.
yes, we need also remove container. expect to have another PR for the runtime repo that also have Oracle references.
yes. I have another PR on runtimes which I will be updating to to remove container.
@porcelli I have to fix breaking test, but more or less this is it We keep the generic jdbc code (from which a user can add oracle support to their project) tested and remove oracle driver and Oracle IT test that does not longer make sense.
PR job #18
was: UNSTABLE
Possible explanation: This should be test failures
Please look here: https://ci-builds.apache.org/job/KIE/job/kogito/job/main/job/pullrequest_jobs/job/kogito-apps-pr/job/PR-1971/18/display/redirect
Test results:
Those are the test failures:
@fjtirado so basically we move from oracle to jdbc (more general) and now we have jpa + jdbc implementation (two generic impl) ¿?
@fjtirado so basically we move from oracle to jdbc (more general) and now we have jpa + jdbc implementation (two generic impl) ¿?
We have just one jpa implementation and use that one to test postgres (and its non standard jsonb column) and generic jdbc (blob instead of jsonb), In future, I would like to explore the possibility of changing from jsonb to ElementColletion and do not divert because of that column, but this implies a schema change and it is a different discussion.
@porcelli Oracle package renamed to jdbc (h2 is a convenient way to test, should be working with any JPA compliant db), thanks for the pointer!
@elguardian Unfortunately I do not understand your concern, Which change are you requesting? Naming of the module? If so, which one do you consider right? The reason I named the module jdbc i because it will work with any jdbc compliant DB. I could have called it jsonasblob, but the name looks worse to me. As I already mention we should unify the handling of json column in future (the standard is really yo use an auxiliar table for map like fields). The JPA module should not directly be added as dependency, you will either add the "jdbc" one or the postgres one.
Hi @fjtirado seems a bit weird to me. for instance
but if you are using the jdbc (which is really jpa based with some overriding) you are working with anything that is compliant with the jpa implementation but requires that overriding (not the entire jdbc)
so brifly
we have a jpa (common that is not meant to be used by anybody and that could really work without anything else just defining the proper data source and adding the driver).. in fact there is no producer in here. I would suggests maybe for jpa-common.
jdbc as a wrap of the jpa module plus overriding (the naming does not reflect what really is). I do think it is not really good name. I would say jpa-flavor being the flavor you are supporting. I can guarantee you that for pgsql big users will use bytea to avoid the vacuun utility (instead of oid or blobs...). so probably will have something like jpa-bytea or something like that. So keep in mind that better have this in mind now that start renaming things afterwards.
I think the strucutre allows some extension (probably not my preferred way) but it complies the need of some databases so it is fine. The thing doing the split (between jpa common and jdbc) it is only confusing as jpa is not meant to use by anybody. I would suggest jpa-common jpa-std (standard if the blob are meant to be supported by everyone....) jpa-byte... (or whatever flavours we ship.
The name does not reflect what really does, just calling jdbc because it seems we are using standard sql without the jpa middle man.
We have three modules:
@elguardian Renaming done as per https://github.com/apache/incubator-kie-kogito-apps/pull/1971#issuecomment-1932114905
Removing quarkus-jdbc-oracle and disable all associated test because of legal issues with oracle driver
We also need to remove the driver from kogito-test-utils with runtimes PR https://github.com/apache/incubator-kie-kogito-runtimes/pull/3381