On 08/05/2013, at 7:39 PM, Matt Khan <matt.k...@db.com> wrote: > 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
Can you give us a few more details about what you need to do here? > > 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) The whole concept of bundling is something we want to bake into our dependency management. When publishing a bundle, we need to transform the meta-data to reflect that fact the bundle no longer requires a version of any bundled dependencies to be provided, but it does still require some version of the remaining dependencies to be provided. We also need to change the meta-data to declare that the bundle includes both A and B. This information can then be considered when detecting and resolving conflicts. For example, if your bundle above is included in the result, then this conflicts with any other standalone version of A or B and any other bundle that includes A or B. There are heaps of examples of where bundling is used: fat jars, WARs and EARs, native binaries, OSGi bundles. > > 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. -- 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
