0

I am about to deploy a library "A" in Maven Central that I currently release in two configurations that are interchangeable but incompatible. One configuration is full featured, the other is more likely to be accepted in an "app store". The choice between the two would best be made by an application developer. An application developer would be very unlikely to use "A" directly, however.

Alternatives that I am aware of are: (1) making the two configurations distinct artifacts "A1" and "A2" and (2) deploying as a single artifact "A" and using classifiers to distinguish the two configurations.

The question gets more interesting when I consider the next step, which is deploying a library "B" that depends upon library "A". Library "B" is compatible with either configuration of library "A", so what should it depend on?

A situation I want to avoid is deploying two versions of "B", "B using A1" and "B using A2", as that is just the start of a combinatorial explosion.

Alan Snyder
  • 408
  • 2
  • 13
  • Presumably this issue would affect any library that depends upon guava, which uses two configurations distinguished by classifier, but I have not found any examples. – Alan Snyder Sep 15 '20 at 17:11
  • Guava variants aren't (or at least no longer, as that might have been the case) distinguished by classifier, but by version: 29.0-android vs 29.0-jre. – Thomas Broyer Sep 21 '20 at 21:39
  • Thank you for clarifying that point. I was confused by the Maven POM documentation that says the classifier is text immediately following the version number in the artifact "name". – Alan Snyder Sep 21 '20 at 23:07

1 Answers1

0

Library "B" is compatible with either configuration of library "A"

Sounds like both versions of library A share a stable API. I'd follow a pattern similar to what SLF4J uses: publish an API artifact, and your two configurations separately, which then depend on and implement the API.

so what should it [library B] depend on?

Defer the choice. Depend on your A API artifact and let the consumer of B choose which A implementation to load.

You can take this as far as feels practical. SLF4J throws runtime warnings when it can't find any implementations, or if it finds too many. You could also just document the responsibility of library users to choose and provide an A implementation in your guide to using B.

Greg Chabala
  • 1,125
  • 2
  • 23
  • 35
  • Since version 1.6, SLF4J does not throw an exception when it can't find an implementation; instead, its operations do nothing. (I don't know what happens if there are too many implementations on the classpath.) This makes SLF4J an ideal use case for a separate API artifact. This solution may be less attractive for libraries that serve an essential function in an application, as an incorrect configuration will not be discovered until runtime when the application attempts to execute library code. – Alan Snyder Sep 22 '20 at 19:38
  • Well, that's the point, right? It's your library, you can make it fail hard when it initializes if no implementation is found. That ought to be discovered during development by clients of your library, unless they're going to rush into production without ever testing. – Greg Chabala Sep 22 '20 at 20:44