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
