I am new to gradle.
I have two versions of Pig UDF (written in Java) com.x.test-udf:test-udf:0.0.3 & com.x.test-udf:test-udf:0.0.4
Is it possible in gradle to define dependency on both of them and have both jars included in the final build? How will the sample dependency declaration look like?
Thanks
Abhijit
Related
Suppose I've a Bazel package with a BUILD.bazel file that contains a list of dependencies. Some dependencies are not in use anymore. How to find the dependencie that are not in use ?
This is a Java project but I think the language is not important.
unused_deps works for Java projects. There is no tool that works for all languages. For C++ a pattern like IWYU can help to decide when and how to make a dependency.
There is two java projects A and B, the build-engine is gradle.
That is a multi-project and A depends on B
A: build.gradle
...
dependencies {
compile project (':B')
}
...
B has core code in src/main/java and test code in src/test/java.
Also in src/test/java is some testing infrastructure classes like loading of test-data.
gradle :B:test work fine
Tests in A-Project uses the testing infrastructure classes from B-Project, and that is alright for eclipse, but not for gradle. Because the builded jar-file dependency on B-Project includes only classes from src/main/java.
And we get the error:
com.aaa.SomeClassFromAAAA.java:42: error: cannot find symbol
import com.bbb.InfrastructureTestClassFromBBB;
What is the solution?
This is discussed on Gradle forum here. The idea is to build JAR with your test classes and make it visible to your A project. There are also notes why this is difficult for the IDEs.
The alternative way is to move test infrastructure classes into main sources of another project. This assumes they do not depend on A's main sources. You can see something similar in Gradle's codebase (int*-test* folders in https://github.com/gradle/gradle/tree/master/subprojects).
I've found two ways of compiling Clojure *.clj files into *.class files, and while they both work, I have some gripes with both of them.
The first one uses a REPL and so cannot be automated (or can it?)
The second one uses lein. To be frank I don't see why I should use a dependency management tool for something that should be part of the core tool-chain of the language. But in any case, using lein soon forces you to use a local Maven repository if your Clojure code needs to access local jars (which is highly likely).
Is there a better way to generate *.class or *.jar files from Clojure code that involves only core Clojure tools and that can be employed in a scripted, non-interactive way?
Clojure provides clojure.core.Compile, which can be used to compile Clojure code from the command-line.
java -Dclojure.compile.path=<targetdir> -cp <targetdir>;clojure.jar <list of namespaces>
For an example of how to use this from ant, look at the compile-clojure task in Clojure's own build.xml file.
clojure.core/compile can be automated via Clojure
I have following problem module core contains test utils which is resused in dependent modules.
How to use this code in those modules? (maven dosen't include this code by convention, but how to solve this problem)
Use maven-source-plugin to create a test jar. It will be published along with your normal jar as an artifact of the build.
Is there a simple way to find out what versions of dependencies are available using Leiningen?
E.g., if I have a web app which depends on Hiccup and Compojure, how can I be sure that I'm on the latest version of each without going to the github page for each?
NOTE: I use Ant and Ivy for building my Java projects, so I have limited knowledge of Maven - so please spell out (or provide Fine Links for me to read) any Maven concepts that Leiningen exposes to me which would help with this (I know that under the hood, Leiningen uses Maven for dependency resolution). Ta.
The Clojure ecosystem has evolved since the original answer was offered. At the present time, I would recommend using lein-ancient:
A Leiningen plugin to check your project for outdated dependencies and plugins. This plugin supersedes lein-outdated and uses metadata XML files in the different Maven repositories instead of a Lucene-based search index. Version comparison is done using version-clj.
Its precursor, lein-outdated, has this helpful message in its README: "lein-outdated is outdated". :)
The canonical way of doing this, at least for dependencies kept in clojars, is the lein-search plugin.
Update: See the highest-rated answer below for a more up-to-date response.
You should have a look at the answer to this question. Leiningen uses the same versioning mechanism as maven so, for example, if you want to use the latest version of a given library, you can substitute the word "LATEST" for the version number. You can also specify a release version or a version range. Again, look at the answer at that link.
Web service that provides this info, along with badges for readmes.
http://clj-deps.herokuapp.com
Disclaimer, by me.