Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Findbugs -> FindBugs

Merge branch 'code-quality' of into ajoberstar-code-quality

(Szczepan/Luke) Fixed the problem with stalling client when daemon used...

-Now the final listening for remaining input / closing the input stream really happens after we send to the client the daemon failure. That solves Hans' stalled client issue. However, it does not solve the underlying problem although now we will be able to see the actual problem / stack trace because it will be sent back to the client.

-Added coverage using the embedded daemon which proves very handy already.

Changed Findbugs task to execute Ant task rather than directly executing the Findbugs class.

Moved configuration of RepositoryCacheManager inside the RepositoryFactory, and out of the ivy SettingsConverter

  1. … 3 more files in changeset.
Moved responsibility for attaching TransferListener to DependencyResolver out of SettingsConverter and into ResolverFactory

Fixed problem with getting new tooling api models with M5 and M6…

I cannot really allow asking for brand new models (like BuildEnvironment) when the provider is at m5 or m6 due to a daemon bug in those versions. So I added special case for that in the tooling api consumer code. Also, we now have coverage for that so this situation should not happen again. The problem with the daemon was fixed with one of the earlier checkins so M7 and above should be safe (given we merge the bugfix to the release branch :).

Merge branch 'code-quality' of into ajoberstar-code-quality

Improved the client facing exceptions (messages and the stack) in the tooling api.

Exception handling in the daemon server for the first received message...

The previous behavior led to 'stalled' client when for some reason receiving the first message on the server side has failed. It was exposed by some tooling api use cases and integ tests. This might be also related to recent problems Hans raised. Details:

-Added exception handling to the daemon server. On exception we dispatch DaemonFailure back to the client. Some refactorings will follow but I need a small changeset I can merge to M7 release branch.

-Added a coverage that takes full advantage of the embeddedDaemon

-Unfortunately this problem exists in M5 and M6 which means that I will have to add some extra handling to the tooling api to protect the client in case the target gradle is M5 or M6.

Improved exception when tooling api client asks for unknown model.

Moved the test to appropriate package.

slightly friendlier deprecation warning

fixed test, acknowledging the fact that we can't currently control order between Javadoc tags and taglets

Changed ArtifactRepositoryInternal.createResolvers(Collection) -> .createResolver():DependencyResolver

fixed GRADLE-1563: Javadoc Plugin does not generate correct command line options for tags and taglets

added javadoc.options {} convenience method

added acceptance test

Javadoc fixes

Tiny update to the comment.

Checkstyle/unit test fixes after recent refactoring.

Shuffled classes into separate package for clarity.

Started adopting the build operation parameters early in the provider...

-Came out at the code review. We want to keep the contract of static protocol interfaces so I reverted the change on the BuildOperationParameters and LongRunningOperationParameters. On the provider side I'm adapting them into a different interface that defines the information needed by the provider.

-Started using the new interface consistently in the provider code.

-Started using generic T in the provider code instead of ProjectVersion3 because we now build different models than projects (e.g. the BuildEnvironment)

Removed unnecessary DependencyGraphBuilder interface, previously introduced to allow ivy context wrapping

Use ivy context to get ParserSettings inside ModuleDescriptorStore, rather than setting the ivySettings directly on the cache implementation - IvyContextualiser now has a way to get the IvyContext, failing if it's not been established.

Wrap ivy contextualisation directly around DefaultModuleDescriptor creation, rather than around the entire resolution process.

Refactored the compatibility-related code in the DefaultConnection...

Got rid of duplicated conditionals, generally started improving our strategy to deal with evolution of internal protocol types. This is not our final strategy for sure but a good incremental start.

Added a little bit of exception handling to the daemon client.

Wrap individual ModuleVersionRepositories with ivy contextualisation, rather than wrapping upper-level DependencyToModuleResolver and ArtifactToFileResolver - UserResolverChain no longer is responsible for constructing ModuleVersionRepository from DependencyResolver

Moved construction of UserResolverChain and wrapping of DependencyResolvers out of DefaultSettingsConverter - DefaultSettingsConverter now only attaches listeners to DependencyResolvers and binds them to the current ivy settings - Construct LoopbackDependencyResolver outside of DefaultSettingsConverter

Fixed a nasty issue about incorrect target gradle version used when test level Spock annotation used...

-Basically, when we used @Timeout(10) annotation on a test level, the target gradle was always latest, rather than whatever is configured via the compatibility suite. I didn't find a way to add coverage for this problem so I added a sanity half-manual test.

-Added new annotation so that when working in IDE one can easily run tests for all permutations.

Avoided some IDEA compilation errors by not using @Delegate...

It was related to eager generation of static methods. Not a big problem, though, I can simply stop using delegate in this instance.

Improved the tooling api tests. Now they should not require updating after release.