Add separate concern provider dependency.


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.




Magno Nascimento
December 23, 2016, 6:03 PM

Oooh.. ok, I thought I'd have to do something else based on what you said.

Garret Wilson
December 23, 2016, 5:59 PM

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.

Magno Nascimento
December 23, 2016, 2:22 AM

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?

Garret Wilson
December 20, 2016, 10:11 PM

, I've updated the description to reflect the new approach.

  1. First finish reviewing the pull requests for RINCL-16.

  2. Reset the erroneous commits in the clogr repository and decline that pull request (if you haven't already).

  3. Also reset the commits you've done so far in the clogr-logback repository and decline that pull request (if you haven't already).

  4. 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.

Magno Nascimento
November 27, 2016, 11:36 PM

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?



Magno Nascimento


Garret Wilson




Fix versions