Open angrymango opened 3 years ago
lukaseder
commented
3 years ago Is there anything we could do from our side to make this work more easily? E.g. we could provide free license keys to help you test this integration, if you're not publishing the built artifacts containing jOOQ anywhere...
angrymango
commented
3 years ago @lukaseder a test license key would be a big help! jOOQ libraries will not be published anywhere.
lukaseder
commented
3 years ago Great, I'll be in touch by email
maxandersen
commented
3 years ago @lukaseder thanks for offering here.
To you and @angrymango, we have to be careful though. One of the criteria we have on quarkiverse hub is that the extensions are open source which includes their build. If you set up a build in github actions CI using a free test license we do need to check with red hat legal how we handle that. I'm happy to do that and my guess is that it is fine but this is the first case we have of building against non-open non-publically-available bits. I'm happy to do check for you - just ping me on manderse (at) redhat.com.
Another alternative for this could also be to have at jooq github setup a jooq-pro-quarkus extension that depends on the quarkiverse one which would be separate - but lets see what options we end up with.
lukaseder
commented
3 years ago One of the criteria we have on quarkiverse hub is that the extensions are open source which includes their build [...] but this is the first case we have of building against non-open non-publically-available bits
How does this work for commercial JDBC drivers?
My intention here was not to publish any built artifacts which contain commercial distributions of jOOQ, but to help make sure whatever is being offered here will work also with the commercial distributions of jOOQ.
maxandersen
commented
3 years ago How does this work for commercial JDBC drivers?
the one we test in community are all available in maven central, even oracle's.
Drivers that are somehow not possible to use in open available builds we find other ways of testing (i.e. internally during red hat productization efforts or tested by the vendor itself).
My intention here was not to publish any built artifacts which contain commercial distributions of jOOQ, but to help make sure whatever is being offered here will work also with the commercial distributions of jOOQ.
Yes, I fully get it and I have the same intent/interest thus interested in finding a way as I'm sure it won't be the last example of things that has mixed source licenses involved.
lukaseder
commented
3 years ago How does this work for commercial JDBC drivers?
the one we test in community are all available in maven central, even oracle's.
But you said "open source" (legal distinction), not "available in maven central" (technical distinction). So, perhaps, this isn't really the first time this happens. With the commercial drivers included in "open available builds", the question about who is really accepting the license at what point remains, I guess?
Drivers that are somehow not possible to use in open available builds we find other ways of testing (i.e. internally during red hat productization efforts or tested by the vendor itself).
Well, I could definitely add something to our build pipeline too, though I'm not using github actions. If there's a simple build based on the OSS edition, and smoke tests that can be run in Jenkins, I'd be happy to do that with the commercial distributions of jOOQ.
lukaseder
commented
3 years ago ... would be a great thing to do anyway, to regression test jOOQ in a quarkus context on our side :)
angrymango
commented
3 years ago I've added support for jOOQ Pro by:
This means the commercial version will not be built automatically or deployed anywhere. This will need to be done manually by users:
Does this solution work for you @lukaseder and @maxandersen?
My preference would be to come up with a way to a build and deploy the pro version automatically, but this seems like a workable compromise for the moment.
lukaseder
commented
3 years ago It certainly works for me for now.
maxandersen
commented
3 years ago heya, sorry for not catching up sooner - let me answer:
But you said "open source" (legal distinction), not "available in maven central" (technical distinction). So, perhaps, this isn't really the first time this happens. With the commercial drivers included in "open available builds", the question about who is really accepting the license at what point remains, I guess?
yes - by being available in maven central there is a common well recognized way of builds allowed to use it; but of course still an issue around distributions. But if use for testing only then that is much less of an concern.
This means the commercial version will not be built automatically or deployed anywhere. This will need to be done manually by users:
- adding their private repository details to a profile in settings.xml
- using the profile to build and deploy the extension to their private repository
Yes, I think your approach is good @angrymango. Now @lukaseder or anyone else for that matter can setup a build verifying these bits in a CI environment that is able to honour the license without risk. i.e. we could setup firing a webhook to trigger a jenkins build somewhere that if it fails could report back opening an issue if some challenge.
My preference would be to come up with a way to a build and deploy the pro version automatically, but this seems like a workable compromise for the moment.
100% agree - if anyone can come up with a way for us to run the builds in github CI without too many loops to jump through and maintain lets do it. all ears.
Supporting the licensed pro versions of jOOQ requires jars that are only available behind a paywall. If this extension is going to support the pro version they would need to be available at build time. This means either: