I was able to finally get things to work, for both of my cases (multiple jars because of multiple variants, and multiple jars because of dependencies in a true multi-project scenario), and I thought I'd share a little bit of my experience, in case it helps someone in the future.
I can't just pinpoint a single solution, because it really was a multi-faceted problem. And one that, in retrospect, I can see would have been somewhat hard to answer from just the questions that I asked, since it involved navigating through more than just my project(s), but common build-related *.gradle files that are shared across the organization. I recommend taking a look at the multiproject example, and even trying to build it yourself, that is included with the gradle artifactory plugin. That helped initially point me in the right direction for solving my problems. You can find it here: * https://github.com/JFrogDev/build-info/tree/master/build-info-extractor-gradle As I was pointed to from here: * http://forums.jfrog.org/Source-available-for-Gradle-Artifactory-plugin-tt7579585.html My initial report of progress by renaming the subprojects was somewhat of a false solution. The source of that problem was that there was common code regarding the publishing to artifactory that was setting archivesBaseName. And it wasn't accounting for the multi-project scenario, which meant that what I wanted my artifacts to be named and what they were actually named wasn't matching. And I think this may have been the source of some HTTP 409 Conflict errors. One big aspect of understanding this all was the realization that a lot of what I thought was the domain of the artifactory plugin was really the domain of the maven plugin. So saying that something is going wrong with artifactory may not really be true. Read through and pay attention to documentation for the maven plugin. I realize that invoking the artifactory plugin somehow (I haven't yet traced down where or how this happens) ends up automatically generating a pom file, and that pom file is published to artifactory but not saved locally (aside -- can you override this? I'd love to end up with a copy in my buildDir as a side effect). But you can also use the maven plugin directly to generate a pom file. If that doesn't look correct (e.g. is missing dependency info), that might be a sign of something suspicious. One big question I had was, for multiple artifacts, should I differentiate them by different names (e.g. foo-bar and foo-baz), or use the same name and differentiate by classifier. Exactly when you ought to use classifier seems to be a topic of some argument. But I think this sums it up pretty nicely: * https://maven.apache.org/pom.html "The classifier allows to distinguish artifacts that were built from the same POM but differ in their content." So if the dependencies might be different, then the POMs should be different, and you should differentiate via name, and not classifier. I've decided to reserve using classifier solely for different types of artifacts (e.g. javadoc jar, source jar) from the same actual sources. But maven doesn't really seem to like the idea of multiple POMs per project. Nevertheless, gradle doesn't think this is a bad idea, and the maven plugin does allegedly support it. See the following: * http://www.gradle.org/docs/current/userguide/maven_plugin.html#multiplePoms I was never able to get this to work. I could get the maven plugin to generate multiple POMs, but they didn't have the dependency info right. I thought that I had found the solution, and that all I had to do was add the configurations that mattered to the relevant Conf2ScopeMappingContainer, as described here: * http://www.gradle.org/docs/current/userguide/maven_plugin.html#mappings But I just couldn't get it to work, and eventually abandoned that effort. I welcome a response from someone who has successfully used the ideas discussed in these two sections of the maven plugin docs in the context of artifactory. For SNAPSHOT builds, at least, internally in artifactory, artifacts are stored like: * ${name}-${version}-${yyyy}${mm}${dd}.${hh}${mm}${ss}-${num}.jar On many occasions when things weren't working properly, I'd instead just get: * ${name}-${version}-SNAPSHOT.jar I'm not positive now in retrospect, but I think that may have been a sign that the POM wasn't being uploaded. What I did instead to properly generate multiple POMs was to use a multi-project build. If I want another regular jar file, then it comes from a different subproject. I think this actually ended up as a cleaner solution than one that relied on solely on different sourceSets and configurations for the different variants. Note that while each jar is coming from a different subproject, each subdir doesn't have to actually be a real project with a real artifact. In one of my cases, I wanted an android and a server variant. The vast majority of the code is common. That's in a common subdir, but it's technically not a subproject (it's not pointed to by the top level settings.gradle). Then there are really two different subprojects, which each produce a single jar, and I reference the two dirs (common plus unique) via a Set of srcDirs in the sourceSet. Which was another revelation, that srcDirs must be a Set, not a List. And Groovy doesn't provide any simple shorthand that I know of for declaring a set, but you can take the "[]" notation of the List and make it a set with either ".toSet()" or " as Set" as a suffix. Carefully paying attention to what happened and was applied where, and properly differentiating in the build.gradle file for the root project between what's in the top level file, and what's in the allprojects{} closure, and what's in the subprojects{} closure, was also important. And if you don't want a nearly empty (manifest only) jar file for the root project, and you don't want that published to artifactory, you probably want the following in the build.gradle for your root project. artifactoryPublish.skip = true jar.enabled = false One final important realization was that, in general, properties are inherited from parent projects to child projects. See the discussion about the 5 different property "scopes" in the Project DSL: * http://www.gradle.org/docs/current/dsl/org.gradle.api.Project.html Often, this is what you want. But not always. Note that project.hasProperty('foo') will return whether or not the property exists anywhere in the chain leading to the current project. If you only want to check whether the exact current project has that property defined, and not to inherit it from a parent project, you can use project.ext.properties.get('foo'). I hope that perhaps some of this might be of help at some point in the future to someone else experiencing similar problems. -- View this message in context: http://forums.jfrog.org/Publishing-multiple-jars-with-the-Gradle-Artifactory-plugin-tp7579584p7579614.html Sent from the Artifactory - Users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Artifactory-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/artifactory-users
