Should `quarkus-beret` be "aware" of `jberet-support` as well?

[x80486]

I'm not sure what's the status of jberet-support, but it does contain quite some useful components, so I guess it's useful to include it as part of this artifact's BOM as well.

[radcortez]

The issue with jberet-support is that includes multiple components in a single dependency (Kafka, Cassandra, Mongo, POI, and others). This would require pulling the equivalent Quarkus Extensions, even if you are only interested in using one of these components (possible, but annoying). Also, there are some components we don't have Quarkus Extension (POI).

I'm not sure how we can properly provide support for this.

[gquintana]

@radcortez quarkus-jberet supports JdbcRepository and InMemoryRepository from jberet-core but the MongoRepository and InfiniSpanRepository are not supported. quarkus-jberet could support standard Java Item Reader/Writer from jberet-support (mostly CSV/JSON/XML files and JDBC), those which doesn't required specific dependencies in terms of libraries or CDI beans/config. That said I agree that having jberet-mongo-support, jberet-jpa-support, jberet-poi-support modules, containing item reader/writer, and job repository when possible, would be a better cutting.

[radcortez]

The issue remains. Because JBeret Support provides everything in a single artifact, you always get visibility for everything (including the ones we don't support), which is not a great developer experience.

We could fail the build if such classes are used. Another alternative is to provide our readers / writers for each extension.