I think that depends on the use cases you believe to be normal...
Personally I only ever used it to add additional metadata to the POM.
I think this is a pretty normal use case, certainly for OSS projects.
Although I will say that the old DSL for doing that was much cleaner:
{
organization {
name 'Hibernate.org'
url 'http://hibernate.org'
}
issueManagement {
system 'jira'
url 'https://hibernate.atlassian.net/browse/HHH'
}
...
}
versus now:
{
def root = asNode();
def org = root.appendNode( 'organization' )
org.appendNode( 'name', 'Hibernate.org' )
org.appendNode( 'url', 'http://hibernate.org' )
def jira = root.appendNode( 'issueManagement' )
jira.appendNode( 'system', 'jira' )
jira.appendNode( 'url',
'https://hibernate.atlassian.net/browse/HHH' )
...
}
For the appending use case, I think access to just the XML "works". I
would prefer to see a better DSL for appending content, but thats just
me perhaps.
I cannot speak to any of the other use cases (remapping dependencies,
etc). I am only touching the dependencies now because of this scope
issue.
On Tue 07 May 2013 08:07:52 AM CDT, Hans Dockter wrote:
On Tue, May 7, 2013 at 2: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 agree although people should be able to choose I guess.
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. It is not clear from the
documentation how one can use the pom.withXml approach to
over-write values already in the POM from Gradle. I tried what
seemed logical (though granted, brute force) to me:
pom.withXml {
asNode()...
final String runtimeScope = '<scope>runtime</scope>';
final int replacementLength = runtimeScope.length();
final String compileScope = '<scope>compile</scope>';
final StringBuilder stringBuilder = asString();
int index = stringBuilder.indexOf( runtimeScope );
while ( index > -1 ) {
stringBuilder.replace( index, index+replacementLength,
compileScope );
index = stringBuilder.indexOf( runtimeScope );
}
}
It works (though quite ugly imo).
BTW: With the wonderful old publication API you had access to the
Maven project object directly ;). Do we think that this is not really
necessary and having access to the XML representation is good enough?
Hans
On 05/05/2013 03:13 PM, Adam Murdoch wrote:
On 03/05/2013, at 11:28 PM, Steve Ebersole <st...@hibernate.org
<mailto:st...@hibernate.org>> wrote:
After updating Hibernate to use the new publishing stuff we now
see all dependencies in the generated POM as 'runtime' whereas
previously the generated pom used 'compile'. Is that expected?
If so, I understand the logic behind using 'runtime' instead
except for the fact of the footnote on Maven's own dependency
primer[1[, I quote:
" it is intended that this should be runtime scope instead, so
that all compile dependencies must be explicitly listed -
however, there is the case where the library you depend on
extends a class from another library, forcing you to have
available at compile time. For this reason, compile time
dependencies remain as compile scope even when they are transitive."
Given that this is generating something to explicitly plug in to
Maven builds, I think 'compile' should still have been the choice.
The problem is that both choices are wrong. Some of the things
you compile against form part of your API, and should be made
available to a consumer when they are compiling against your
component. And some of the things you compile against form part
of your private implementation, and should not be made available
to a consumer at compile time.
Our plan is to add a mechanism that allows you to declare the
dependencies of your API. These will be made available to both
you and your consumers at compile time. When you're publishing to
Maven, these will end up in the `compile` scope. Everything else
will end up in the `runtime` scope.
There will also be a DSL on the publication object for messing
with the scopes, if you don't like whatever the defaults happen
to be. We've done this for the artefacts of the publication, but
haven't tackled it for the scopes and dependencies yet.
[1]
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
On Tue 16 Apr 2013 06:11:54 PM CDT, Steve Ebersole wrote:
That plugin code on master works. I just integrated it into
Hibernate
build and updated Hibernate to use this Publication DSL and was
able
to perform a publish!
In terms of designing a generic solution, not sure how much help I
will be. Gradle has moved on dramatically from the last time I was
"in the code". But I do think the
org.hibernate.build.gradle.publish.auth.maven.Credentials/CredentialsProvider/CredentialsProviderRegistry
stuff is pretty generic solution for managing credentials.
But I'd
not really be sure the best way to tie it in to Gradle to apply
credentials to "things" that need authentication.
Anyway, I'll be pushing (ahem, *publishing*) a 2.0.0 release of
this
plugin later today that will support its feature set against the
Publication DSL.
Thanks to Luke, Daz and Adam for all the help getting me on the
right
path there!
On Tue 16 Apr 2013 04:19:41 PM CDT, Adam Murdoch wrote:
On 16/04/2013, at 10:41 PM, Steve Ebersole
<st...@hibernate.org <mailto:st...@hibernate.org>
<mailto:st...@hibernate.org>> wrote:
Maybe an even better question...
This upload credential plugin is really in my opinion a work
around
for the fact that Gradle has no built-in support for externalized
credential declaration. As the developer of an OSS project,
it is
utterly impossible for me to put my username/password
directly into
my build scripts.
While forcing each project to define username/password project
variables and do the whole hasProperty checking stuff
"works", it is
(again in my opinion) not ideal.
Absolutely. I agree with this.
So... Is there any externalized credential management in
place or
planned? Pretty sure there is nothing in place as of now. Is
anything of the sort planned?
It's planned. Just a matter of finding the time. As always, if
someone
from the community is interested in helping out with this,
we'd really
appreciate it. One place to start would be to get Steve's plugin
merged into Gradle and we can evolve it from there.
On Tue 16 Apr 2013 07:30:57 AM CDT, Steve Ebersole wrote:
Sigh. Daz mentioned that credentials get copied from the
upload repo
definitions.
Look, I just want to know what I need to do in order to
apply a set of
credentials to a maven repository to be used for upload. Is
that
possible? If so how? Been asking that for almost 2 weeks
now ;)
P.S. I am also not seeing a way to define a split between
"production" and "snapshot" repo urls for publishing the way
we used
to be able to do with
uploadArchives.repositories.mavenDeployer. Is
that also no longer supported? If not, I guess that is
something I
need to handle "manually" in the script to conditionally set
the url?
On Tue 16 Apr 2013 07:25:04 AM CDT, Luke Daley wrote:
On 16/04/2013, at 1:19 PM, Steve Ebersole
<st...@hibernate.org <mailto:st...@hibernate.org>
<mailto:st...@hibernate.org>> wrote:
So am I understanding that the only way to get this (applying
"publish repo" credentials) is to add credentials to a
MavenArtifactRepository?
What I am not understanding is what to do in the
(seemingly normal)
use case where the publish repo is not an artifact
(download) repo.
The set of consumption repositories is a different set to the
publication repositories.
On Sat 06 Apr 2013 08:47:15 PM CDT, Daz DeBoer wrote:
If you didn't find it, the DSL docs for the Publishing
Extension
and
related model elements might be useful:
http://www.gradle.org/docs/nightly/dsl/org.gradle.api.publish.PublishingExtension.html.
For some classes (eg PublicationContainer) the javadoc is
probably
more useful than the DSL reference (click the "API
Documentation"
link
from the DSL page).
Other than that, the best way to understand what's going
on is to
consult the sources.
One thing that is not well documented is the new,
experimental
support
for deferred configuration that is leveraged by the
PublishingExtension. This extension is a {@link
org.gradle.api.plugins.DeferredConfigurable} model
element, meaning
that extension will not be configured until it is first
accessed in
the build. So any configuration blocks are not executed until
either:
1. The project is about to execute
or
2. The publishing extension is referenced as an instance, as
opposed
to a configuration closure. ie:
publishing.publications { ... }
publishing.repositories.maven { ... }
You can read the rationale behind deferred configuration
in the
design
doc:
https://github.com/gradle/gradle/blob/master/design-docs/lazy-configuration.md.
We're interested in feedback and ideas of how we can make
this
clearer.
If you were not aware of this, it's quite possible that
you were
causing the publishing extension to be configured early
which could
lead to hard-to-understand behaviour.
I'm happy to help get things working, do you have some
code to
share?
cheers
Daz
On 5 April 2013 15:47, Steve Ebersole
<st...@hibernate.org <mailto:st...@hibernate.org>
<mailto:st...@hibernate.org>
<mailto:st...@hibernate.org>> wrote:
I realize that this is an incubating feature, but given the
current documentation I am really not able to get this
to work.
It works if I have something simple (no pom
customization, no
snapshot/releases repository distinction, etc). Is
there some
better documentation I shuld look at rather than
http://www.gradle.org/docs/__current/userguide/publishing___maven.html
<http://www.gradle.org/docs/current/userguide/publishing_maven.html>
and the dsl docs for MavenPom/MavenPublication?
On Fri 05 Apr 2013 02:50:42 PM CDT, Steve Ebersole wrote:
Hey Daz,
The "upload auth" plugin[1] reads credentials from
maven
settings.xml
etc and applies them to any same-named repositories
referenced
in a
Gradle build through an Upload task. So, as I
understand
it, that
would not apply here.
Applying the credentials to the resolution repos
would be a
good thing
too.
[1]
https://github.com/sebersole/__gradle-upload-auth-plugin
<https://github.com/sebersole/gradle-upload-auth-plugin>
On Fri 05 Apr 2013 02:21:07 PM CDT, Daz DeBoer wrote:
On 5 April 2013 07:16, Steve Ebersole
<st...@hibernate.org <mailto:st...@hibernate.org>
<mailto:st...@hibernate.org>
<mailto:st...@hibernate.org
<mailto:st...@hibernate.org>>>
wrote:
I am just upgrading Hibernate to Gradle 1.5
and am
reading about
the new publications stuff. I really like the
new DSL
much, much
better.
I did have one question though that was not
addressed
in the docs.
For the old style of "uploading" I had
developed a
plugin that
provided authorization based on users local
Maven
install. From
my recollection the intent in the new maven
publication code was
to provide this behavior out-of-the-box.
So I am
curious if that
code ever made it into the
MavenArtifactRepository/____MavenPublication
code. Or
do I need to
update my gradle-upload-auth-plugin to handle
this new
API?
The new Publication support copies the
credentials from
the
MavenArtifactRepository (see the poorly named
org.gradle.api.publish.maven.__internal.publisher.__MavenDeployerConfigurer).
So any plugin code that you use to add
credentials to
maven
repositories used for resolution should also
work for
publication.
--
Darrell (Daz) DeBoer
Principal Engineer, Gradleware
http://www.gradleware.com <http://www.gradleware.com/>
Join us at the Gradle Summit 2013, June 13th
and 14th in
Santa Clara,
CA: http://www.gradlesummit.com
<http://www.gradlesummit.com/>
--
Darrell (Daz) DeBoer
Principal Engineer, Gradleware
http://www.gradleware.com <http://www.gradleware.com/>
Join us at the Gradle Summit 2013, June 13th and 14th in
Santa
Clara,
CA: http://www.gradlesummit.com
<http://www.gradlesummit.com/>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
