[MAGNOLIA-1461] Remove commons-logging Created: 12/Apr/07  Updated: 06/Jan/15  Resolved: 11/Oct/07

Status: Closed
Project: Magnolia
Component/s: build
Affects Version/s: None
Fix Version/s: 3.5 RC1

Type: Task Priority: Major
Reporter: Magnolia International Assignee: Fabrizio Giustina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MAGNOLIA-1478 Update velocity dep to 1.5, remove de... Closed
is related to MAGNOLIA-1422 update slf4j to 1.3.1 and change depe... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:

 Description   

As far as I can tell, none of the magnolia code is using commons-logging anymore. We should be able to remove it from our main build. (it will probably still come up through transitive dependencies, so we need to check if the versions are compatible)



 Comments   
Comment by Magnolia International [ 12/Apr/07 ]

hmm, just tested: we used 1.1, and through trans.deps, we get 1.0.3.
Need to investigate what dep brings this, and see if there's any impact.

Comment by Fabrizio Giustina [ 18/Apr/07 ]

we should exclude any transitive deps from commons-logging and included the slf4j commons logging wrapper, that would bring the benefits of slf4j (static binding) and avoid mess in commons-logging versions... unfortunately this will bring in a ton of exclusions in our poms

Comment by Magnolia International [ 18/Apr/07 ]

as far as i could see, the deps that used to be excluded from commons-logging by our pom are not brought over when simply and completely eradicating c-l from our poms, so I'm not sure I understand the need to keep c-l? Except if we know of a lib we use that explicitely rely on it ?

Comment by Fabrizio Giustina [ 18/Apr/07 ]

> Except if we know of a lib we use that explicitely rely on it ?
yes, many libs we depends on explicitely needs commons-logging

Comment by Magnolia International [ 19/Apr/07 ]

I'll check the dependencies report to see which ones (just curious)

Comment by Ceki Gulcu [ 21/Apr/07 ]

Are you aware of the jcl104-over-slf4j module that ships with SLF4J?

Comment by Ceki Gulcu [ 21/Apr/07 ]

Sorry, reading Fabrizio's comments from April 18th, you are obviously aware of jcl104-over-slf4j.

And, yes, you would need to explicitly exlude dependencies on commons-logging for each of Magnolia's dependencies which transitively import JCL.

Excluding JCL this way is not exactly exciting. I had to go through it recently in one of my own projects. I was nearly bored out of my skull. Anyway, it can definitely be done but will extoll few minutes from your schedule preventing you from doing interesting work.

Comment by Fabrizio Giustina [ 22/Apr/07 ]

done, I checked all the transitive deps and also added the needed exclusions while checking

for the record, this is the list of libraries we need that require commons-logging:

  • commons-httpclient
  • commons-betwixt
  • commons-discovery
  • commons-chain
  • ehcache

replacing commons-logging with the sl4j bridge using exclusion was really no fun :/ I had to add a lot of exclusions before being able to see a final war without that evil jar...

Comment by Magnolia International [ 23/Apr/07 ]

nice, thanks.
maybe we could do the same for logkit ?

Comment by Magnolia International [ 23/Apr/07 ]

See MAGNOLIA-1461 for logkit (was only used by velocity)

Comment by Magnolia International [ 23/Apr/07 ]

Fabrizio, it seems to me that adding the exclusions in the <dependencyManagement> is enough, isnt that the case?

Comment by Fabrizio Giustina [ 23/Apr/07 ]

> Fabrizio, it seems to me that adding the exclusions in the <dependencyManagement> is enough, isnt that the case?

unfortunately that is usually not enough in a multiproject build :/
for example if you exclude commons-logging from commons-betwixt in dependencyManagement the result is that the dependency gets removed from magnolia-core. However this exclusion only applies to magnolia-core and it's not transitive: only exclusions declared directly in the pom seems to be transitive.
Because of that and since the "magnolia" module (the main webapp) depends on magnolia-core, the exclusion is not carried over and commons logging still pops up in the final war.

I didn't tested this properly after the upgrade to maven 2.0.6, but I guess that the changes in dependency management didn't affect this behaviour. At least I am sure that dependencies still show up in the maven generated dependency report but maybe a second check to WEB-INF/lib could confirm this...

Comment by Fabrizio Giustina [ 11/Oct/07 ]

this has already been fixed in svn

Generated at Mon Feb 12 03:27:08 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.