Classification: For internal use only >> 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? Our approach to consuming native libraries is described on the forum - http://forums.gradle.org/gradle/topics/handling_native_dependencies_across_different_platforms When it comes to building them, we currently build each binary separately and append the platform/arch to the artifact name so we end up with n GAVs (and actually n different versions due to the way our build calculates version numbers on each release).
We do something similar with configuration bundles. Our build is based on a strict separation between libraries (mostly code, things that are invariant to the environment they run in) and applications. Applications are a particular organization of configuration files that are environment specific. They are "built" for a particular environment and published to a configuration repository (an action which is controlled by our release management group), effectively a release is the creation of a new version of a particular stack (where a stack is 1-n platforms and a platform is 1-n applications and an application is composed of config + 1-n libraries). The core requirement here is the ability to run 1 build to produce n variants with a particular naming scheme based on where the variant is going to go. Cheers Matt From: Adam Murdoch [mailto:adam.murd...@gradleware.com] Sent: 09 May 2013 00:19 To: dev@gradle.codehaus.org Subject: Re: [gradle-dev] New maven publishing featureset [I] On 08/05/2013, at 7:39 PM, Matt Khan <matt.k...@db.com<mailto: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<http://gmail.com>] Sent: 08 May 2013 02:35 To: dev@gradle.codehaus.org<mailto: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> <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 --- 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.
