It's a little unclear what is going on.
What you are seeing though is Maven's unique version feature, which assigns a
version number to the snapshot based on timestamp and an incrementing counter.
Try turning that off with:
uploadArchives {
repositories.mavenDeployer {
uniqueVersion = false
snapshotRepository(url:"${repoBase}/${snapshotPublishRepoLocation}")
}
}
That said, I think the setup you are describing should work. Can you please
raise an issue, and it would be especially helpful if you could attach a small
sample project that exhibits the issue.
On 03/09/2011, at 9:47 AM, lessonz wrote:
> Okay, I'm not a maven expert, so I'm trying to keep things as simple as
> possible, but I'm still running into problems.
>
> I have a plugin I'm writing. In it, I set version:
>
> version = "0.1-SNAPSHOT"
>
> I set mavenDeployer:
>
> uploadArchives {
> repositories.mavenDeployer {
> snapshotRepository(url:"${repoBase}/${snapshotPublishRepoLocation}")
> }
> }
>
> That works as expected. The repo ends up with an artifact where the
> "SNAPSHOT" in version has been replaced with a time stamp and a classifier
> of "1" has been appended (the version in the default hierarchy has
> "SNAPSHOT" unchanged and does not include the classifier). I guess that's
> normal?
>
> Then, I have a project that depends on this plugin:
>
> buildscript {
> repositories {
> mavenRepo urls: "${repoBase}/${resolverRepoLocation}"
> }
> dependencies {
> classpath 'lessonz:common-java:+'
> }
> }
>
> Resolving fails. It can't find the pom or the artifact. I don't understand
> why this build is failing. Is the classifier the problem? Am I mistaken to
> believe using mostly default values for each side of this should result in a
> successful dependency resolution?
>
> Thanks for any help and/or insight.
>
> --
> View this message in context:
> http://gradle.1045684.n5.nabble.com/Problems-with-Maven-Resolver-or-Deployer-tp4765075p4765075.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email