G'day Sorry to come late to the party. I'm responding to the original email that kicked off this thread:
On 15 November 2012 22:57, Adam Murdoch <[email protected]> wrote: > 1. Infer the 'main' component and publish this, as we do now. To publish > an additional component, you'd add it to the appropriate publication: > I think we all agree that we don't want this magic. 2. Don't publish anything. You need to declare it, perhaps something like: > It's nice if things "just work" in most cases. In this case, do you mean "Don't publish anything by default, ever", or "Don't publish anything when there are multiple main artifacts"? For the latter case, I would suggest that publishing without explicitly declaring which artifact(s) is a failure situation? So basically, if there is one 'main' publication, just publish it. If there are more, ask the user for more information. So this could work by leaving the plugins as-is, but introducing a DSL for declaring which artifacts to publish. Default would be to publish 1 main publication if available, or fail for multiple main artifacts. > 3. Split the 'java' plugin into a Java language plugin that knows how to > compile and test Java based stuff, and a Java library plugin that knows how > to publish a Java library for use outside the project. > An alternative would be to do the split by introducing a 'java-lang' plugin that adds the language support (all of the current 'java' plugin), leaving the 'java' plugin to mean "I'm building a jar". The 'war' plugin would apply the 'java-lang' plugin. This means that applying 'war' on it's own would publish the war file, and applying 'java' on it's own would publish the jar. Applying both would require more configuration. Just an idea. The benefits would be that the 'war' and 'java' plugins would continue to publish the same as they currently do. They would not need to add "apply plugin: 'java-library'" to get their jar published. The downside is that effectively renaming the current 'java' plugin to 'java-lang', and adding a new 'java' plugin to extend this, is not back-compatible? We'd need to introduce 'groovy-lang' and 'scala-lang' too, I guess. > This does not publish anything: > > apply plugin: 'java' > > This would publish the Java library as a jar + meta-data: > > apply plugin: 'java' > apply plugin: 'java-library' > Would this be more like 'jvm-library'? What if you were compiling groovy or scala? Are they different library plugins for different languages? Or is 'java' the language and 'jvm-library' the component type'? Are plugins the right way to compose this sort of behaviour? I guess I mean: are we thinking that over time builds will start to apply lots of smaller plugins to get all of the support they require? Is there a lower-level concept that opinionated plugins could be composed of, rather than other plugins? Just curious. > As far as what should be available via a project dependency, it feels like > we should make every component available, assuming components have some > kind of identity so that they can be referenced from another project. So, > perhaps we would add an implicit local publication for each component. > > I think the issue of 'choosing what to publish' is only problematic so that things don't end up unexpectedly in a remote repository. For project dependencies I tend to agree that we should make all possible publications available, "published" or not. -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com
