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

Incomplete reflection cache files for 0.54 engine/Core jars #1777

Closed
msteiger opened this issue Jun 17, 2015 · 5 comments
Closed

Incomplete reflection cache files for 0.54 engine/Core jars #1777

msteiger opened this issue Jun 17, 2015 · 5 comments
Milestone

Comments

@msteiger
Copy link
Member

After upgrading to engine 0.54.0, some of the FacetLayers were no longer discovered in WorldViewer. I noticed that the reflections.cache file in the snapshot jars specified only some implementations.

Example: engine-0.54.0-6 reflections:

According to the cache file, the only subtypes of AbstractFacetLayer are NominalFacetLayer and SeaLevelFacetLayer, but in fact there are more - even in the same package (e.g. FieldFacetLayer).

How is that possible?

@immortius
Copy link
Member

immortius commented Jun 17, 2015 via email

@msteiger
Copy link
Member Author

Just a wild guess: Could it be related to gradle now compiling projects in parallel? I don't see a direct link, but maybe that's still buggy. Commit 6c1fe4b enabled it. The Gradle docs "56.8 Parallel project execution" gives some background info.

@immortius
Copy link
Member

It doesn't look like it, but if the reflections caching is happening concurrently with compilation that could explain it. Although I think it is too consistent on what classes are and aren't included.

@Cervator Cervator added this to the !NEXT: v0.54.0 milestone Jun 20, 2015
@Cervator
Copy link
Member

Actually that commit is to a template file, it isn't being used. I manually copy it to my local workspace to enable that kind of stuff and override destinations if I'm testing Artifactory type stuff.

Jenkins should still be compiling old school. We probably should actually consider changing that around a little sometime to optimize Gradle.

Would it be something to try running the build and the caching in separate Gradle executions? Like first compile the code, finish that Gradle execution, then start another to cache, then dist?

@immortius
Copy link
Member

immortius commented Jun 21, 2015 via email

immortius added a commit to immortius/Terasology that referenced this issue Jun 28, 2015
Updated gradle build to use reflections-0.9.9 and the new dom4j dependency
Tweaks to engine cacheReflections because it randomly started thinking it was always up-to-date on me.
Core and CoreSampleGamePlay also updated to use the new reflections, this will need to be pushed out to other modules and possibly improved in structure.
immortius added a commit to immortius/Terasology that referenced this issue Jun 28, 2015
Updated gradle build to use reflections-0.9.9 and the new dom4j dependency
Tweaks to engine cacheReflections because it randomly started thinking it was always up-to-date on me.
Core and CoreSampleGamePlay also updated to use the new reflections, this will need to be pushed out to other modules and possibly improved in structure.
This was referenced Jun 28, 2015
msteiger added a commit that referenced this issue Jun 28, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants