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. 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. > > I'm looking at what Usage.getArtifacts() returns and I see that everything > extends AbstractPublishArtifact instead of just implementing > PublishArtifact. > > If I don't extend AbstractPublishArtifact, will things not work? > Anything that implements PublishArtifact should work. The relevant code is found in DefaultMavenPublication.from(SoftwareComponent) and MavenArtifactNotationParserFactory. > > > On Tue, Jul 30, 2013 at 12:58 PM, Xavier Ducrohet <x...@google.com> wrote: > >> >> What's the ETA for the feature to be stable and those API to move out of >> internal? >> > The new publishing DSL hasn't been getting much focus lately, so there's no ETA for this. The mapping of Usage to pom.xml/ivy.xml is very simplistic at this time, and the exact API is likely to change. But I'm pretty sure the fundamental concepts will remain. Adding Android to the mix of SoftwareComponents would be a nice way to drive out any required changes to the API. -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com
