Classification: For internal use only FWIW the use cases I have for this, outside the usual metadata munging, are;
https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md#i-want-my-consumers-to-use-the-same-dependency-versions-as-i-used-to-build-and-test-my-artifacts - I do this via configuration.resolvedConfiguration.resolvedArtifacts at present https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md#i-want-to-customise-a-publication-based-on-its-destination - for both environment specific configuration bundles and native libraries https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md#i-want-to-publish-multiple-ivy-or-maven-modules-from-my-project - the same shared test module as Steve describes (which we have also broken out to a separate subproject for now) I also have a variation on the last one as our build provides the ability to produce a bundled jar with a correct set of dependencies, i.e. if we have A -> B -> C and we configure A to also produce a single jar containing {A,B} then the published pom will have dependency on C (i.e. it will be {A,B} -> C) Cheers Matt -----Original Message----- From: Steve Ebersole [mailto:steven.ebers...@gmail.com] Sent: 08 May 2013 02:35 To: dev@gradle.codehaus.org Cc: Adam Murdoch Subject: Re: [gradle-dev] New maven publishing featureset Like I said, I think its a great improvement. Y'all did great with this so far. Yes there are some things missing, but only 2 are really hitting me so far and both are on the "design plan" for publications (https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md) already: 1) this runtime versus compile scope in the generated POM issue. 2) not being able to define multiple artifacts/publications for a project. I am not sure how common the second requirement is across projects, but wanted to explain it. Its sort of a cross between the points in https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md#i-want-to-publish-multiple-ivy-or-maven-modules-from-my-project and https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md#i-want-to-customise-the-ivy-or-maven-meta-data-for-a-publication. Basically I have a set of "test support" classes that I currently split out into a separate project (hibernate-testing) in order to share it between modules in the project and to let others use it easily for testing Hibernate. Ideally, I'd move these classes into another module (hibernate-core) in the project and then (a) be able to refer to it from other modules and (b) be able to publish it using the same artifactId (hibernate-testing). (a) used to be doable by using a special configuration, but not sure how I can tie that in with the new publication feature. On Tue 07 May 2013 06:09:25 PM CDT, Adam Murdoch wrote: > > On 07/05/2013, at 10:50 PM, Steve Ebersole <steven.ebers...@gmail.com > <mailto:steven.ebers...@gmail.com>> wrote: > >> I agree that neither is correct and that this is yet another >> manifestation of bad Maven design. >> >> But... >> >> This is a POM. It is specifically a Maven artifact. In my opinion >> this needs to follow Maven conventions. That seems to be the way you >> are leaning as well given the plan you are describing below. >> >> I'd really like to stick with the Publication DSL. It is much >> simpler/better. I updated my plugins to work with it. And I'd like >> to keep testing it for y'all. > > Thanks for doing this. This new DSL is so long overdue (you know this > as much as anyone) and it's nice to make a start on it, but we > certainly don't think it's 'finished' yet. Your feedback is really > useful for driving what we tackle next with the DSL: what's missing, > what's confusing, and so on. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, > Consulting http://www.gradleware.com > > Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, > CA: http://www.gradlesummit.com > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
