Some IDE environments do not support maven-compiler-plugin include/exclude
filter configurations well and this profile is meant to bridge that gap by
enabling all sources and dependencies for IDE compiles.
* No need to toggle the oracle profile, enabled by default
* No need to specify the logminer profile, this is used by default
* Converted several release pipeline usages from oracle to oracle-xstream
This is needed so that the release contains both LogMiner & Xstream bits.
* Removed oracle-ci profile entirely, no longer required
The default build with no profiles explicitly uses the previous oracle-ci behavior.
* Removed the use of the oracle profile, the Oracle connector enabled by default
* Removed the xstream-dependency usage, Xstream dependencies aren't enabled by default.
* Oracle will always be built with LogMiner by default
* Oracle tests are always compiled, integration tests skipped by default
* Integration tests require oracle-tests profile to be executed
* Xstream requires oracle-xstream profile
* Instant client dependencies are excluded by default
* The assembly profile enables Xstream bits automatically
Currently we update first `lsn` and then update `lastCommitLsn` in
`PostgresOffsetContext` constructor. However, when `lastCommitLsn`
is for whatever reason `null`, previously updated `lsn` is reset to
`null` as `updateLastCommit()` updates also `lsn`. This can have
unwanted consequences like streaming again records which were already
streamed. To prevent this, update `lsn` in `updateLastCommit()` only
when `lastCommitLsn` is not `null`.
This internal option is meant to replace the old `log.mining.query.logs.for.snapshot.offset`.
This now enum-based setting provides much more flexibility by being able to completely
disable the in-progress transaction check (now the default), only grab transactions that are
in-progress from V$TRANSACTION, or finally be able to grab all in-progress transactions that
are both from V$TRANSACTION and by scanning the logs.
When a table is renamed with the ALTER TABLE statement, the schema
history record not only will reference the current table's unique id
in the "id" metadata, but will also refer to the old table name in
the "previousId" metadata field.