Closure-compiler: Maven artifact without bundled dependencies?

[jleyba]

Commit 1b3efe85c4b66fa69078d02cd28f62780b414068 includes all of the compiler's dependencies in the jar. This creates classpath issues for projects that build custom compiler passes. Notably, closure-compiler includes protobuf-java.[email protected].

Please publish an artifact that does not include the compiler's dependencies.

_EDIT_: This is an issue with the v20151015 release.

[dimvar]

I have not looked into Maven at all. Tyler made our recent Maven changes, and he's on vacation for the next couple of weeks, so this will have to wait until after he comes back.

[MatrixFrog]

I'm not an expert on Maven but I'm learning more and more about it. I want to keep the complete jar so that we can just build it and push it to dl.google.com/npm/etc. but I don't mind having the alternate version as a separate output as well. If you know how to do this, a pull request would be most welcome.

[edgesite]

I think we have two solution to solve this problem. Relocate package to com.google.javascript.repacked.* or just make a new goal without dependencies.
I recommend the first solution, is avoid risk of incompatible version and seems Google like this.

[piranha]

Any news on this front? :-)

[piranha]

Why I'm interested: I use clojurescript (which depends on closure-compiler) and riemann-java-client in a single project. Riemann client depends on protobuf-java 2.6.1, while closure-compiler brings protobuf 2.5.0, which makes riemann fail with following exception:

Class com.google.protobuf.UnmodifiableLazyStringList does not implement the requested interface com.google.protobuf.ProtocolStringList
  [com.aphyr.riemann.Proto$Event getSerializedSize "Proto.java" 2105]
  [com.google.protobuf.CodedOutputStream computeMessageSizeNoTag "CodedOutputStream.java" 749]
  [com.google.protobuf.CodedOutputStream computeMessageSize "CodedOutputStream.java" 530]
  [com.aphyr.riemann.Proto$Msg getSerializedSize "Proto.java" 4195]
  [com.google.protobuf.AbstractMessageLite toByteArray "AbstractMessageLite.java" 62]
...

[ChadKillingsworth]

@piranha This is waiting on someone to submit a PR. The maven build would need to produce two versions of the compiler jar (with and without dependencies embeded).

[michaelhixson]

I made a PR for this: https://github.com/google/closure-compiler/pull/1594

It turns the existing pom-main.xml into a parent for two new modules: one that produces the current shaded/bundled jar with the current artifact name, and one that produces a non-shaded jar with a different, new artifact name. The non-shaded one is built first, then the shaded version reuses the compiled files from the first step and does not run the tests again.

https://github.com/EsotericSoftware/kryo is another project that releases both shaded and non-shaded artifacts. I looked there for guidance.

mvn clean package produces the output I'd expect. I don't know what Maven incantation happens during an actual release build, so I can't guarantee that it works properly there.

A safer way to implement this (guaranteeing the current artifacts remain unchanged) might have been to not change the existing pom-main.xml file at all, and to copy and paste most of the contents into a new pom. You'd replace the shade plugin with the jar plugin in the new pom, and you'd specify a different build directory (not target). I did not go that route because the redundancy (of code, of compilation, and of test running) made me sad, and I figure it would be harder to maintain in the long run.

Maybe there is an even better way to handle this that I don't know about.