Missing dependencies: "org.benf:cfr:0.132.0" and "org.eclipse.platform:org.eclipse.equinox.app"

[RichardBradley]

The published version 7.1.0 of spoon-core depends on a library that is not in the public maven repositories: org.benf:cfr:0.132.0

You can see this at e.g. https://mvnrepository.com/artifact/fr.inria.gforge.spoon/spoon-core/7.1.0 which lists it as a dep but does not have a hyperlink to a published version of this artefact.

When I try to compile a project against 7.1.0 spoon-core, I get the following error (using SBT/Ivy):

[info] Updating ...
[warn] 	module not found: org.benf#cfr;0.132.0

Similarly, it seems that 7.0.0 has a transitive dependency on org.eclipse.platform:org.eclipse.equinox.app, which I cannot resolve either, but things seem to work OK if I exclude that dep, i.e.

libraryDependencies += "fr.inria.gforge.spoon" % "spoon-core" % "7.0.0" exclude("org.eclipse.platform", "org.eclipse.equinox.app")

[nharrand]

Yes the dependency is available on the inria maven repo, which you can add (as in spoon's pom) with:

<repository>
      <id>inria</id>
      <name>triskell-public-release</name>
      <url>http://maven.inria.fr/artifactory/triskell-public-release</url>
</repository>

Not sure how to add a repo to sbt though (Perhaps something like this).
You can also download directly the jar on its author's website.

[monperrus]

Does it mean that the with-dependencies is not anymore a true with-dependencies, esp. for non Maven users?

[nharrand]

I'm not sure what do you mean, but the jar with-dependencies still contains everything including cfr.

[monperrus]

@RichardBradley did you take the with-dependencies version?

[RichardBradley]

@monperrus, I did not use the with-dependencies jar, no. I think it is more conventional to use the standard jar, as it allows for de-duplication of shared dependencies and detection of conflicting dependencies etc.

[RichardBradley]

@nharrand: the docs need updating to reference this non-standard repo then. The front-page does not mention this at present: https://github.com/INRIA/spoon#getting-started-in-2-seconds

I don't know what spoon needs "cfr" or "eclipse.equinox.app" for, but the latter at least looks like a possible mistake to me.

[nharrand]

You are using sbt right?
Did adding the additional repository worked for you?
If so, could you provide a sample of sbt build file that uses spoon? (We could definitely add it in the Readme or somewhere else.)
(cfr is used in for byte code analysis through decompilation.)

[RichardBradley]

I expect that adding the maven.inria.fr repository will work. I have not tried it, because I chose to downgrade to ver 7.0.0 rather than trust a repos I have never heard of.

(I think the SBT syntax is a distraction here; anyone using SBT will know how to translate Maven syntax into SBT.)

I think the two bugs here are:

1. cfr either a) get cfr published to the main Maven repositories, or b) update the docs to add the maven.inria.fr repos as a required third party repos
2. Do the same for eclipse.equinox.app, or remove it if it is not a real dependency (certainly everything that I have tried seems to work without that dep)

[nharrand]

rather than trust a repos I have never heard of.

I can understand that.

1.a) is not simple. I am not the author of cfr and not in control of the associated domain. The author does not plan to publish the artifact on Maven Central (according to his website), even if the binary is under MIT license.
1.b) As far as I understand, this is specific to other build systems than maven, as I think the procedure documented in Getting started in 2 seconds should work directly for maven. But we could and should indeed document it for other build systems. Would you like to make a PR?

I'm unsure about the role of eclipse.equinox.app, @monperrus WDYT?

[RichardBradley]

I think the procedure documented in Getting started in 2 seconds should work directly for maven

It does not; you need to add a repo which contains cfr to your Maven's config. I have just verified this by a) cloning spoon-examples, b) removing the custom <repository> from the POM, c) changing the spoon version in the POM from 6.2.0 to 7.1.0 and d) running mvn compile, which gives:

Could not find artifact org.benf:cfr:jar:0.132.0

There is no difference between SBT and Maven in this regard. I am sorry to have confused matters by posting an SBT snippet.

[nharrand]

Ok then, my bad. I'll try to fix this then.

[nharrand]

I have troubles reproducing it. If I download spoon-examples and change the version of the spoon dependency to 7.1.0, it still downloads cfr.
The custom repos declared in spoon-samples does not contains cfr. (If i create another project with a dependency to spoon, with no custom repository, it still download cfr as well.) (Same with a clean .m2)
When you did b) you meant on spoon-samples's pom right?
Do you have some particular settings.xml properties?

[RichardBradley]

I expect you have cfr cached locally. Try mvn -U to re-fetch deps.

See

spoon/pom.xml

Line 214 in f0dd561

<!-- This repository is needed for cfr -->

-- I expect the travis build will fail without that import.

[nharrand]

No, I did removed it from my cache. I even ran it in a docker container with an empty .m2. I also checked the log to verify that it was downloaded, and it was.

[nharrand]

-- I expect the travis build will fail without that import.

But wait, yes it would. That's the point of adding this repository. That's why I keep asking if you included these lines!

Do you mean that the bug you are reporting is, if you remove a part of the spoon pom, it stop working? If so we can discuss if having external repository is well founded, but it's definitely not a bug in the sense that it is not accidental.

[RichardBradley]

I feel like we are not understanding each other here. I am sorry. Let me try rephrasing things.

1. Users of fr.inria.gforge.spoon:spoon-core at ver >= 7.1.0 must add the maven.inria.fr repository (to their project's POM or to their own settings.xml) in order to resolve a transitive dependency (cfr), which is not included in the default public Maven repositories
2. The installation instructions for new users in your main README do not mention this requirement: https://github.com/INRIA/spoon#getting-started-in-2-seconds
3. Therefore new users see the error I quoted at the top of this thread

The easiest fix will be to update the documentation in the "Getting started in 2 seconds" section to include this custom repository (described above as fix 1.b).

There is a similar bug for a second non-public transitive dependency (org.eclipse.platform#org.eclipse.equinox.app;1.3.0), which will have similar fixes. I wonder in this case whether this dep is real. If it is, you need to make a similar documentation fix.

Does that clarify the bug?

[surli]

Hi @RichardBradley

Actually you're perfectly right, we shouldn't have put a dependency in our pom that is not available on Maven Central.
So indeed as a quickfix I'll add the missing instruction in the getting started.
On the longer term I'll try to get in touch with the maintainer of CFR to check if he's willing to release it on Maven Central.

Thanks for reporting this!

[nharrand]

Ok.
I'm not sure about 1.
But any way, we now have another decompiler (fernflower) so if cfr is such a problem, we can also remove it if needed.

[surli]

I'm not sure about 1.

Not sure either if it's a problem for everyone: I personally tested it in another project by removing any references I could have on my computer to INRIA and it managed to resolve it properly by getting the repository from the Spoon pom directly.

Anyway, it's definitely not recommended to put a dependency that is not in Maven Central in the pom, so we should be more careful about it.

Now I got an answer from the maintainer of CFR and he seems willing to put CFR on central, so on the long term view it should be ok.

[nharrand]

Anyway, it's definitely not recommended to put a dependency that is not in Maven Central in the pom, so we should be more careful about it.

I agree.

Now I got an answer from the maintainer of CFR and he seems willing to put CFR on central, so on the long term view it should be ok.

Wow. That's cool!