Dependency Resolution Exception at head?

[Pepper Lebeck-Jobe]

I'm just getting started attempting to contribute to the Guava project, and I've run into a problem which might just be configuration error on my part, but I've spent a little time trying to fix it and I'm baffled.

$> git clone https://code.google.com/p/guava-libraries/

$> cd guava-libraries

$> mvn --version

Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T16:58:10-04:00)

Maven home: /usr/local/apache-maven-3.2.3

Java version: 1.6.0_65, vendor: Apple Inc.

Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

Default locale: en_US, platform encoding: MacRoman

OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac"

$> mvn compile -e

...

[INFO] Error stacktraces are turned on.

[INFO] Scanning for projects...

[INFO]                                                                         

[INFO] ------------------------------------------------------------------------

[INFO] Building Guava GWT compatible libs 19.0-SNAPSHOT

[INFO] ------------------------------------------------------------------------

[WARNING] The POM for com.google.guava:guava:jar:19.0-SNAPSHOT is missing, no dependency information available

[WARNING] The POM for com.google.guava:guava-testlib:jar:19.0-SNAPSHOT is missing, no dependency information available

[WARNING] The POM for com.google.guava:guava-testlib:jar:tests:19.0-SNAPSHOT is missing, no dependency information available

[WARNING] The POM for com.google.guava:guava-tests:jar:tests:19.0-SNAPSHOT is missing, no dependency information available

[INFO] ------------------------------------------------------------------------

[INFO] BUILD FAILURE

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 1.201 s

[INFO] Finished at: 2014-09-02T22:40:00-04:00

[INFO] Final Memory: 4M/81M

[INFO] ------------------------------------------------------------------------

[ERROR] Failed to execute goal on project guava-gwt: Could not resolve dependencies for project com.google.guava:guava-gwt:jar:19.0-SNAPSHOT:

 The following artifacts could not be resolved: com.google.guava:guava:jar:19.0-SNAPSHOT, com.google.guava:guava-testlib:jar:19.0-SNAPSHOT, c

om.google.guava:guava-testlib:jar:tests:19.0-SNAPSHOT, com.google.guava:guava-tests:jar:tests:19.0-SNAPSHOT: Failure to find com.google.guava

:guava:jar:19.0-SNAPSHOT in https://oss.sonatype.org/content/repositories/snapshots was cached in the local repository, resolution will not b

e reattempted until the update interval of sonatype-nexus-snapshots has elapsed or updates are forced -> [Help 1]                           

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project guava-gwt: Could not resolve dependencies for proje

ct com.google.guava:guava-gwt:jar:19.0-SNAPSHOT: The following artifacts could not be resolved: com.google.guava:guava:jar:19.0-SNAPSHOT, com

.google.guava:guava-testlib:jar:19.0-SNAPSHOT, com.google.guava:guava-testlib:jar:tests:19.0-SNAPSHOT, com.google.guava:guava-tests:jar:tests

:19.0-SNAPSHOT: Failure to find com.google.guava:guava:jar:19.0-SNAPSHOT in https://oss.sonatype.org/content/repositories/snapshots was cache

d in the local repository, resolution will not be reattempted until the update interval of sonatype-nexus-snapshots has elapsed or updates ar

e forced                                                                                                                                    

        at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:220)

        at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)

        at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257)

        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)

        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)

        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)

        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)

        at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)

        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)

        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)

        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)

        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)

        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)

        at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

        at java.lang.reflect.Method.invoke(Method.java:597)

        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)

        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)

        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)

        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

Caused by: org.apache.maven.project.DependencyResolutionException: Could not resolve dependencies for project com.google.guava:guava-gwt:jar:

19.0-SNAPSHOT: The following artifacts could not be resolved: com.google.guava:guava:jar:19.0-SNAPSHOT, com.google.guava:guava-testlib:jar:19

.0-SNAPSHOT, com.google.guava:guava-testlib:jar:tests:19.0-SNAPSHOT, com.google.guava:guava-tests:jar:tests:19.0-SNAPSHOT: Failure to find co

m.google.guava:guava:jar:19.0-SNAPSHOT in https://oss.sonatype.org/content/repositories/snapshots was cached in the local repository, resolut

ion will not be reattempted until the update interval of sonatype-nexus-snapshots has elapsed or updates are forced                         

        at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:198)

        at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195)

        ... 22 more

Caused by: org.eclipse.aether.resolution.DependencyResolutionException: The following artifacts could not be resolved: com.google.guava:guava

:jar:19.0-SNAPSHOT, com.google.guava:guava-testlib:jar:19.0-SNAPSHOT, com.google.guava:guava-testlib:jar:tests:19.0-SNAPSHOT, com.google.guav

a:guava-tests:jar:tests:19.0-SNAPSHOT: Failure to find com.google.guava:guava:jar:19.0-SNAPSHOT in https://oss.sonatype.org/content/repositor

ies/snapshots was cached in the local repository, resolution will not be reattempted until the update interval of sonatype-nexus-snapshots ha

s elapsed or updates are forced                                                                                                             

        at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:384)

        at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:192)

        ... 23 more

Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: The following artifacts could not be resolved: com.google.guava:guava:j

ar:19.0-SNAPSHOT, com.google.guava:guava-testlib:jar:19.0-SNAPSHOT, com.google.guava:guava-testlib:jar:tests:19.0-SNAPSHOT, com.google.guava:

guava-tests:jar:tests:19.0-SNAPSHOT: Failure to find com.google.guava:guava:jar:19.0-SNAPSHOT in https://oss.sonatype.org/content/repositorie

s/snapshots was cached in the local repository, resolution will not be reattempted until the update interval of sonatype-nexus-snapshots has 

elapsed or updates are forced                                                                                                               

        at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:459)

        at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:262)

        at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:367)

        ... 24 more

Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to find com.google.guava:guava:jar:19.0-SNAPSHOT in https://oss.son

atype.org/content/repositories/snapshots was cached in the local repository, resolution will not be reattempted until the update interval of 

sonatype-nexus-snapshots has elapsed or updates are forced                                                                                  

        at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.newException(DefaultUpdateCheckManager.java:232)

        at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkArtifact(DefaultUpdateCheckManager.java:206)

        at org.eclipse.aether.internal.impl.DefaultArtifactResolver.gatherDownloads(DefaultArtifactResolver.java:599)

        at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:518)

        at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:436)

        ... 26 more

[ERROR] 

[ERROR] Re-run Maven using the -X switch to enable full debug logging.

[ERROR] 

[ERROR] For more information about the errors and possible solutions, please read the following articles:

[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

Can someone point me in the right direction?

Thanks,

Pepper

[Chris Povirk]

This sounds like the message that results if you run `mvn compile` rather than `mvn install`. If anyone can suggest a way for us to get `mvn compile` to work, we'd be happy to hear it.

https://code.google.com/p/guava-libraries/wiki/ContributorSetUp#Build_and_Test

[Christian Gruber]

As long as we're pulling guava sources to create guava-gwt, we're stuck with compile not working, since compile doesn't actually publish the sources such that the next module (guava-gwt) can pull them from the local repository.  Short of developing a plugin that can actually yoink the sources from the "reactor" (the in-memory pseudo repo that maven uses during multi-module builds to communicate build state), we're stuck going through the install lifecycle. 

On 3 September 2014 11:11, 'Chris Povirk' via guava-discuss <guava-...@googlegroups.com> wrote:

This sounds like the message that results if you run `mvn compile` rather than `mvn install`. If anyone can suggest a way for us to get `mvn compile` to work, we'd be happy to hear it.

https://code.google.com/p/guava-libraries/wiki/ContributorSetUp#Build_and_Test

--
--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAEvq2noe5F0cyit4idsBLKCfq4mBgF1P4uHLB2bKPOkNTjyd%2Bw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Jens]

As long as we're pulling guava sources to create guava-gwt, we're stuck with compile not working, since compile doesn't actually publish the sources such that the next module (guava-gwt) can pull them from the local repository.  Short of developing a plugin that can actually yoink the sources from the "reactor" (the in-memory pseudo repo that maven uses during multi-module builds to communicate build state), we're stuck going through the install lifecycle. 

You could switch to Gradle. I have a multi-module project in which "module-gwt" picks certain source files from "module" to build a GWT compatible subset just like Guava does. So far it works pretty well and I don't have to install artifacts to my local repository if I don't want to.

-- J.

[Joachim Durchholz]

Am 03.09.2014 um 20:11 schrieb 'Chris Povirk' via guava-discuss:
> This sounds like the message that results if you run `mvn compile` rather
> than `mvn install`. If anyone can suggest a way for us to get `mvn compile`
> to work, we'd be happy to hear it.

The One True Maven Way(TM) to use a dependency is to first `mvn install` it.
There are workarounds, such as relying on the local cache or on a
"reactor", but they are discouraged, mostly for philosphical reasons
(though the Mavenists were never able to convince me of the validity of
these reasons).

I switched to Gradle in the end, and while not everything is roses
there, it's far more cooperative.

[Christian Gruber]

Joachim - let's not get into "build system wars" here.  This is not a list for such discussion. 

The reactor is just fine conceptually, it is not discouraged - it is in fact the means by which inter-module dependencies are resolved during hte build phase.  That's by design, so there's no "one true way" involved (and the religious language is simply inappropriate in a technical discussion). 

I'd prefer to use the reactor if possible.  It is not fine in our case, however, because we're doing something unusual - we're taking sources (which are only created in the packaging step) and pulling them in the guava-gwt's build step.  We're hacking up maven's lifecycle and using installed secondary artifacts in a later project/module's build step.

That said, I can try to see if we can just build the sources artifact earlier than the packaging step in order to satisfy this oddity - now that I think it through, it might be possible. 

Christian.

--
--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss

This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask?tags=guava
--- You received this message because you are subscribed to the Google Groups "guava-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/5409C894.9020906%40durchholz.org.

[Joachim Durchholz]

Sorry, I got the "just getting started" bit and thought it was about
Pepper's build process, totally missing that his build process is
actually Guava's.
And no, I'm not lunatic enough to seriously advocating changes in
Guava's build system. Not unless I have a firm grasp of all the
stakeholders' needs, anyway ;-)

> The reactor is just fine conceptually, it is not discouraged

Hm. Undisputed authority on the maven-users list (if memory serves me
right) had it that the reactor is an ugly hack.
That it isn't doing a mvn install (which is the normal way to make a
dependency available) might be at the core of that sentiment. Maybe that
particular person was sick of problems like the one we're seeing here.

> That's by design, so there's no "one true way" involved (and
> the religious language is simply inappropriate in a technical discussion).

Heh. Apologies for the religious connotation, though I stand by the
substance (but too far off-topic for this list).

> I'd prefer to use the reactor if possible. It is not fine in our case,
> however, because we're doing something unusual - we're taking sources
> (which are only created in the packaging step) and pulling them in the
> guava-gwt's build step.

Hmm... are we barking up the right tree?
The error trace from Pepper indicates missing POMs. That's not what I'd
expect to see from just a missing secondary artifact, unless the POMs
themselves are generated, too (now that's something I'd never dare).

> We're hacking up maven's lifecycle and using
> installed secondary artifacts in a later project/module's build step.

Providing secondary artifacts should be covered by plugins inside the
normal lifecycle; what's in the Guava build that requires a modified
lifecycle?