New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reorganize JARs #80

Closed
cruftex opened this Issue Feb 19, 2018 · 5 comments

Comments

Projects
None yet
2 participants
@cruftex
Member

cruftex commented Feb 19, 2018

In the context of the Spring integration @snicoll raised some concerns about the many different modules that are bundled together into cache2k-all. See: https://jira.spring.io/browse/SPR-16501

The idea is now:

An alternative approach to cater the Android world would be to deliver a jar with all features, but provide Proguard rules that strip unused "server-stuff" away. I will take a look into this.

Still, I would like to keep the API in a separate jar. Right now the API is also included in the cache2k-all jar, which means only one jar is needed at runtime. To remove the duplication in this case, two jars will be needed in the future, let's say cache2k-api and cache-impl.

Thoughts from Android developers?

@cruftex cruftex self-assigned this Feb 19, 2018

@cruftex cruftex added this to the v1.2 milestone Feb 19, 2018

@cruftex cruftex added the enhancement label Feb 19, 2018

@snicoll

This comment has been minimized.

snicoll commented Apr 9, 2018

@cruftex from a non-Android perspective, what is the rationale from separating the API from the rest? I am not aware of any other cache library taking down that route, which is why I am asking.

Thanks!

@cruftex

This comment has been minimized.

Member

cruftex commented Apr 9, 2018

@snicoll

Yes, separating the API does no other caching library. Its tedious and some effort, but I would consider it as good practice for every other library as well.

I see the following advantages:

  • using the API only jar as compile time dependency makes sure that no dependency exists to implementation code that might change between revisions
  • within the API jar/artifact there are strong checks for completeness of documentation and changes
  • the API jar can be checked for compatibility between versions (e.g. clirr)
  • there is the (somewhat theoretical) chance that other caching vendors implement the cache2k API. Although it is "theoretical" I would encourage this and would like to see discussion and contribution just on the API level.
  • the cache2k API was finalized after JSR107 was finalized and is avoiding all inconsistencies and defects found in JSR107. Also the cache2k API is a super set of the JSR107 functionality, so it is actually an alternative to JCache
  • of course everything could be delivered in one jar and the API can be separated by package naming, e.g. with the implementation in the impl Package or the API in the api package. However, what would the Javadoc for this jar contain? How to ensure that somebody does not use and internal implementation interface?
  • at some point there might be a 2.0 API. An application can choose which API to use (or both) with the dependency
  • experimental or upcoming features can be delivered in the impl jar only
  • maybe in the future the API will not be released as often as the implementation. Thats another way to signal that a service release is semantically 100% compatible to the API.

The separate packages help me a lot during development for decision making and keeping things clean and focused. Is this something that needs to last or is this something that I may change any time?

Still it is some effort and not seen by much other libs. So what would be the Cons? Comments?

At the moment I started the reorganization and will release a alpha version with the new jars.

@cruftex

This comment has been minimized.

Member

cruftex commented Jul 3, 2018

Yesterday I released the version 1.1.1.Alpha which reflects the jar restructuring. Any feedback is welcome.

@cruftex cruftex closed this Jul 3, 2018

@cruftex

This comment has been minimized.

Member

cruftex commented Jul 21, 2018

Reopening. Decided to stay with cache2k-core for the core functionality. So we rename the cache2k-impl released in Alpha to cache2k-core again.

Also I found that some users actually use explicitly cache2k-core which does not contain the JMX and configuration support. For 1.2 JMX and configuration will be included in core. This leads to the question: Should JMX be enabled or disabled by default? At the moment it is enabled by default. There is a slightly chance to get into naming conflicts when JMX beans are registered, in case multiple classloaders use a separate cache manager of the same name. Maybe this needs some further considerations.

@cruftex

This comment has been minimized.

Member

cruftex commented Aug 2, 2018

With release 1.1.3.Alpha the following was changed:

  • Main implementation is in cache2k-core, this works if just cache2k-core is added as dependency
  • JMX support is off by default and needs to be explicitly enabled
  • a transition jar for cache2k-all is provided
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment