Skip to content
This repository has been archived by the owner on Oct 5, 2018. It is now read-only.

release-opinion error with maven-publishing plugin #252

Closed
rodney757 opened this issue Apr 1, 2017 · 3 comments
Closed

release-opinion error with maven-publishing plugin #252

rodney757 opened this issue Apr 1, 2017 · 3 comments
Labels
Milestone

Comments

@rodney757
Copy link

rodney757 commented Apr 1, 2017

I am trying to use the release-opinion plugin along with the maven-publishing plugin in a multi-project gradle build. The problem is that gradle is complaining about the publishing extension already being evaluated.

If I use the release-base plugin, this error goes away.

I was able to reproduce the bug here test-project.zip

if you go into the test directory and run the command gw tasks --include-build ../test-plugin you will experience the issue

If I apply the maven-publish plugin directly above the publishing closure in each build.gradle, it works correctly. If I apply the maven-publish plugin in the TestPlugin for each project or at the top of the build.gradle files, I get the error

@ajoberstar
Copy link
Owner

It seems tied to the evaluationDependentOnChildren() removing that resolved the issue for me (in your test project).

A couple other notes (they don't seem related to your issue):

  • You shouldn't set an explicit version if you are using the release plugin, since it will infer for you
  • The release plugin should only be applied to the root project, since it copies it's inferred version into all subprojects

@rodney757
Copy link
Author

right, but I need the evaluationDependsOnChildren()

I figured out what the issue is. It is related to this.

If I reimplement the RebuildVersionStrategy class and comment out def props = project.properties.keySet().find { it.startsWith('release.') }, it works as expected.

Using something like def props = project.hasProperty(SemVerStrategy.SCOPE_PROP) || project.hasProperty(SemVerStrategy.STAGE_PROP) will work around the gradle issue

Regarding the explicit version, that was a typo in the test project. Thanks
My sub projects are more like composite builds. They are dynamically added if they are present on the users computer. Specific tasks (release being 1 of them) are only allowed to run for the root project.

@ajoberstar ajoberstar added the bug label Apr 1, 2017
@ajoberstar
Copy link
Owner

That makes sense marking as a bug.

@ajoberstar ajoberstar modified the milestone: 1.7.1 Apr 9, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants