etiennestuder / gradle-plugindev-plugin Goto Github PK

I use plugindev plugin pushlish to bintray.com,But i can't download it.How i fix resolve it?

error log:

Error:Could not find ihrthk.droidsonroids.gradle.localization:android-gradle-localization-plugin:1.0.8.
Searched in the following locations:
file:/D:/Program Files (x86)/android-studio/gradle/m2repository/ihrthk/droidsonroids/gradle/localization/android-gradle-localization-plugin/1.0.8/android-gradle-localization-plugin-1.0.8.pom
file:/D:/Program Files (x86)/android-studio/gradle/m2repository/ihrthk/droidsonroids/gradle/localization/android-gradle-localization-plugin/1.0.8/android-gradle-localization-plugin-1.0.8.jar
https://jcenter.bintray.com/ihrthk/droidsonroids/gradle/localization/android-gradle-localization-plugin/1.0.8/android-gradle-localization-plugin-1.0.8.pom
https://jcenter.bintray.com/ihrthk/droidsonroids/gradle/localization/android-gradle-localization-plugin/1.0.8/android-gradle-localization-plugin-1.0.8.jar
Required by:
:VideoPlayer:unspecified

config:
classpath 'ihrthk.droidsonroids.gradle.localization:android-gradle-localization-plugin:1.0.8'

address:
https://bintray.com/ihrthk/groovy-plugins/android-gradle-localization-plugin/1.0.8/view

Please update to new gradle-bintray-plugin that supports gradle 2.4 once it is available per this issue
bintray/gradle-bintray-plugin#70

The generated .pom file does not appear to include the dependencies of the module project. Previous publications set up by hand using Nexus, e.g. gradle-velocity-plugin, have not had this trouble.

To reproduce:

clone https://github.com/shevek/gradle-jnaerator-plugin
run ./gradlew --daemon publishPluginPublicationToMavenLocal
clone [email protected]:shevek/udev4j.git
run ./gradlew --daemon jar

Could you make the pluginBundle propperty from the new publishing plugin configurable?

Hi @etiennestuder

According to official documentation for custom plugins Section 59.5. A standalone project developer has to provide property files in META-INF/gradle-plugins folder:

So how does Gradle find the Plugin implementation? The answer is you need to provide a properties file in the jar's META-INF/gradle-plugins directory that matches the id of your plugin.

Example 59.6. Wiring for a custom plugin

src/main/resources/META-INF/gradle-plugins/org.samples.greeting.properties
implementation-class=org.gradle.GreetingPlugin

Your plugin will generate it if it's missed BUT if it exists that jar file will have 2 files:

One of the file has original content:

implementation-class=com.github.moleksyuk.plugin.SemanticVersionPlugin

And generated:

implementation-class=com.github.moleksyuk.plugin.SemanticVersionPlugin
implementation-version=1.0.0

If you try to unzip it you won't get two files on file system with the same file but jar contains them. Seems like it's a jar feature 😄

I don't think it's a critical because both of them have definition of plugin implementation class but probably you should fix this anyway.

The documentation for the high-level-steps is not linkable anymore.

I am so glad I found this plugin, thanks for writing it!

It would be great if the plugin also added the OJO repository to resolve and publish snapshots. It may be best to use the artifactory plugin to handle the publishing of snapshots to OJO.

I am happy to do the work for this, just let me know if this is something that fits with your vision of the project.

Repository: https://github.com/shevek/gradle-velocity-plugin

Output:

Executing task ':bintrayUpload' (up-to-date check took 0.0 secs) due to:
  Task has not declared any outputs.
Found 0 configuration(s) to publish.
Version 'shevek/gradle-plugins/gradle-velocity-plugin/1.0.2-SNAPSHOT' does not exist. Attempting to creating it...
:bintrayUpload FAILED
:bintrayUpload (Thread[Daemon worker Thread 7,5,main]) completed. Took 1.694 secs.

Exception:

Caused by: org.gradle.api.GradleException: Could not create version '1.0.2-SNAPSHOT': HTTP/1.1 400 Bad Request
        at com.jfrog.bintray.gradle.BintrayUploadTask$_bintrayUpload_closure6_closure26_closure30.doCall(BintrayUploadTask.groovy:264)
        at groovyx.net.http.HTTPBuilder$1.handleResponse(HTTPBuilder.java:503)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:1070)

Hi @etiennestuder

Do you have any plans to update dependency of bintray plugin to v1.0?

v.0.6 does not support mavenCentralSync definition and sync to maven central can not be enabled with your plugin:

bintray {
    user = "$bintrayUser"
    key = "$bintrayApiKey"
    pkg {
        repo = 'gradle-plugins'
        version {
            gpg {
                sign = true
                passphrase = "$gpgPassphrase"
            }
            mavenCentralSync {
                sync = true
                user = "$sonatypeUserToken"
                password = "$sonatypeUserTokenPassword"
                close = '1'
            }
        }
    }
}

Hello,

I've been using your plugin for a few plugins and it is working fine :) Thanks for that!

However I recently wanted to bundle more than one plugin in a same JAR and the current implementation does not allow that.

Is that on purpose?
I'd gladly submit a PR to have it working for multiple plugins.

Cheers

The generated scm section in the pom file should contain a connection and developerConnection entry (see Section SCM).
For github the defaults would be

<connection>scm:git:git://github.com/user/example.git</connection>
<developerConnection>scm:git:[email protected]:user/example.git</developerConnection>

I removed the plugin descriptor on my project since it is being generated by the plugin, but it doesn't seem to be available when the tests run so they all fail 😢

See: https://travis-ci.org/ReadyTalk/gradle-readytalk-js/builds/40609923

The mechanism through which plugins are deployed to the plugin portal has changed, and you don't publish them to bintray, is this plugin going to be updated for the new mechanism?

See Here:
https://plugins.gradle.org/docs/submit

The generated license section in the pom file should set the distribution to repo or manual (see Section Licenses).
I would appreciate the repo as default value.

Maybe I've done sth wrong but If you write test in nebula-test you need to have the META-INF/gradle-plugins entry for the nebula project to see that your plugin is available.

If one uses this plugin he will not have this file created before tests and if it's there the tests don't seem to see the plugin descriptor.

There is a workaround for Gradle though:

task copyPluginDescriptorToMetaInf(type: Copy, dependsOn: generatePluginDescriptorFile) {
    from "$project.buildDir/plugindev"
    into "${sourceSets.main.output.resourcesDir}/META-INF/gradle-plugins"
}

test.dependsOn copyPluginDescriptorToMetaInf

How do you think it would be possible to add this functionality to your plugin? Some switch maybe like

copyDescriptorToBuildFolder = true

The problem still remains for running tests from IDE.

Is this project already set up for CI somewhere? I can open a pull request to get something going with TravisCI or whatever other service is preferred.

It seems that with latest version I get this:

Caused by: org.gradle.api.internal.plugins.PluginApplicationException: Failed to apply plugin [id 'nu.studer.plugindev']
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyPlugin(DefaultObjectConfigurationAction.java:117)
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$200(DefaultObjectConfigurationAction.java:36)
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$3.run(DefaultObjectConfigurationAction.java:80)
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:131)
        at org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:37)
        at org.gradle.api.Project$apply$0.call(Unknown Source)
        at org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.groovy:34)
        at org.gradle.api.Script$apply$0.callCurrent(Unknown Source)
        at build_an60zvzl0fynwc5b0jufsy5gw.run(E:\src\p\gradle-editbin-plugin\build.gradle:19)
        at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:52)
        ... 42 more
Caused by: groovy.lang.MissingPropertyException: No such property: COMPILE_ONLY_CONFIGURATION_NAME for class: org.gradle.api.plugins.JavaPlugin
        at nu.studer.gradle.plugindev.PluginDevPlugin.apply(PluginDevPlugin.groovy:106)
        at nu.studer.gradle.plugindev.PluginDevPlugin.apply(PluginDevPlugin.groovy)
        at org.gradle.api.internal.plugins.DefaultPluginContainer.providePlugin(DefaultPluginContainer.java:188)
        at org.gradle.api.internal.plugins.DefaultPluginContainer.addPluginInternal(DefaultPluginContainer.java:137)
        at org.gradle.api.internal.plugins.DefaultPluginContainer.apply(DefaultPluginContainer.java:103)
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyPlugin(DefaultObjectConfigurationAction.java:115)
        ... 51 more

But this didn't happen with 1.0.3

The generated pom file should contain a issueManagement section (see Section Issue Management).

For github the defaults would be

issueManagement {
    system 'github'
    url extension.projectIssuesUrl
}

dryRun property is set to false. When running on CI server it might be good to have dry runs.

It doesn't look like this plugin currently applies the java-gradle-plugin, but it seems like that would probably be a good idea.

http://www.gradle.org/docs/current/userguide/javaGradle_plugin.html

latest bintray plugin has changed the namespace of the BintrayUploadTask to
https://github.com/bintray/gradle-bintray-plugin/blob/3fe02dfdae3e807afba57e0140a0d4c2424674e1/src/main/groovy/com/jfrog/bintray/gradle/tasks/BintrayUploadTask.groovy

Could not upload to 'myfile.jar': HTTP/1.1 401 Unauthorized

I am sure that the username and api key are well spelled. Any ideas why is this happen?

Especially if the Artifactory plugin is added to handle the publishing of SNAPSHOTS, it would be great to introduce a standard way to handle the bintray credentials.

My suggestion would be to look for a bintrayUser and bintrayApiKey property (most likely set as you suggest in the user's gradle.properties), and fall back to using environment variables BINTRAY_USER and BINTRAY_APIKEY which are usually easier to set up on CI servers / services like Travis.