Design approach for static data requirement in a library -

i supposed design re-usable component. java library api interface, hiding implementation details including internal data dependency. requires set of static data client application needs configure in library before calling methods

after lot of debate , discussions have come 2 design approaches

1. first design approach: static data internal library so, implementation quarrying , data tables should implemented internally transparent client application of library

   in approach we'd following:
   
   a1. library internally depends on abstract static data interface , there various data source implementations: ex: database-query implementation, file query implementation, config query implementation
   a2. client application configures implementation source of static data
   

   debates against approach:
   
   d1. library should not make database connection
   d3. client bound data schema can not change queries. can point libray data source
   
   

2. in second design approach: static data viewed dependency (even though internal library). should injected, i.e. client application of library needs implement static data

   we'd following:
   
   a. library implements service provider interface (spi)
   b. client applications need implement interface
   c. tables client application
   

   debates against approach
   
   d1. static data internal library, user of library should not worry implementation
   d2. data different clients same, there redundant code
   d3. more redundant code = more errors
   

i not sure approach follow. if can recall elegant approach experience helpful me.

many in advance!

i'd suggest going option 2 keep library modular own maintenance purposes. solve issue of having client implement data connection logic themselves, ship library configuration files (such mapper xml using mybatis db connection) user can edit if choose update it.

you provide other configuration options using other data connections don't have easy editing xml file.

you make going default easiest option , require user put in more work farther away default requirements go, while avoiding coding corner.