Skip to content
This repository has been archived by the owner on Feb 11, 2022. It is now read-only.

aditional artifacts examples #24

Closed
jcranky opened this issue Mar 27, 2015 · 23 comments
Closed

aditional artifacts examples #24

jcranky opened this issue Mar 27, 2015 · 23 comments

Comments

@jcranky
Copy link

jcranky commented Mar 27, 2015

I'm publishing a java project, with jar, sources and javadoc. I also want to publish an extra jar file, for which I already have the custom task. The wiki mentions I should be able to configure my own publishing to do this kind of thing, but I'm not sure how. An example in the wiki would be great.

I'm pretty sure I should be able to extend JavaArtifacts for that, since I what I want is that plus the new jar. Perhaps I lost because I'm new to groovy and gradle, so again, an example would help a lot.

thanks!

@blundell
Copy link
Contributor

You want to publish 1 jar with another jar inside it?
Or you want to publish 1 jar with a dependency on another jar?

@jcranky
Copy link
Author

jcranky commented Mar 28, 2015

Neither, just a new jar file, with a different classifier - a new artifact. Something like this:

task deobfJar(type: Jar) {
    from sourceSets.main.output
    classifier = 'deobf'
}

@jcranky
Copy link
Author

jcranky commented Mar 31, 2015

By the way, I currently have the task mentioned above and this

tasks.build.dependsOn('deobfJar')

which generates the -deobf.jar file. I just wanted to have it published together with the other 3 artifacts already being published :)

@xrigau
Copy link
Contributor

xrigau commented Apr 1, 2015

I'm not 100% sure but this wiki page might be useful https://github.com/novoda/bintray-release/wiki/Defining-a-custom-Publication

I think you need to define your own publication and add the atrifacts you want in there

@jcranky
Copy link
Author

jcranky commented Apr 1, 2015

I read that, but I don't know how to define my publication. Perhaps I'm not seeing something obvious because I don't know much about groovy and gradle - that's why the examples would be helpful, not just to me, but anyone in a similar situation :)

@xrigau
Copy link
Contributor

xrigau commented Apr 7, 2015

I assume you're working on a java project (not an android project)

See here you can use just a string to define an artifact https://github.com/novoda/bintray-release/blob/master/core/src/main/groovy/com/novoda/gradle/release/AndroidArtifacts.groovy#L29

So if you know what's the path to the jar you generate (the -deobf.jar one) then I think you can just extend the JavaArtifacts class and override the all() method to return the super plus your own artifact.

I'm not exactly sure about the syntax but something like:

class JavaWithDeobfArtifacts extends JavaArtifacts {

  @Override
  def all(Project project) {
    def list = super.all(project)
    list.add(deobfuscatedJar())
    return list
  }

  def deobfuscatedJar(Project project) {
    "$project.buildDir/foobar-deobf.jar" // TODO: Replace with the right path
  }

}

and then you should be able to use that with something like this:

    void attachArtifacts(Project project) {
        Artifacts artifacts = new JavaWithDeobfArtifacts()
        String projectVersion = getString(project, 'version', project.publish.version)
        project.publishing {
            publications {
                maven(MavenPublication) {
                    groupId project.publish.groupId
                    artifactId project.publish.artifactId
                    version projectVersion

                    artifacts.all(project).each {
                        delegate.artifact it
                    }

                    from artifacts.from(project)
                }
            }
        }
    }

and then call attachArtifacts() from your gradle script after applying the release plugin (probably after defining the publish closure).

I haven't checked that code so it might not work or be incomplete.

Let me know if that works and if it doesn't I'll try to replicate it with a simple project

@jcranky
Copy link
Author

jcranky commented Apr 8, 2015

Yes, it is a Java (Scala, actually, but it is the same from this perspective). Where should I put my custom JavaWithDeobfArtifacts?

@xrigau
Copy link
Contributor

xrigau commented Apr 8, 2015

the easiest would be to put it inside your build.gradle file directly

@jcranky
Copy link
Author

jcranky commented Apr 8, 2015

I should have though of that XD
I tried it and it didn't work with this error:

Caused by: org.gradle.api.InvalidUserDataException: Cannot add task ':sourcesJar' as a task with that name already exists.

@ouchadam
Copy link
Contributor

I raised a PR to fix the task name issue, #42

@xrigau
Copy link
Contributor

xrigau commented Apr 13, 2015

@jcranky try again but using 0.2.10 and see if there's more luck

@jcranky
Copy link
Author

jcranky commented Apr 15, 2015

I'm still a bit lost on what I should do. I tried some stuff here and the best I got until now is

Caused by: org.gradle.api.InvalidUserDataException: Maven publication 'maven' cannot include multiple components

My current working build is here: https://github.com/easyforger/easyforger/blob/master/build.gradle, but without the custom publishing. Locally, the publish / publishing / publications doesn't seem to have any effect =(

@ouchadam
Copy link
Contributor

have you also selected the publication like -

publish {
    userOrg = 'novoda'
    groupId = 'com.novoda'
    artifactId = rootProject.name
    version = project.version

    description = 'Super duper easy way to release your Android and other artifacts to bintray'
    website = "https://github.com/novoda/${rootProject.name}"

    publishing {
        publications {
            superPublication(MavenPublication) {
                groupId project.publish.groupId
                artifactId project.publish.artifactId
                version project.publish.version

                Artifacts artifacts = new JavaArtifacts()

                artifacts.all(it.name, project).each {
                    delegate.artifact it
                }

                from artifacts.from(project)
            }
        }
    }

    publications =["superPublication"]

}

The error seems like you've reused the maven publication name, it'll need to be unique!

@jcranky
Copy link
Author

jcranky commented Apr 15, 2015

You mean the publications =["superPublication"] line, right? I had it, but it seemed to be ignored. I'll try again later today from scratch and if I get different results I'll post back here.

@jcranky
Copy link
Author

jcranky commented Apr 15, 2015

For a quick try, what I did:

  1. update bintray-release to 0.2.10:
classpath 'com.novoda:bintray-release:0.2.10'
  1. Add this import:
import com.novoda.gradle.release.*
  1. added @ouchadam 's publishing block, and set the publications as well

With that, I couldn't get the results from the superPublication to run. I executed:

./gradlew --stacktrace clean build publishMavenPublicationToMavenLocal

And got:

:build
:generatePomFileForMavenPublication
:mavenJavadocJar
:mavenSourcesJar
:publishMavenPublicationToMavenLocal

Perhaps I'm not doing something I should be doing?

Also, IDEA shows me the publishing inside of the publish closure as underlined gray, meaning it doesn't seem to find it.

@jcranky
Copy link
Author

jcranky commented Apr 18, 2015

After some investigation, the problem seems to be that I was using publishMavenPublicationToMavenLocal. With bintrayUpload the custom publication is found.

I still have to do some more testing, but how can we have the same results with both publishMavenPublicationToMavenLocal and bintrayUpload? The idea is to use local maven publishing to test stuff, and the bintray upload when everything is ready.

thanks!

@ouchadam
Copy link
Contributor

sorry for the delay

the "maven" part of "publishMavenPublicationToMavenLocal" is the publication name, so in the example I gave it was called "superPublication" would be "publishSuperPublicationPublicationToMavenLocal"

The ...publicationToMavenLocal task is done by default when using dryRun=true (which is also the default setting for bintrayUpload) which means bintrayUpload will always do a maven local deploy unless you provide dryRun=false and in that case it'll upload to bintray

hope that helps!

@jcranky
Copy link
Author

jcranky commented Apr 20, 2015

Perfect, thank you! bintrayUpload with dryRun fit the bill just fine. This is how I ended up setting up my publication, in case you want to use it as an example in the documentation:

import com.novoda.gradle.release.*

def deobfJarPublish(String publicationName, Project project) {
    project.task(publicationName + 'DeobfJar', type: Jar) {
        classifier = 'deobf'
        from sourceSets.main.output
    }
}

publish {
    ...
    dryRun = true

    publishing {
        publications {
            deobfPublication(MavenPublication) {
                groupId project.publish.groupId
                artifactId project.publish.artifactId
                publishVersion project.publish.publishVersion

                Artifacts artifacts = new JavaArtifacts()
                (artifacts.all(it.name, project) + deobfJarPublish(it.name, project)).each {
                    delegate.artifact it
                }
                from artifacts.from(project)
            }
        }
    }

    publications = ['deobfPublication']
}

I still find it a bit verbose, but it works :D

thank you!

@friedger
Copy link
Contributor

@jcranky
Copy link
Author

jcranky commented Feb 7, 2016

I just updated to version 0.3.5 and the custom publication discussed above seems to be broken now:

Caused by: org.gradle.api.internal.MissingMethodException: Could not find method publishing() for arguments [build_12cycqr9h1kaaswhvdttv9vva$_run_closure5_closure10@1f71e024] on root project

Should I open a new issue? Or perhaps I missed something in the update process?

@xrigau
Copy link
Contributor

xrigau commented Feb 9, 2016

hey @jcranky there's an issue already #75

the temporary solution is to just revert back to 0.3.4 until we fix and release a new one

@jcranky
Copy link
Author

jcranky commented Feb 9, 2016

Uhmmm not sure if this is the same thing. Using 0.3.4 gives me the same result:

Caused by: org.gradle.api.internal.MissingMethodException: Could not find method publishing() for arguments [build_hvucr0990rgadjc575ptdeb4m$_run_closure5_closure10@384472bf] on root project

Reverting to 0.3.2 works though.

@Wrywulf
Copy link

Wrywulf commented Sep 6, 2016

I could get around this by applying the 'maven-publish' plugin explicitly

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants