Skip to content

Conversation

JLLeitschuh
Copy link
Contributor

@JLLeitschuh JLLeitschuh commented Oct 17, 2018

Before this change, there was no easy way to rely upon the output
of the AbstractArchiveTask without using dependsOn.

Related: https://github.com/gradle/gradle-native/issues/893

Signed-off-by: Jonathan Leitschuh [email protected]

Contributor Checklist

  • Review Contribution Guidelines
  • Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
  • Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
  • Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
  • Provide unit tests (under <subproject>/src/test) to verify logic
  • Update User Guide, DSL Reference, and Javadoc for public-facing changes
  • Ensure that tests pass locally: ./gradlew <changed-subproject>:check

Gradle Core Team Checklist

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation
  • Recognize contributor in release notes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this TODO be removed now?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I think so

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't really want this to show up in the generated docs, so I left it using the implNote tag, hope that's okay.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it looks like the version of javadoc we're using doesn't like @implNote. You could also put this as a comment inside the method too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If anyone has a better name for this, let me know.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getExtension is the best name, but it's already taken. Maybe getArchiveExtension?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getExtension is already taken, I'll use getArchiveExtension.

@JLLeitschuh JLLeitschuh force-pushed the provider-api-on-abstract-archive-task branch from e99e9a3 to 9b4c427 Compare October 17, 2018 23:21
Copy link
Member

@big-guy big-guy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking the time on this. I've left some comments.

The test failures are due to the convention mapping no longer working from BasePlugin. We'd need to change

Callable<File> destinationDir;
if (task instanceof Jar) {
destinationDir = new Callable<File>() {
public File call() throws Exception {
return pluginConvention.getLibsDir();
}
};
} else {
destinationDir = new Callable<File>() {
public File call() throws Exception {
return pluginConvention.getDistsDir();
}
};
}
taskConventionMapping.map("destinationDir", destinationDir);

to something like:

if (task instanceof Jar) {
   task.getDestinationDirectory().set(project.getLayout().getBuildDirectory().dir(pluginConvention.getDistsDirName()));
} else {
   task.getDestinationDirectory().set(project.getLayout().getBuildDirectory().dir(pluginConvention.getLibsDirName()));
}

And deprecate the BasePluginConvention.get*Dirs methods.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I think so

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you make this a regular default constructor?

Copy link
Contributor Author

@JLLeitschuh JLLeitschuh Oct 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.
It just seemed clearer to have this logic as close to where the field was declared as possible.
Happy to change it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make this final

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make this final

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing all of these!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think our checks will want @since tags in the javadoc for all new methods.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you also add destinationDirectory and the new extension method below to subprojects/docs/src/docs/dsl/org.gradle.api.tasks.bundling.AbstractArchiveTask.xml as properties?

Copy link
Contributor Author

@JLLeitschuh JLLeitschuh Oct 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. What is subprojects/docs/src/docs/dsl/org.gradle.api.tasks.bundling.AbstractArchiveTask.xml?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, I think.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @marcphilipp just added this.

I think the behavior with the Provider/Property is that the error will be about an unset provider?

Copy link
Contributor Author

@JLLeitschuh JLLeitschuh Oct 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's still an exception thrown, it's a different exception now though and it happens at a different phase in the build.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getExtension is the best name, but it's already taken. Maybe getArchiveExtension?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it looks like the version of javadoc we're using doesn't like @implNote. You could also put this as a comment inside the method too.

Before this change, there was no easy way to rely upon the output
of the AbstractArchiveTask without using dependsOn.

Related: https://github.com/gradle/gradle-native/issues/893

Signed-off-by: Jonathan Leitschuh <[email protected]>
}
};
}
task.getDestinationDirectory().set(project.getLayout().getBuildDirectory().dir(project.provider(destinationDir)));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @big-guy for working on this with me!

@JLLeitschuh JLLeitschuh force-pushed the provider-api-on-abstract-archive-task branch from 4d68c55 to a6abefd Compare October 24, 2018 22:09
Signed-off-by: Jonathan Leitschuh <[email protected]>
@JLLeitschuh JLLeitschuh force-pushed the provider-api-on-abstract-archive-task branch from c92f28f to 666240a Compare October 25, 2018 15:54
@JLLeitschuh
Copy link
Contributor Author

Supposedly I introduced some binary incompatibility?? @big-guy can you tell me what that means so I can try and fix it?

@big-guy
Copy link
Member

big-guy commented Oct 25, 2018

Thanks @JLLeitschuh, I merged this locally, fixed a couple of things and pushed it to master. This'll be in 5.1

@big-guy big-guy closed this Oct 25, 2018
@JLLeitschuh
Copy link
Contributor Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants