We're switching build system from Ant to Gradle, mainly to benefit from the "automagic" dependency management. However, I'm having great problems resolving jug 2.0.0.
I've defined it in my build.gradle file like this:
compile 'org.safehaus.jug:jug:2.0.0'
which corresponds to the name of the artifact entry in Maven Central, but when I look in my Gradle cache only the pom.xml file has been downloaded - no jars.
Looking at the artifact details on the Maven Central search page, it seems there are three files; jug-2.0.0.pom, jug-2.0.0-asl.jar and jug-2.0.0-lgpl.jar, where the difference between the latter two is the license (Apache Software License vs LGPL). I've tried adding -asl and -lgpl to the version number in the dependency specification, but it didn't help.
How do I correctly define this dependency, so that the jar files are downloaded and referenced?
The 'lgpl' part of the dependency is the classifier. Try to resolve it using:
dependencies{
compile 'org.safehaus.jug:jug:2.0.0:lgpl'
}
Related
In my gradle java library project, I have a dependency on a local jar file (the artifact is not published anywhere). The dependencies configuration looks like:
dependencies {
api fileTree(dir: '3rdparty', include: '*.jar')
}
When I publish my library to maven local, and then pull it in from another project, the symbols from the jar in the 3rdparty folder aren't available on the classpath, even though it's listed as an api dependency. Is this just a limitation of using jar files directly within library modules or something?
This is a well known limitation on File Dependencies. The Gradle documentation is clear on that
File dependencies are not included in the published dependency descriptor for your project. However, file dependencies are included in transitive project dependencies within the same build. This means they cannot be used outside the current build, but they can be used within the same build.
The reason is simply that those dependencies are not externally resolvable by other projects in contrast to artifacts hosted in a binary repository. Read more about this topic in the Declaring Dependencies userguide.
I have a maven project that depends on several sbt project, which in turn depends on more projects. Are these transitive dependencies being resolved by maven? E.g. in packing of assemby jar?
Let me answer this question with mine: How can you know what build tool was used in a dependency?
You can't unless the build tool leaves some files to let you guess what the build tool could have been. But still, they're just files that are generated as part of the publishing process so the other build tools could resolve dependencies.
That's the point of any build tool to let you integrate with the other build systems in a less troublesome way.
Maven requires pom.xml and an appropriate repository layout. sbt follows the rules while publishing project artifacts to Maven repositories.
Ivy requires other files in repositories and sbt does generate them (by default).
Gradle plugs itself in to the game by following Maven's standard files and directory layout.
Read about publish task. You may want to consult the official documentation of sbt. Start with http://www.scala-sbt.org/0.13/docs/Publishing.html.
On mvnrepositry, when you search for a certain module, there's a link to download the binary. For some versions it has a pom.xml file available for download instead of the jar. What are you supposed to do with that pom.xml? It seems like if I specify a version that does not have a downloadable jar, but instead downloadable pom.xml, my maven build will fail. Is what I'm seeing correct?
Modules that only have pom files are maven modules with pom packaging. They are used to aggregate multiple modules into one unit. You can use such a module as a dependency for your maven project. Maven will download the pom file, analyze the dependencies included in that pom file and download those & add it to your automatically.
Even modules that have jars (jar packaging) have a pom file associated with them. This pom file defines the other dependencies that are required for using it. Maven will automatically process and fetch those dependencies (transitive dependencies).
This makes specifying and managing dependency for any project. You will specify the top level modules that your projects directly depends on and other things required will automatically figured out and downloaded. It also makes it easier when you have upgrade to a new version - all the transitive dependencies will get upgraded automatically.
One of the reason that cause this is because of licensing issue.
License for such JARs prohibit public redistribution in such approach. So someone provide only the POM so that you can get the JAR yourself and install it to your local maven repo/ internal repo, together with the POM provided.
It's not in jbossesb-rosetta which I already depend on. I've looked at http://mavenhub.com/c/org/jboss/soa/esb but I can't seem to find it. I suppose I can always include it as a system dependency but only as a last resort.
Analysis
1)
That artifact is not present in Maven Central, explaining why Maven cannot find it by default:
http://search.maven.org/#search|ga|1|a%3A%22jbossesb-soap%22
2)
Jboss artifacts are hosted by a separate Nexus repository. A search there was similarily fruitless:
https://repository.jboss.org/nexus/index.html#nexus-search;gav~~jbossesb-soap~~~
3) A Google search threw up this same unanswered question on Jboss community forum:
https://community.jboss.org/thread/154253
Recommendation
Seems you are left with only one option. Upload the required jar into your own Maven respository so that the dependency can be found.
If you want to simply hack the jar into your current build, then I would recommend installing it into your local repository. Do not use system scope dependencies.
Jars can be installed locally using the Maven install plugin
I have quite a situation here: another team is building a Flex SDK and delivers it as a huge set of separate SWC files. At this point I cannot make them build a single SWC file library.
I'm trying to use these files as Maven dependencies to pass to Flexmojos but they are like 40 files and I don't want to manage each of them as a separate dependency (after all they are parts of the same thing).
Is there a way to:
Install all of the SWC files as artifacts in the local repo? (with the same groupId and version and auto-generated artifactId I guess)
Import these as dependencies using a "wildcard" or plugin that generates dependencies at runtime or something?
this won't work that way. Dependency declarations can't be dynamic, this would break the build. What you can do is have your deployers create a rollup pom with packaging pom containing all of the SWC dependencies and deploy that pom into your nexus repository. You'd be able to use that pom dependency. The benefit would be that the pom is maintained in a single central location.
You can use the build-helper-maven-plugin to add artifacts to the Flex SDK project. As a result you can use the SDK project as a dependency and got all files which you can use.