On 29/09/2010, at 8:39 PM, Joern Huxhorn wrote: > Hi Adam, > thank you very much for your reply! > > On 29.09.2010, at 12:16, Adam Murdoch wrote: > >> >> On 29/09/2010, at 12:26 AM, Joern Huxhorn wrote: >> >>> Hi everyone. >>> >>> I'm writing a gradle plugin that provides the functionality of the >>> maven-gpg-plugin and I've now reached a point where I don't know how to >>> solve the remaining issues... >>> >>> You can find the project here: >>> http://github.com/huxi/huxi-gradle-plugins >>> >>> The current version has several issues: >>> - The created signature files are not added to the set of artifacts, >>> meaning they are not deployed to the maven repository. :( >> >> >> Have a look at this email thread from some details: >> http://gradle.markmail.org/thread/pgdhc7hrfn2e27o5 >> > > I found this thread already but I couldn't find any info on > DefaultPublishArtifact in > http://www.gradle.org/latest/docs/javadoc/index.html - so I assumed that it > was removed in the meantime. > Where can I find docs/source of that class?
It's an internal class, so it does not appear in the API documentation. You can find the source in the Gradle source tree: http://github.com/gradle/gradle/blob/master/subprojects/gradle-core/src/main/groovy/org/gradle/api/internal/artifacts/publish/DefaultPublishArtifact.java As discussed in the thread, we will improve the dependency dsl after the 0.9 release, so that you don't have to use internal classes. > >> >>> - If no password is given using either the System property 'pgp.password' >>> or >>> password in the convention above (which would actually both be a rather >>> bad >>> idea concerning security) then the plugin asks once for password entry >>> using >>> console.readPassword. This requires Java 6. >>> - The text output 'Enter PGP-Password: ' is mixed up with the '> Building > >>> :foo:uploadArchives' text. >>> The password is prompted for after the later one >> >> >> There is a JIRA issue for this: http://jira.codehaus.org/browse/GRADLE-1147 >> > > Ok, nice. Then I can tick this off as "not my issue" :) > >> >>> . >>> - This plugin currently attaches itself to uploadArtifact.doFirst - which >>> is probably a bad idea. >> >> It might be better to add a custom task to do the signing, which >> uploadArtifacts would depend on. This would allow you to, for example, make >> use of incremental build for signing. It would also allow someone to reuse >> the signing task without necessarily doing an upload. Or to sign multiple >> configurations. >> >> >>> - The configuration used for signing is always 'default' >> >> Having a custom task would give you a place to add, say, a property that >> specifies which configuration to sign. >> > > Ok, I'll take a look at your suggestions. Thanks a lot! > > Would there be an interest to include this functionality into the basic > Gradle distribution? > I'd happily donate it under whatever license you'd like, assuming that it > reaches a certain level of quality of course. We're planing on busting up the distribution so that most (or maybe all) plugins are downloaded on demand from a central plugin repository somewhere. This repository will be open for pretty much anyone to contribute plugins to. The idea is that a plugin might start off as a 'contributed' plugin and over time become an 'official' plugin. The only real difference between the 2 would be that 'official' plugins would have some quality criteria that they must meet (whatever that might be). Apart from that, you'd use the plugins exactly the same way in your build script. > > One other thing hit me, btw: > It seems that it's not possible to use Grapes in Gradle plugins. Will this > change or was this done on purpose? It wasn't done on purpose. If you'd like to use Grapes in your plugin, could you add a JIRA issue for it? -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
