On 31/07/2013, at 7:47 AM, Daz DeBoer <darrell.deb...@gradleware.com> wrote:
> > On 30 July 2013 15:12, Xavier Ducrohet <x...@google.com> wrote: > Looking at the code of DefaultMavenPublication I see that SoftwareComponent > gets casted always into SoftwareComponentInternal, so I guess I have to use > it anyway. > > Yep, any public Gradle API that is annotated with @HasInternalProtocol has a > matching internal interface that is required for Gradle to use an instance. > This pattern is used for types that are designed for use, but have not been > designed with user-implementation in mind. Just to add: sometimes this is because we don't intend that there will be user implementations, such as `Project`, and sometimes this is because we aren't quite ready to open the interface up for user implementation. For SoftwareComponent, the intention is very much that there will be custom implementations. So, at some point the internal interface will go away or there will be some way to mix the internal stuff in. For example, `Task` has an internal interface but you can easily implement this by extending `DefaultTask`. > > In the Android case, implementing SoftwareComponent/SoftwareComponentInternal > is likely the right way to go: the alternative would be to drive the > MavenPublication/IvyPublication directly, but this will be a lot less > convenient. The plan is that you should describe the things you produce using SoftwareComponent, and that Gradle takes care of the mapping to Ivy or Maven (or whatever other repositories that Gradle ends up supporting). We'll probably retro-fit support for SoftwareComponent to the old publishing DSL as well, so that you describe the things you produce once via SoftwareComponent and there's a consistent mapping to Ivy or Maven regardless of whether the build is using the new or old publishing DSLs. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
