These are chat archives for jruby-gradle/jruby-gradle-plugin

10th
Jun 2015
R. Tyler Croy
@rtyler
Jun 10 2015 14:13
@ysb33r do you use the maven-publish plugin?
despite documentation stating to the contrary, it seems like everybody is still using the normal ol' maven plugin
Schalk W. Cronjé
@ysb33r
Jun 10 2015 14:23
I prefer the old one - it works for my use-cases. The new one’s DSL is not very slick.
R. Tyler Croy
@rtyler
Jun 10 2015 14:26
no it is not :(
Gradleware needs to learn to use asciidoctor :)
so they can put examplesin their freakin docs
Schalk W. Cronjé
@ysb33r
Jun 10 2015 14:32
That whole from components.java thing is just wrong IMHO. It’s black magic at this point in time as far as a plugin author is concerned
R. Tyler Croy
@rtyler
Jun 10 2015 14:32
yeah, wtf does that even do? :P
there is an 'artifacts' thing in the DSL though, surely that's enough?
Schalk W. Cronjé
@ysb33r
Jun 10 2015 14:33
I think they want to get rif of artifacts
R. Tyler Croy
@rtyler
Jun 10 2015 14:34
but they're so useful!
I've got to find a way to publish the same artifact with two different group IDs into a maven repository, and it seems like "switch everything to maven-publish" is the only (moderately) sane way to accomplish that
Schalk W. Cronjé
@ysb33r
Jun 10 2015 14:37
alternative is a subproject which depends on the first and then just perform a publish
R. Tyler Croy
@rtyler
Jun 10 2015 14:37
wouldn't that publish a pom but not artifact into the repo?
Schalk W. Cronjé
@ysb33r
Jun 10 2015 14:41
you have to try it, but I think for a starter
group = ‘new.group’
task dupicateJar ( type : Copy ) {
  from project(‘:other:project’).jar
  destinationDir “${buildDir}/libs”
}
artifacts {
  duplicateJar
}
R. Tyler Croy
@rtyler
Jun 10 2015 14:41
iiiiinteresting idea
much saner than maven-publish, I'll take a whack at it, thanks for the suggestion
Schalk W. Cronjé
@ysb33r
Jun 10 2015 14:42
comes with no warranty
the problem you ran into is one of the reasons of getting rid of old maven plugin.
rtyler @rtyler nods
R. Tyler Croy
@rtyler
Jun 10 2015 14:48
replacing it with something that is harder to use but more flexible is definitely not a recipe for success
Schalk W. Cronjé
@ysb33r
Jun 10 2015 14:51
no, but they do still state that it is incubating.
I should really write a forum post about it sometime
R. Tyler Croy
@rtyler
Jun 10 2015 14:51
I'm starting to hate 'incubating'
that plugin has been incubating for as long as I've been using gradle (~1 year)
Schalk W. Cronjé
@ysb33r
Jun 10 2015 14:52
:shipit:
R. Tyler Croy
@rtyler
Jun 10 2015 14:52
heh
R. Tyler Croy
@rtyler
Jun 10 2015 15:59
@ysb33r it apparently was a bit easier than that
apply plugin: 'maven'

group = 'com.lookout.services'
version = rootProject.version

artifacts {
    archives rootProject.serviceJar
}

uploadArchives {
    repositories {
        mavenDeployer {
            pom.artifactId = rootProject.name
            repository(url: servicesArtifactoryUrl) {
                authentication(userName: artifactoryUsername,
                               password: artifactoryPassword)
            }
        }
    }
}
:ship:
Schalk W. Cronjé
@ysb33r
Jun 10 2015 16:06
excellent! no need to have a copy.
R. Tyler Croy
@rtyler
Jun 10 2015 21:02
@ysb33r actually I think I was mistaken earlier
gradle appears to be doing something intelligent about trying to upload the same file multiple times
I didn't notice that if I executed tasks with both in the same task execution cycle, only one uploadArchives task would work
Schalk W. Cronjé
@ysb33r
Jun 10 2015 21:03
does not sound right. If the two tasks are in seprate projects both should execute in the original jar changed.
if you run the build with —rerun-tasks will both upload?
rtyler @rtyler runs
Schalk W. Cronjé
@ysb33r
Jun 10 2015 21:05
(assuming the upstream repoS will accept overwrites)
R. Tyler Croy
@rtyler
Jun 10 2015 21:07
they've got different group IDs
--rerun-tasks doesn't do anything, it really seems to be that bot hin the same execution doesn't work
Schalk W. Cronjé
@ysb33r
Jun 10 2015 21:12
mmm….
R. Tyler Croy
@rtyler
Jun 10 2015 21:15
HMMMMMMm indeed, running locally this works fine
Schalk W. Cronjé
@ysb33r
Jun 10 2015 21:15
you mean in the folder?
R. Tyler Croy
@rtyler
Jun 10 2015 21:16
sanity check me here
if I have a root task called makeMagicHappen
with dependsOn uploadArchives
that behaves differently than if I use ./gradlew uploadArchives on the command line doesn't it?
the latter dcalling uploadArchives in subprojects I am assuming
Schalk W. Cronjé
@ysb33r
Jun 10 2015 21:17
indeed.
in the first case the dependsOn will be scoped to the script in which it is located
R. Tyler Croy
@rtyler
Jun 10 2015 21:17
there's my bug then :0
Schalk W. Cronjé
@ysb33r
Jun 10 2015 21:18
you can do dependsOn ‘uploadArchives’, ‘:foo:uploadArchives’
R. Tyler Croy
@rtyler
Jun 10 2015 21:18
I've got a publish task in all my subprojects which handles their publishing
and the CLI contract is that Jenkins will invoke publish
Schalk W. Cronjé
@ysb33r
Jun 10 2015 21:45
I’ve been pretty busy with some other stuff - among things as you might know is an Asciidoctor -> Leanpub converter
R. Tyler Croy
@rtyler
Jun 10 2015 21:53
ooooOOOoo
@ysb33r how is the book coming along?
rtyler @rtyler wants to proof read
Schalk W. Cronjé
@ysb33r
Jun 10 2015 22:11
two weeks and I should be ready enough. Trying to work on the front-cover and fixing the preface