You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just hit the issue described in #2699, where the server runtime classpath container couldn't be resolved. It was difficult to figure out as there were no real indications of a problem, largely because our logging isn't actually visible (#3092). I ended up having to launch a debug instance and put exception breakpoints on CoreException to figure out what was going wrong.
I hit this problem as my Windows VM's networking was non-functional and so attempting to resolve the server runtime artifacts failed (servlet-api 3.1.0 and jsp 2.3). Maven helpfully wrote out its .lastUpdated files which prevent subsequent attempts to re-resolve the artifacts because of m2e's default update policy is set to never update.
Our reliance on Maven to resolve artifacts means that we're subject to m2e's policy decisions. But unlike m2e, we do not have a pom.xml to which to attach resolution problems.
We can actually ignore m2e's policies — and we actually do in our DependencyResolver (#2887). But it turns out that we have two codepaths for resolving maven artifacts with different behaviours:
MavenUtils: uses m2e to resolve items, and is subject to the m2e preferences
DependencyResolver: uses aether directly, using m2e's configurations as a base that we can override
And our library resolving infrastructure uses MavenUtils, whereas our BuildPath support uses the DependencyResolver. By using DependencyResolver everywhere, we can configure Aether to ignore the .lastUpdated files (setUpdatePolicy(RepositoryPolicy.UPDATE_POLICY_*)).
May 24, 2018 12:31:36 PM com.google.cloud.tools.eclipse.appengine.localserver.ServletClasspathProvider$1 onFailure
WARNING: Failed to resolve servlet APIs
java.util.concurrent.ExecutionException: org.eclipse.core.runtime.CoreException: Could not resolve artifact javax.servlet:servlet-api:jar:2.5
at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:502)
at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:461)
at com.google.common.util.concurrent.AbstractFuture$TrustedFuture.get(AbstractFuture.java:78)
at com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:142)
at com.google.common.cache.LocalCache$Segment.getAndRecordStats(LocalCache.java:2461)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2425)
at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2298)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2211)
at com.google.common.cache.LocalCache.get(LocalCache.java:4154)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4158)
at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:5147)
at com.google.cloud.tools.eclipse.appengine.libraries.repository.LibraryClasspathContainerResolverService.resolveLibraries(LibraryClasspathContainerResolverService.java:177)
at com.google.cloud.tools.eclipse.appengine.libraries.repository.LibraryClasspathContainerResolverService.lambda$0(LibraryClasspathContainerResolverService.java:168)
at com.google.cloud.tools.eclipse.util.jobs.PluggableJob.compute(PluggableJob.java:69)
at com.google.cloud.tools.eclipse.util.jobs.FuturisticJob.run(FuturisticJob.java:285)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
Caused by: org.eclipse.core.runtime.CoreException: Could not resolve artifact javax.servlet:servlet-api:jar:2.5
at org.eclipse.m2e.core.internal.embedder.MavenImpl$5.call(MavenImpl.java:776)
at org.eclipse.m2e.core.internal.embedder.MavenImpl$5.call(MavenImpl.java:1)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:177)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99)
at org.eclipse.m2e.core.internal.embedder.MavenImpl.resolve(MavenImpl.java:743)
at org.eclipse.m2e.core.internal.embedder.MavenImpl.resolve(MavenImpl.java:720)
at com.google.cloud.tools.eclipse.util.MavenUtils.lambda$0(MavenUtils.java:98)
at com.google.cloud.tools.eclipse.util.MavenUtils.lambda$1(MavenUtils.java:124)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:177)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99)
at com.google.cloud.tools.eclipse.util.MavenUtils.runOperation(MavenUtils.java:120)
at com.google.cloud.tools.eclipse.util.MavenUtils.resolveArtifact(MavenUtils.java:93)
at com.google.cloud.tools.eclipse.appengine.libraries.repository.MavenHelper.resolveArtifact(MavenHelper.java:44)
at com.google.cloud.tools.eclipse.appengine.libraries.repository.M2RepositoryService.resolveArtifact(M2RepositoryService.java:50)
at com.google.cloud.tools.eclipse.appengine.libraries.repository.LibraryClasspathContainerResolverService.resolveLibraryFileAttachSourceSync(LibraryClasspathContainerResolverService.java:307)
at com.google.cloud.tools.eclipse.appengine.libraries.repository.LibraryClasspathContainerResolverService.access$0(LibraryClasspathContainerResolverService.java:304)
at com.google.cloud.tools.eclipse.appengine.libraries.repository.LibraryClasspathContainerResolverService$1.load(LibraryClasspathContainerResolverService.java:110)
at com.google.cloud.tools.eclipse.appengine.libraries.repository.LibraryClasspathContainerResolverService$1.load(LibraryClasspathContainerResolverService.java:1)
at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3716)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2424)
… 10 more
The text was updated successfully, but these errors were encountered:
I just hit the issue described in #2699, where the server runtime classpath container couldn't be resolved. It was difficult to figure out as there were no real indications of a problem, largely because our logging isn't actually visible (#3092). I ended up having to launch a debug instance and put exception breakpoints on
CoreException
to figure out what was going wrong.I hit this problem as my Windows VM's networking was non-functional and so attempting to resolve the server runtime artifacts failed (
servlet-api 3.1.0
andjsp 2.3
). Maven helpfully wrote out its.lastUpdated
files which prevent subsequent attempts to re-resolve the artifacts because of m2e's default update policy is set to never update.Our reliance on Maven to resolve artifacts means that we're subject to m2e's policy decisions. But unlike m2e, we do not have a
pom.xml
to which to attach resolution problems.We can actually ignore m2e's policies — and we actually do in our
DependencyResolver
(#2887). But it turns out that we have two codepaths for resolving maven artifacts with different behaviours:MavenUtils
: uses m2e to resolve items, and is subject to the m2e preferencesDependencyResolver
: uses aether directly, using m2e's configurations as a base that we can overrideAnd our library resolving infrastructure uses
MavenUtils
, whereas ourBuildPath
support uses theDependencyResolver
. By usingDependencyResolver
everywhere, we can configure Aether to ignore the .lastUpdated files (setUpdatePolicy(RepositoryPolicy.UPDATE_POLICY_*)
).The text was updated successfully, but these errors were encountered: