Hello, > Are you _sure_ that's the case? I would say Yes. The circular dependency originates from pom files, but the problem is that I cannot find a portage equivalent of some maven features (that is "exclusion" exactly). > These projects are using Maven to build, test and upload artifacts > to Maven central, how can it not compile? This is weird. I encountered net.sf.kxml:kxml2:2.3.0, which does not declare any dependencies. But it turns out to depend on xmlpull:xmlpull, I need to manually add it and make net.sf.kxml:kxml2:2.3.0 able to compile. > Did you check out a stable commit? I am sorry that I am not sure what the stable commit stands for. Does that mean Maven artifacts always have a stable commit? Could you please tell me where can I find it? > Did you set the proper Maven profile? I do not set a Maven profile, and I believe it should be the default one. > Are you invoking Maven the same way upstream is? No, I am trying to translate pom into ebuild, which is an important part of my GSoC. > Please elaborate. Here is a set of pom files leading to circular deps: org.codehaus.groovy:groovy-all:2.5.12 depends on org.codehaus.groovy:groovy:2.5.12, while org.codehaus.groovy:groovy:2.5.12 depends on org.codehaus.gpars:gpars:1.2.1, while org.codehaus.gpars:gpars:1.2.1 depends on org.codehaus.groovy:groovy-all:2.5.12. But in pom of groovy, it excludes groovy-all with the "exclusion" attribute. It means that the gpars that groovy depends on is not depending on groovy-all now. So the circular dep gets broken in Maven. The problem is that portage cannot deal with things like "exclusion", so we cannot avoid the circumstance of circular deps. Do you have any suggestions? And Thank you in advance. Regards, Zhang Zongyu [1] an Overlay of ebuild files from Maven artifacts, if you are interested in https://github.com/6-6-6/spark-overlay [2] java-ebuilder which translates pom files into ebuild files. https://github.com/6-6-6/java-ebuilder