Bug 205245 – dev-java/commons-dbcp-1.2.2 and www-servers/tomcat-6.0.14-r1 circular dependency with FEATURES="test"

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Vlastimil Babka (Caster) (RETIRED) 2008-01-10 20:37:07 UTC]

Originally reported in bug 203750:
------- Comment  #8 From Brent Baude  2008-01-10 03:31:15 0000  [reply] -------

I hit a circular dep with FEATURES="test" on my packages.  Check this out:

baudequad ~ # FEATURES="test" emerge -pv `cat java.pkgs `

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] www-servers/tomcat-6.0.14-r1  USE="test -doc -examples -source" 
[ebuild  N    ]  dev-java/commons-dbcp-1.2.2  USE="test -doc -source" 
!!! Error: circular dependencies:

('ebuild', '/', 'dev-java/commons-dbcp-1.2.2', 'merge') depends on
   ('ebuild', '/', 'www-servers/tomcat-6.0.14-r1', 'merge') (hard)
('ebuild', '/', 'www-servers/tomcat-6.0.14-r1', 'merge') depends on
   ('ebuild', '/', 'dev-java/commons-dbcp-1.2.2', 'merge') (hard)

!!! Note that circular dependencies can often be avoided by temporarily
!!! disabling USE flags that trigger optional dependencies.
baudequad ~ # 

This is for ppc64.

Can the java herd peek at this?
--

Looked at it briefly, the tests in commons-dbcp really at some point want org.apache.naming (which is in tomcat's catalina.jar) instead of javax.naming, which looks suspicious and I'm not sure it's really needed.

[Comment 1 William L. Thomson Jr. (RETIRED) 2008-01-10 21:39:36 UTC]

I question it as well, and I use commons-dbcp in Tomcat :) So does tomcat, they renamed that sucker to tomcat-dbcp.jar/naming-factory-dbcp.jar. Been a problem for me for a while in bug 205245.

Looking at upstream home page, it says
"Applications can use the commons-dbcp component directly or through the existing interface of their container / supporting framework."

So I guess the tests are testing the container interface or etc? I figured it could be used directly and not require a container.

Guess absolute worse case I could see about packaging catalina.jar on it's own. But would hope to avoid that.

[Comment 2 Abraham Marín Pérez 2008-02-18 09:22:17 UTC]

Hi all,

I had a problem which seems to be related with this topic. I keep tomcat-6.x masked since we (the company I work for) are forced to stick on tomcat-5.5.x; plus, I have test feature enabled in Portage, which altogether makes commons-dbcp won't have all its dependencies satisfied (test flag -> tomcat:6). My workaround has been disabling test on commons-dbcp, but I wonder if there's any way to make commons-dbcp tests work with tomcat-5.5 or to make Portage workarounds this issue by itself.

[Comment 3 Abraham Marín Pérez 2008-02-18 10:16:13 UTC]

In fact, I think a new bug should be reported, since test FEATURE can be disabled for a particular call of emerge, but not permanently for a particular package (there's no package.feature). I'll open a bug and associate it with this one.

[Comment 4 Vlastimil Babka (Caster) (RETIRED) 2008-02-18 18:28:01 UTC]

Hm, common sense tells me that the test that needs tomcat6 is testing only functionality when commons-dbcp is used in tomcat6, which is not always the case. So, it could simply drop the dependency, use has_version check and if tomcat6 is not there, patch the test out and spit an ewarn.

[Comment 5 Ralph Sennhauser (RETIRED) 2012-05-30 11:17:27 UTC]

commons-dbcp-1.4-r2, for which a stable request was filed, no longer depends on tomcat for it's tests. Closing here.