Hi,
deployment to maven repositories works in trunk. You can find an
example in samples/pomGeneration project. Right now it works like this:
A MavenUploadResolver can upload to multiple repositories. If the
version is a Maven SNAPSHOT version, this is supported as well (the
Ant Maven tasks care for this). We delegate to the Maven Ant tasks to
make all this happen. The Maven Ant tasks only provide http and
filesystem support out of the box. For the support of other protocols
you need to register providers. Right now you can do this with Gradle
like the following:
dependencies {
addConfiguration('mavenUpload')
mavenUpload "org.maven.wagon:wagon-ftp:1.0-beta-2" // beta-3
and beta-4 did not work and have caused an exception
}
uploadLibs {
uploadResolvers.add(new MavenUploadResolver()) {
name = 'maven'
addProtocolProviders(dependencies.resolve("mavenUpload"))
addRemoteRepository(new RemoteRepository(url: "ftp://
ftp.something.org", authentication: new Authentication(username: 'x',
password: 'y'))
}
}
All in all I'm very happy how the integration of the Ant Maven tasks
has worked out. I only had to do a little bit of tweaking to make
things work. And the payoff is: No reverse engineering of all this
metadata.xml manipulation which is not specified anywhere. And what
is for example the difference in behavior when deploying to distinct
snapshot repositories. The list goes on. We don't have to care and to
know the details. I'm really happy about this.
The current way you have to do things wit Gradle is not that
convenient yet. I think we can improve this in two areas:
1.) wagon jars retrieval:
I think it would be a general nice feature to have something like:
dependencies.resolve("org:name:version:3.0")
dependencies.resolve("org:name:version:3.0", transitive: true/false)
Those methods would return a list of files.
The MavenUploadResolver would then have an instance of the dependency
manager. It would also have properties ftpProvider, sshProvider, ...
The default values for this properties are "org.maven.wagon:wagon-ftp:
1.0-beta-2", ...
Then we would figure out the protocols and download the dependencies
with dependencies.resolver(ftpProvider) on demand (and register them
with the internal Plexus Container as we do now).
2.) API
We should offer more convenience for configuring the
MaveUploadResolver. For example we could offer something like:
uploadResolvers.addMavenUploadResolver {
addRemoteRepository(url: "ftp://ftp.something.org";, authentication:
[username: 'x', password: 'y'])
}
RemoteRepository and Authentication are domain objects provided by
the Maven Ant tasks. See also http://maven.apache.org/ant-tasks/
usage.html (section: Installing and Deploying Your Own Artifacts to a
Repository)
The DependencyManager has now a maven property to customize the Maven
pom generation. But for 'normal' Java projects this should work out
of the box (for current limitations see below). Here are some more
details about pom generation (from my posting to the ivy list):
I have submitted code into the Gradle trunk for auto generating a
Maven pom descriptor file from an Ivy ModuleDescriptor. This code is
all on the Ivy API level. Not everything we want to implement is
implemented yet. We are happy to offer this code eventually to the
Apache Ivy project (there is some code in Ivy for generating a pom
out of ivy objects but this code is pretty limited and was not usable
for our purpose).
What our code does:
One challenge is how to map between configurations and scopes, as
dependencies can belong to more than one configuration. In our code
we allow to map a configuration to one and only one scope. Different
configurations can be mapped to more than one scope. One can assign
also a priority to a particular mapping. Let's look at a couple of
cases:
- A dependency belongs to only one configuration: The first thing we
check is whether there is a mapping for this configuration. If there
is none, the dependency is by default not added to the pom. By
setting the global property 'includeUnmappedConfigurations' to true
such a dependency would be added. If the configuration is mapped, the
scope mapping is clear and the dependency is added.
- A dependency belongs to more than one mapped configuration: If the
mapped configurations map to the same scope the situation is clear.
If the mapped configurations map to different scopes the
configuration mapping with the highest priority is chosen. If there
is more than one configuration with a highest priority and they map
to different scopes an exception is thrown.
Exclude Rules: Our code has an exclude rule converter. This converter
gets an Ivy exclude rule and returns a Maven exclude rule or null. If
null is returned the exclude rule is not reflected in the pom. The
current simple logic of the converter is, that it returns a non null
value if the Ivy exclude rule uses an exact matcher and the name as
well as the organization of the module is specified.
Functionality that is still missing:
- Integrating the new Ivy 'override' rules the same way as the
exclude rules.
- Artifact dependencies are not mapped yet.
- Fine grained customization
The last point I think is very important. Due to the more powerful
elements Ivy has and many , often subtle, differences between Ivy and
Maven, auto generation can't always produce the result that is
needed. What we want to enable is that the user can modify any
property of an auto generated Maven dependency element. Customization
should also allow to remove auto generated elements as well as add
new elements. One thing we want to provide is a conversion listener.
A hook would getdev all the created MavenDependency object and can
analyze and modify them. Alternatively such a hook can provide a
'query by example' filter to get only a subset of the generated
MavenDependency elements.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
