Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log resolving errors from LibraryClasspathContainerResolverService #3180

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

briandealwis
Copy link
Member

@briandealwis briandealwis commented Jun 26, 2018

I was hitting puzzling errors running the ImportNativeAppEngineStandardProjectTest integration tests locally where our classpath container had no entries. It was really puzzling! I discovered that our LibraryClasspathContainerResolverService wasn't logging a key exception, which clued me in that Maven had failed to download an artifact and left a little .lastUpdated dropping that prevents Maven from attempting to re-resolve for some amount of time.

This patch causes that exception to be logged.

java.lang.AssertionError: 
Expected: an array with size a value greater than <0>
     but: array size <0> was equal to <0>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:956)
	at org.junit.Assert.assertThat(Assert.java:923)
	at com.google.cloud.tools.eclipse.integration.appengine.ImportNativeAppEngineStandardProjectTest.updateOldContainers(ImportNativeAppEngineStandardProjectTest.java:131)
	at com.google.cloud.tools.eclipse.integration.appengine.ImportNativeAppEngineStandardProjectTest.importAppEngineStandardJava8_from1_3_1(ImportNativeAppEngineStandardProjectTest.java:102)

Fixes #3181 too.

@codecov
Copy link

codecov bot commented Jun 26, 2018

Codecov Report

Merging #3180 into master will increase coverage by 0.11%.
The diff coverage is 83.33%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #3180      +/-   ##
============================================
+ Coverage     69.75%   69.87%   +0.11%     
- Complexity     2931     2939       +8     
============================================
  Files           372      372              
  Lines         13422    13424       +2     
  Branches       1611     1612       +1     
============================================
+ Hits           9363     9380      +17     
+ Misses         3377     3365      -12     
+ Partials        682      679       -3
Impacted Files Coverage Δ Complexity Δ
...tory/LibraryClasspathContainerResolverService.java 80.89% <83.33%> (-2.34%) 36 <0> (+1)
...calAppEngineServerLaunchConfigurationDelegate.java 61.42% <0%> (-0.3%) 39% <0%> (ø)
...ow/ui/preferences/RunOptionsDefaultsComponent.java 78.57% <0%> (+0.62%) 60% <0%> (+2%) ⬆️
.../facets/ui/navigator/AppEngineContentProvider.java 80.76% <0%> (+1.92%) 37% <0%> (+2%) ⬆️
...vigator/model/AppEngineStandardProjectElement.java 76.47% <0%> (+1.96%) 39% <0%> (+1%) ⬆️
...ipse/dataflow/core/project/DataflowMavenModel.java 63.88% <0%> (+9.72%) 9% <0%> (ø) ⬇️
...ibraries/LibraryClasspathContainerResolverJob.java 92.3% <0%> (+15.38%) 3% <0%> (ø) ⬇️
...aflow/ui/handler/ModifyDataflowVersionHandler.java 20.83% <0%> (+20.83%) 2% <0%> (+2%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aa89aa3...26e0f7b. Read the comment docs.

chanseokoh
chanseokoh previously approved these changes Jun 26, 2018
@briandealwis
Copy link
Member Author

I'll commit this once I have a patch for #3181.

@briandealwis
Copy link
Member Author

Hmm, now the logs are littered with exceptions (below) as the fix for #3181 is now executing the remainder of LibraryClasspathContainerResolverService.resolveContainer():

The first type of exception is because we don't have source for appengine-api-1.0-sdk on Maven Central. This is arguably not an error.

15:45:55.875 [Worker-2] DEBUG c.g.c.t.e.a.l.SourceAttacherJob - Could not attach source path
org.eclipse.core.runtime.CoreException: Could not resolve artifact com.google.appengine:appengine-api-1.0-sdk:jar:sources:1.9.64
	at org.eclipse.m2e.core.internal.embedder.MavenImpl$5.call(MavenImpl.java:776) ~[na:na]
	at org.eclipse.m2e.core.internal.embedder.MavenImpl$5.call(MavenImpl.java:1) ~[na:na]
	at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:177) ~[na:na]
	at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112) ~[na:na]
	at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99) ~[na:na]
	at org.eclipse.m2e.core.internal.embedder.MavenImpl.resolve(MavenImpl.java:743) ~[na:na]
	at org.eclipse.m2e.core.internal.embedder.MavenImpl.resolve(MavenImpl.java:720) ~[na:na]
	at com.google.cloud.tools.eclipse.util.MavenUtils.lambda$resolveArtifact$0(MavenUtils.java:98) ~[na:na]
	at com.google.cloud.tools.eclipse.util.MavenUtils.lambda$runOperation$1(MavenUtils.java:124) ~[na:na]
	at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:177) ~[na:na]
	at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151) ~[na:na]
	at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99) ~[na:na]
	at com.google.cloud.tools.eclipse.util.MavenUtils.runOperation(MavenUtils.java:120) ~[na:na]
	at com.google.cloud.tools.eclipse.util.MavenUtils.resolveArtifact(MavenUtils.java:93) ~[na:na]
	at com.google.cloud.tools.eclipse.appengine.libraries.repository.MavenHelper.resolveArtifact(MavenHelper.java:44) ~[na:na]
	at com.google.cloud.tools.eclipse.appengine.libraries.repository.M2RepositoryService.resolveSourceArtifact(M2RepositoryService.java:64) ~[na:na]
	at com.google.cloud.tools.eclipse.appengine.libraries.repository.LibraryClasspathContainerResolverService.lambda$createSourceAttacherJob$0(LibraryClasspathContainerResolverService.java:256) ~[na:na]
	at com.google.cloud.tools.eclipse.appengine.libraries.SourceAttacherJob.attachSource(SourceAttacherJob.java:105) ~[na:na]
	at com.google.cloud.tools.eclipse.appengine.libraries.SourceAttacherJob.run(SourceAttacherJob.java:82) ~[na:na]
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) [org.eclipse.core.jobs-3.9.3.v20180115-1757.jar:na]

Our SourceAttachers then update the container state with the source bindings, which is failing as the test has completed in the meantime and deleted the project. These SourceAttacherJobs should be part of a family so that ProjectUtils.waitForProjects() waits for their completion. Or maybe we should just toss this source-attachment and let m2eclipse's source provider find and resolve it instead.

15:45:55.987 [Worker-15] DEBUG c.g.c.t.e.a.l.SourceAttacherJob - Could not attach source path
org.eclipse.core.internal.resources.ResourceException: Resource '/AESv7/.settings' does not exist.
	at org.eclipse.core.internal.resources.Resource.checkExists(Resource.java:335) ~[na:na]
	at org.eclipse.core.internal.resources.Resource.checkAccessible(Resource.java:209) ~[na:na]
	at org.eclipse.core.internal.resources.Folder.assertCreateRequirements(Folder.java:33) ~[na:na]
	at org.eclipse.core.internal.resources.Folder.create(Folder.java:93) ~[na:na]
	at org.eclipse.core.internal.resources.Folder.create(Folder.java:121) ~[na:na]
	at com.google.cloud.tools.eclipse.appengine.libraries.persistence.LibraryClasspathContainerSerializer$DefaultStateLocationProvider.getFile(LibraryClasspathContainerSerializer.java:215) ~[na:na]
	at com.google.cloud.tools.eclipse.appengine.libraries.persistence.LibraryClasspathContainerSerializer$DefaultStateLocationProvider.getContainerStateFile(LibraryClasspathContainerSerializer.java:202) ~[na:na]
	at com.google.cloud.tools.eclipse.appengine.libraries.persistence.LibraryClasspathContainerSerializer.getContainerStateFile(LibraryClasspathContainerSerializer.java:184) ~[na:na]
	at com.google.cloud.tools.eclipse.appengine.libraries.persistence.LibraryClasspathContainerSerializer.saveContainer(LibraryClasspathContainerSerializer.java:87) ~[na:na]
	at com.google.cloud.tools.eclipse.appengine.libraries.SourceAttacherJob.run(SourceAttacherJob.java:87) ~[na:na]
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) [org.eclipse.core.jobs-3.9.3.v20180115-1757.jar:na]

Copy link
Contributor

@elharo elharo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Source jars are b/68379022

I've pinged @ludoch

serializer.saveContainer(javaProject, container);
for (Job job : sourceAttacherJobs) {
job.schedule();
if (!javaProject.getProject().getWorkspace().isTreeLocked()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like the PR is doing more than simply logging errors.

Copy link
Contributor

@elharo elharo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ping. What's the status on this?

@briandealwis
Copy link
Member Author

It turned into a bit of a tar-baby.

The trigger (failing downloads leaving .lastUpdated files) is #3095 — we have two codepaths for fetching Maven dependencies which should be rationalized to use Aether directly as done by DependencyResolver.

And then there's a separate issue of forking off separate source-jar resolvers. I'm not sure it actually buys us that much since on completion the jobs update the classpath, which will trigger a new build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ResourceException during LibraryClasspathContainer initialization
4 participants