Depend on Closure Compiler jar instead of importing source code

[benmccann]

I think that plovr's version of closure is pretty close to the real version since this change was made

https://code.google.com/p/plovr/source/detail?r=d1c217a362000f2321870088d401d7560dad0e2c

[bolinfest]

Unfortunately that is not a sustainable option because compiler/templates/stylesheets often bundle different versions of the same jar, such as guava.

I believe I eliminated my local changes to the compiler: it's mainly a matter of updating the build scripts so it is easier to pull the latest versions of all of Google's tools from GitHub. On Jun 13, 2014 7:14 PM, "Ben McCann" notifications@github.com wrote:

I think that plovr's version of closure is pretty close to the real version since this change was made

https://code.google.com/p/plovr/source/detail?r=d1c217a362000f2321870088d401d7560dad0e2c

— Reply to this email directly or view it on GitHub https://github.com/bolinfest/plovr/issues/21.

[benmccann]

Sorry, accidentally hit close. We can close if you really think it's not reasonable. I'd be surprised if it ended up being a real issue though. The majority of Java projects are built using something like Maven and pull in numerous libraries which transitively pull in different versions of the same library. It ends up just using the newest and in practice that works the vast majority of the time. Plus Google allows only one version of a library internally which will greatly reduce the chance of the library versions getting too out-of-sync.

[monzonj]

Hi, "Plus Google allows only one version of a library" -

• closure-compiler uses Guava 17.0
• closure-templates uses Guava 14.0

They build with ant, libraries are included in the distribution. Both contain enough changes to break one another.

I've submitted a pull request to bring templates up to date, but that project doesn't seem to get much love.

"It's mainly a matter of updating the build scripts" You underestimate the changes the Google guys have done to the compiler. I certainly had to change a lot of things in my copy of plovr to bring all the latest options/features. Expect compilation errors/warnings.

[pauldraper]

+1. This is the "right way" to manage dependencies.

It ends up just using the newest

FYI, it's slightly more nuanced than that. Maven uses the "nearest" dependency, then the newest to break ties; Ivy and Gradle use the newest. (Though all are configurable.) Maven can display differences.

But this is a very common situation in the Java community, especially for common dependencies like Google Guava, Apache Commons, etc. Well-maintained libraries like these emphasize backwards compatibility for this reason. I'd be a little surprised if Guava 17.0 wasn't almost entirely backwards compatible to 14.0, though it certainly might not be.

[teppeis]

@bolinfest @nicks This seems to be fixed by in v7 https://github.com/bolinfest/plovr/pull/124