There is a crucial file io.csar.ConcernProvider which Csar uses to know which concern it should register. Clogr provides an implementation for Logback, but eventually we want to provide implementations for other logging services, too. If we create an implementation, it won't automatically be recognized by Csar unless we have the io.csar.ConcernProvider file in the build.
In Rincl I found it necessary to have other projects use rincl-resourcebundle (the resource bundle implementation) without actually haven't it registered by Csar.
At first in I modified the rincl-resourcebundle POM so that it didn't include the io.csar.ConcernProvider file. Then I made a separate POM in the same repository that would build a JAR containing just the io.csar.ConcernProvider file, and have a dependency on the original JAR. At first I tried to maintain two POMs in a single repository, but as discovered in this can be problematic, not to mention the extra trouble of remembering an extra build step. So I reopened and split the io.csar.ConcernProvider file and its corresponding implementation into a separate repository.
Now people people use the implementation rincl-resourcebundle in other libraries, but include rincl-resourcebundle-provider only if they wanted Csar to automatically register Rincl's resource bundle implementation.
For consistency I want to do the same thing for Clogr's Logback implementation (and for future implementations). This should end up like after rincl-resourcebundle pull request 2 and rincl-resoourcebundle-provider pull request 1 are complete.
You'll want to move io.csar.ConcernProvider (and the actual Java implementation it refers to inside) over to the new repository clogr-logback-provider. Put the provider implementation into a provider subpackage. Copy over the POM and update the coordinates, the description, the repository URLs, and whatever else you need to. Don't forget to update the readme too.
You'll want to update the POM versions to 0.8.0-SNAPSHOT.
I want your opinion on something. I see that you've ran into a little problem in the branch for this issue, and it wasn't something I had considered.
Normally we have a separate repository for each POM. But basically for this "provider" we only have a single Java file and a small text file, just to register the provider with Csar automatically. So I felt that it was overkill to create a separate Git repository just for this, and created a separate POM just for including or not including the text file that makes Csar recognize the provider.
But now I'm having second thoughts, because having a separate POM has several drawbacks:
It requires the developer to remember to manually do a separate Maven build with the separate POM to create and publish the provider JAR.
In fact the actual provider will be included in the non-provider JAR — the "provider" JAR will only contain the Csar definition text file identifying the provider. So the real "provider" class is not in the "provider" JAR, but in the implementation JAR.
Creating a program that uses the provider in Eclipse will be weird if it's a SNAPSHOT version, because it won't be available in Eclipse unless you remember to go do a mvn install for the provider JAR.
And last of all, as you're finding out, how do we create unit tests that make sure the provider is working? We can't put them in the implementation project, because it no longer has the automatic provider inclusion. And we can't put the unit tests in the other JAR, unless we do even more gymnastics in the POM to leave out the unit tests in the implementation JAR and put them in the provider JAR.
So I'm about to determine that I was wrong in trying to "cut corners" as we say, and it would be better just to create a separate clogr-logback-provider repository that contains the provider class and the provider text file. Then everything would work as expected, we wouldn't forget to build the separate JAR, and everything would work in Eclipse as normal. We'd just have yet another Git repository for every provider we have.
What do you think?
As a framework, it really might be better to have it in separate repositories.. I think we should make everything as easier as possible to the final user, because that's what frameworks are made for, right? But it shouldn't be any different in a SNAPSHOT than in a release build.. What if a developer find any bug and try to fix it for you, then he should know about these two "branches", which is okay, if you decides that.. But then he would need to know how the project works with the provider and how it works without it, what could make things harder for them.
i.e. Unit tests case: A lot of errors appeared, because it was expected some class that wasn't present in the actual build, but they shouldn't really be.. It wasn't an error on the method, but on the build.. you could fix that with those gymnastics in the POM, but then you would have to create a brand new documentation telling the user what's from one build and what's from the other, what could make things confusing.
And because of that, why not create a new project with just one line more in the documentation saying "This projects includes Csar provider", or something like that?
, I've updated the description to reflect the new approach.
First finish reviewing the pull requests for RINCL-16.
Reset the erroneous commits in the clogr repository and decline that pull request (if you haven't already).
Also reset the commits you've done so far in the clogr-logback repository and decline that pull request (if you haven't already).
Start over (with a branch for CLOGR-3; it could be the same branch you reset or another one if you delete the old one) and implement with our new approach.
Don't forget that you'll make changes both in clogr-logback and in clogr-logback-provider (the new repository I made) to complete this task.
I don't understand, do I need to make changes on clogr? I thought it was all about clogr-logback, where do you say anything about clogr?
I thought it was all about clogr-logback, where do you say anything about clogr?
When you first worked on this I thought you inadvertently changed the clogr repository, didn't you? I was just reminding you to remove those commits.
Oooh.. ok, I thought I'd have to do something else based on what you said.