8000 Refactor saker.java.processor implementation to employ classpath caching in the bundle storage · Issue #1 · sakerbuild/saker.java.compiler · GitHub
[go: up one dir, main page]
Skip to content
8000

Refactor saker.java.processor implementation to employ classpath caching in the bundle storage #1

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.

Sign up for GitHub

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

Jump to bottom
Closed
Sipkab opened this issue Dec 31, 2019 · 0 comments · Fixed by #10
Closed

Refactor saker.java.processor implementation to employ classpath caching in the bundle storage #1

Sipkab opened this issue Dec 31, 2019 · 0 comments · Fixed by #10
Labels
bug Something isn't working enhancement New feature or request

Comments

@Sipkab
Copy link
Member
Sipkab commented Dec 31, 2019 •
edited
Loading

The saker.java.processor() task currently loads the classpath for the annotation processors by opening the files in-place. This can cause JAR files to be locked, and may prevent issues when the user tries to delete/overwrite them.

The classpath input for the task should be cached off-site, meaning that it should be copied to a location private to the saker.java.compiler bundle. The saker.nest repository provides access to such directory, and the classpaths should be copied there.

Note that this cache location is shared by all concurrently running build executions, therefore proper file-system level locking should be ensured.

The deprecated part of the ProcessorCreationContextImpl class should be removed when this issue is done.

The ClassLoader creation for the classpath should be cached by the build environment, so they won't be recreated between subsequent builds.

Both the bug and enhancement labels are added to the issue as it qualifies as both. Currently the issue can be easily worked around.
@Sipkab Sipkab added bug Something isn't working enhancement New feature or request labels Dec 31, 2019
@Sipkab Sipkab mentioned this issue Jan 9, 2020
Merged
Sipkab added a commit that referenced this issue Jan 9, 2020
@Sipkab
Cache annotation processor classpaths in repository storage dir
a91fb78 
The input classpaths from where the saker.java.processor task loads the
annotation processors are cached in the storage directory associated
with the saker.java.compiler package.

See issue #1
@Sipkab Sipkab mentioned this issue Jan 9, 2020
Merged
@Sipkab Sipkab closed this as completed in #10 Jan 9, 2020
Sipkab added a commit that referenced this issue Jan 9, 2020
@Sipkab
Fix issue #1 (#10)
6c25805 
* Cache annotation processor classpaths in repository storage dir

The input classpaths from where the saker.java.processor task loads the
annotation processors are cached in the storage directory associated
with the saker.java.compiler package.

* Add API for representing static classpath in ClassPathEntry

* Report execution property dependency on cached jar outputs

So if they are deleted between build executions, they are re-cached
again.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working enhancement New feature or request
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix issue #1 sakerbuild/saker.java.compiler
1 participant
@Sipkab
0