Make ExtraArchivePlugin not use afterEvaluate about gradle-nexus-plugin HOT 8 CLOSED

The reason they are defined in afterEvaluate is that they creation is derived of the properties set by the extension ExtraArchivePluginExtension. When you copy/pasted the code you probably didn't copy that piece.

from gradle-nexus-plugin.

I'm struggling greatly to publish gradle plugins to both nexus and bintray. Right now, both plugindev and this plugin define sourcesJar tasks, and I can't get either to abdicate in favour of the other, nor can I get a hook in between the two to undefine one and define the other. :-( Can you help at all?

from gradle-nexus-plugin.

The reason I started to break out the ExtraArchivesPlugin is that the functionality shouldn't actually be part of the Nexus plugin. The user should actively decide to apply the plugin. There are various reasons why I didn't follow through:

1. I don't directly publish to Maven Central anymore and therefore don't use this plugin anymore myself. There's little incentive to improve the functionality of this plugin if I don't use it.
2. Having two distinct plugins is a breaking change and needs to be understood by the end user. I simply haven't finished this work though it would be desirable. The ExtraArchivesPlugin would become a completely separate plugin.

What I am doing is to directly publish to Bintray and then I sync to Maven Central from Bintray (see Bintray documentation). Far more convenient than having to use the Nexus UI. In turn this means that you don't actually have to use the Nexus plugin.

from gradle-nexus-plugin.

My libraries tend to have a core, then gradle, ant and maven implementations. This leaves me writing a multi-module gradle project where all the subprojects publish to central except the gradle integration, which works out very odd. I guess an overall move to publish via bintray rather than sonatype could also work. There's no good documentation for knowing whether, having published via sonatype, I can switch to publishing via bintray, and have it "take over"

from gradle-nexus-plugin.

For publishing to Bintray you might just want to check out the build file of this project. It uses the Bintray plugin and simply sets up the JAR tasks itself. Yes, it does require some copy/pasting but you'd have full control as long as my plugin is not broken up by functionality.

I guess an overall move to publish via bintray rather than sonatype could also work. There's no good documentation for knowing whether, having published via sonatype, I can switch to publishing via bintray, and have it "take over"

I'd ask the JFrog guys about this for more info. But from my experience this worked just fine. I did the same thing.

from gradle-nexus-plugin.

Thank you, I'm talking to JFrog now. Just in case you have any insight, I'm also stuck on this, which I did also pull from this nexus plugin:

http://discuss.gradle.org/t/magically-configuring-a-mavenpom-object/9143

from gradle-nexus-plugin.

Can we close this issue?

from gradle-nexus-plugin.

thank you

from gradle-nexus-plugin.