killbill / killbill-oss-parent Goto Github PK
View Code? Open in Web Editor NEWKill Bill parent pom.xml
Home Page: https://killbill.io
License: Apache License 2.0
Kill Bill parent pom.xml
Home Page: https://killbill.io
License: Apache License 2.0
3.2.1 isn't on Maven Central.
See also #21.
This is blocked by:
Some of these are pre-requisite for Java 11 support.
commons-compress
in platform flyway
in Kill Billjavax.servlet-api
to 4.xThis is a sub-task from this: #552
Since PostgreSQL update more important (needed to update jooq, also it's old already), we'll cofus with it as the first step:
killbill-commons
killbill-commons
to update testing-postgresql-server
with embedded-postgres
.killbill-commons
local SNAPSHOT
in killbill-platform
and killbill
killbill-platform
killbill-commons
available in sonatype, update killbill-platfrom
from testing-postgresql-server
to embedded-postgres
.killbill-platform
local SNAPSHOT
in killbill
, and test them.killbill-platfrom
local SNAPSHOT
in killbill-stripe/braintree-plugin
, update jooq
version, and test them.killbill-oss-parent
We have killbill-commons
and killbill-platform
with up-to-date embedded-postgres
migration, so:
killbill-oss-parent
with up-to-date killbill-commons
and killbill-platform
, build locally.killbill-oss-parent
local SNAPSHOT
in killbill-stripe/braintree-plugin
, update jooq
version, and test them.killbill-oss-parent
local SNAPSHOT
in killbill
, and run test, and manual test with plugins installed, if needed.killbill
with up-to-date killbill-oss-parent
killbill-embeddeddb-postgresql
in killbill-commons
test-jar
dependencySee
This might help for killbill/killbill#1878.
Code to upgrade:
The current version of the log4jdbc library does not implement the getSchema
/ setSchema
methods. This causes an issue with the analytics plugin. See killbill/killbill-analytics-plugin#152.
Once this library is updated, we would need to update its version in oss-parent
.
Also see arthurblake/log4jdbc#99
We define maven-clean-plugin here. But AFAIK, we not use it anywhere. My understanding is that, to "use" that plugin, we should define it in build/plugins/plugin
. So far, we just declare/define it in build/pluginManagement/plugins/plugin
. I checked any other project that may use it, but I can't found any. The only project that use it is api-pojos, but this project not using this parent pom.
Could we use one with a smaller footprint?
Related: #126
Dependencies:
cglib
should be banned in the base pom.xml)We've had to ignore some libraries updates over the years due to various upstream blockers, see
Once the various pending PRs from dependabot have been merged, let's do a 2022 pass, to see if some of these ignore entries can be removed.
The snakeyaml
dependency needs to be updated to 2.0
. The current version (1.33
) has some vulnerabilities which is causing an issue for some customers.
I am currently having trouble building the Stripe plugin with IntelliJ IDEA 2021.1. As there is a .idea folder in your repositories, it looks like you are also using IntelliJ IDEA.
I have recently upgraded to IntelliJ 2021.1 and now building a project inside the IDE does not work anymore. It seems like Jetbrains changed something internally which now triggers a bug in an older version of manifold that is used in killbill-oss-parent.
Some more information can be found here: https://youtrack.jetbrains.com/issue/IDEA-266798. I don't know if Jetbrains will change anything on their side.
Upgrading manifold from 2020.1.45 to 2021.1.11 resolved the issue for me. But I only tested it to compile the Stripe plugin. I don't know if upgrading manifold will lead to problems in any of your other projects.
It would be great if you could consider upgrading manifold next time you are upgrading your dependencies.
Because of https://issues.apache.org/jira/browse/SHIRO-679 (duplicate classes across artifacts), we cannot upgrade until 2.0.0 is released (apache/shiro#236).
Once we've upgraded, do we still need the forked classes in Kill Bill?
Also need to remove this config:
Line 2241 in f5d0681
Related:
The dry-run feature is a Pro feature for Flyway:
Because of this, we've implemented our own dry-run on top of Flyway 4.0. Work is needed to port the code to the latest version.
Note: it looks like some folks are relying on this outside of Kill Bill (https://stackoverflow.com/a/38086304).
There are some deprecated configuration in github CI. Take a look here: https://github.com/killbill/killbill-oss-parent/actions/runs/3666893119 .
Link above refers to github action, and sometimes it disappear after a while, so here are more info from blogs, and screenshot:
Currently, each Kill Bill repository has an automatic way of releasing itself (release.yml
github workflow). What's time consuming is the ordering of releases that is necessary.
We're not expecting that we automate all of release process (what if there are failures in the middle or infinite loops...), but at least, for example: each time killbill-platform
released, it automatically triggers a release of killbill-oss-parent
with the new version of killbill-platform
.
Some idea (from Pierre):
There is an event that can be triggered across repos: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#repository_dispatch So one release could trigger (in theory) the next.
We also need to update via script the version of repo X in the killbill-oss-parent workflow (ideally the new version is sent in the repository_dispatch event and passed here:
).
.... maybe there is another way of doing it... Like doing all releases from a "central" repo, just like the ci job is doing here: https://github.com/killbill/killbill-oss-parent/blob/125da2cf399802378cf1349bbd3afc9c24503927/.github/workflows/ci.yml
When working on this, we may need run github action locally.
Currently, we're using embedded database server for MySQL and postgreSQL. Unfortunately, those library in "public archive" state, so it is unlikely that we can even send a PR: There's case that we need to update postgreSQL version to test make sure we able to upgrade JOOQ library. Current testing-postgresql-server version doesn't support fetch ... row only
statement, where JOOQ 3.15.x
will use that statement.
So this leave us with:
testcontainer
. Problem is experience tell me that this is slow compared to use local/installed/embedded.killbill-commons
.Current plan: Lets use testcontainer
in smaller project like stripe/braintree plugins. If itβs too slow/painful, maybe we just fork them.
We had this updated plan, but a comment section is not a quite right place to put a (bigger) plan, so I decided with 2 sub-tasks:
TODO:
org.osgi.*
componentsAs part of this, remove the hacks in place:
This is causing several plugins keep using jooq 3.13.x:
This is because in 3.14.0+
, returning()
in MariaDB will use insert .... returning
statement. Solution would be:
returning()
Jooby 2.x is a significant rewrite. The major breaking change is that there is no more Servlet support, which is a blocker for us.
Here are my notes from a quick investigation.
org.jooby.Result
and org.jooby.Results
are gone, the new io.jooby.Context
should be used instead.@Singleton
@Path("/something")
public class SomethingResource {
@GET
public Result getSomething(final Optional<String> maybeSomething) {
return Results.ok(...);
}
}
becomes
@Singleton
@Path("/something")
public class SomethingResource {
@GET
public void getSomething(final Optional<String> maybeSomething, final Context context) {
context.setResponseCode(StatusCode.OK);
}
}
Jooby#use(config)
has been removed: instead, we need to create a new environment (https://jooby.io/#configuration-custom-environment). Maybe something like that (untested): public PluginApp build() {
final PluginApp app = new PluginApp(jackson, services, routeClasses);
final Environment origEnv = app.getEnvironment();
final Environment newEnv = new Environment(origEnv.getClassLoader(),
this.config.withFallback(origEnv.getConfig()),
origEnv.getActiveNames());
app.setEnvironment(newEnv);
return app;
}
org.jooby.Sse
has become io.jooby.ServerSentEmitter
org.jooby.mvc.Local
has become io.jooby.annotations.ContextParam
As part of the upgrade, we should add a few tests (https://jooby.io/#testing) in our base framework, to help with such upgrades in the future.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.