Why is slf4j a banned dependency?

[Mario Giammarco]

Thanks,

Mario

[Edwin Stang]

Hi Mario,

I guess you mean the "org.slf4j:slf4j-log4j12" dependency? This is because SLF4J is used with the LogBack backend. The Log4J API is already redirected to LogBack via "org.slf4j:log4j-over-slf4j". So these two would conflict. Otherwise SLF4J is not a banned dependency. If another library brings in the direct Log4J binding "org.slf4j:slf4j-log4j12", you should exclude that dependency. Or if you want to actually use Log4J instead of LogBack, you could do that via some maven overrides. This requires some specific steps and I can tell you how to do that if desired. Essentially overriding the "maven-enforcer-plugin" rule or using a bill-of-materials-import instead of a maven-parent declaration. Additionally defining excludes for LogBack and if you use the invesdwin-context platform, you might have to tell the platform-initializer to skip the LogBack setup (I would make sure that this works if desired).
 
Best regards,
Edwin

Am Mittwoch, 27. Dezember 2017 20:22:32 UTC+1 schrieb Mario Giammarco:

Thanks,

Mario

[Mario Giammarco]

I add this, now I need to use querydsl-apt and it imports jta... that is banned? Can I unban it?

[Edwin Stang]

There are a few options for that:

a) Regarding "not using invesdwin as a maven-parent" you can find example on different integration scenarios here: https://github.com/subes/invesdwin-context/tree/master/tests
The documentation for this is here: https://github.com/subes/invesdwin-context#parent-pom

b) Alternatively you can turn the banned dependency failures into mere warnings like this:
            <plugin>
                <artifactId>maven-enforcer-plugin</artifactId>
                <configuration>
                    <fail>false</fail>
                </configuration>
            </plugin>
Here is the full excample: https://github.com/subes/invesdwin-context-persistence/blob/master/invesdwin-context-persistence-parent/invesdwin-context-persistence-jpa-kundera-rdbms/pom.xml

c) Another alternative is to override the maven configuration via the attribute " combine.self='override' ". An example is here where the spring-boot transformers declaration gets overridden from the maven-share-plugin (you can do the same with any type of plugin configuration): https://github.com/subes/invesdwin-nowicket/blob/master/invesdwin-nowicket-parent/invesdwin-nowicket-examples/invesdwin-nowicket-examples-mvp-bsgcoach/pom.xml

d) Though JTA is in some ways banned because there are multiple different providers for this API and having multiple ones in the classpath will give runtime exceptions if they are incompatible (ClassCastException, ClassNotFoundException, AbstactMethodException, ...). Those problems are hard to track and fix, so we normally ban all conflicting providers in favor of one specific provider that we favor. In this case we banned these two for our platform:
<exclude>javax.transaction:jta</exclude>
<exclude>org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec</exclude>
And allow the following as the favored one (which is defined as a dependency of invesdwin-context):
<dependency>
            <groupId>org.jboss.spec.javax.transaction</groupId>
            <artifactId>jboss-transaction-api_1.1_spec</artifactId>
 </dependency>

Though in the case of querydsl-apt I think i remember it to be only an optional dependency. So it could be possible it would work without any JTA on the classpath. But I have not tried it for some time and might not remember it correctly.

Best regards,
Edwin

[Edwin Stang]

Hi Mario,

I have adjusted the invesdwin-nowicket-examples-war project to not use any parent pom and instead do the bom-import. I guess this is the more appropriate way for an example:
https://github.com/subes/invesdwin-nowicket/blob/master/invesdwin-nowicket-parent/invesdwin-nowicket-examples/invesdwin-nowicket-examples-war/pom.xml

Best regards,
Edwin