On 08/05/2013, at 11:35 AM, Steve Ebersole <steven.ebers...@gmail.com> wrote:
> 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. Something we want to do is add support for test fixtures as a first-class concept. It's a common pattern for a library component to produce some code that is to be used at test time to exercise or mock (or whatever) the production code, and we want to model this. There would be some convention regarding where to find the test fixtures for a project, plus some convention for how to share these between projects (including publishing them), and some convention about where to make the test fixtures visible in the consumer (eg if module `a` is required at compile time, then make its test fixtures, if any, visible at test compile and runtime). In the shorter-term (and as a step towards this), there will be some way to define additional 'usages' for a module, which you could use to manually wire this together. In practical terms, it's more or less equivalent to defining a special configuration. The test fixture jar(s) and meta-data would travel with the production jar(s) and meta-data. The other approach for sharing test fixtures would be to map the test fixtures for the project to a second module. Possibly at some point we'll support both patterns for publishing them. One use case where it makes some sense to publish multiple modules for a project is where the project produces multiple mutually-incompatible variants of the same thing. For example, a Groovy library that is built against both Groovy 1.8 and Groovy 2.0. Or a native shared library build for windows and linux. > > > 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 >> -- 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
