Details
-
Type:
Task
-
Status: Closed (View Workflow)
-
Priority:
Minor
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:None
-
Story Points:1
-
Epic Link:
-
Sprint:Spring 1 : 25 Dec to 17 Jan, Spring 2 : 20 Jan to 31 Jan, Spring 3 : 3 Feb to 14 Feb, Spring 3 : 17 Feb to 28 Feb
Description
Note: This would be a good job for someone who understands maven quite well - or who wants to learn.
The goal of the task is to make the IGB POM simpler and more understandable. It looks like the POM property log4JVersion is not be used anywhere and can be deleted, which will simplify the POM. This task is to investigate that and delete if if possible.
Background:
The IGB project uses SLF4J as its logging system. SLF4J - Simple Logging Facade for Java - is basically just an API "facade" for various logging systems you can include in a Java project. In all of IGB's bundles, we include the facade API as a dependency. When we build IGB itself, we also include an implementation of the logging framework. None of the bundles needs to know anything about which framework implementation is being used. Only the master build logic that creates the final platform jar should specify the particular logging implementation.
Note that this is complicated by the fact that some of the 3rd-party jars we include might declare dependencies on specific logging framework implementations, which would be bad. I have not checked if this is happening.
For some reason, the parent IGB POM creates a property called log4JVersion, but it is not used anywhere in the parent POM. For this task, use grep or whatever tools you like to find out if any of the child modules in "core" or "plugins" or wherever are using this property. If they are, investigate why. If they are using any older, non-SLF4J logging system, change this so that they are using SLF4J.
Note that the story point estimate assumes you will not have to change any code – just delete and un-used property. If this is not the case, please update the story points to show the greater effort.
Attachments
Activity
The only place that log4jVersion used is shared lib wrapper apart from the main pom.
I have commented out the code for now since it is unused.
code change - https://bitbucket.org/noorzahara/integrated-genome-browser-local1/branch/IGBF-2214#diff
For next steps, investigate:
- Which (if any) bundles or bundle dependencies are using groupId org.apache.logging.log4j artifactId log4j-api.
Suggestions:
- run IGB and view the loaded bundles using the Felix Web console. See IGB project README.md for details on how to do that. Check to see if any bundles fail to resolve because they lacking log4j-api.
- use mvn's dependency plugin ("analyze" goal) to determine if log4j-api is an unused dependency or not. Try to find out which included libraries or bundles in our project depend on it.
- use git blame ("annotate" in the Bitbucket UI) to track down who added the log4j-api depending in core/shared-lib-wrapper/pom.xml and why.
Note: I am increasing story points to 0.5
Shamika Gajanan Kulkarni could you pick this up next week when you come back?
Yes sure. Thank you.
SLF4J gives generic access to many logging frameworks, log4j and logback being some of them. In IGB we are using logback framework.
SLF4J makes it easier to change the logging framework. The logging framework is chosen based on the binding jars provided.
logback-classic is a native implementation of SLF4J.
To use logback-classic we need to declare its dependency in pom.xml [which we have already] (the versions mentioned may differ)
" If you wish to use logback-classic as the underlying logging framework, all you need to do is to declare "ch.qos.logback:logback-classic" as a dependency in your pom.xml file as shown below. In addition to logback-classic-1.2.3.jar, this will pull slf4j-api-1.7.28.jar as well as logback-core-1.2.3.jar into your project. Note that explicitly declaring a dependency on logback-core-1.2.3 or slf4j-api-1.7.28.jar is not wrong and may be necessary to impose the correct version of said artifacts by virtue of Maven's "nearest definition" dependency mediation rule."
-http://www.slf4j.org/manual.html
https://howtodoinjava.com/log4j/slf4j-vs-log4j-which-one-is-better/
https://www.tutorialspoint.com/slf4j/slf4j_vs_log4j.htm
The dependency for logback has also been declared in shared-lib-wrapper pom and igb-project pom.
So, I think it should be safe for us to delete the log4jVersion in pom.xml and shared-lib-wrapper pom too.
Kindly review Prof [~aloraine]
Ok - let us remove it!
Please proceed with PR.
cc: Shamika Gajanan Kulkarni
Hi Noor,
Since you have a little time left today, can you pick up this task?
If you need help with maven, let me know. I am upstairs currently and don't mind taking a break from writing my proposal to get you started on this if you need it.
-Dr. Loraine