-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
refactor! move engine code in to org.terasology.engine package #4560
Conversation
Packages that were formerly org.terasology.engine are now org.terasology.engine.core.
I wonder if someone has published a diff filter that makes it easy to say "hide all chunks that change only imports or comments." |
Recent versions of git (2.30) have an option to --ignore-matching-lines I find this almost does what I want: git diff \
--ignore-matching-lines='^(@API )?(package|import)' \
--ignore-matching-lines='^/[/*]' \
--ignore-matching-lines='^ \*' \
origin/develop...origin/chore/move-in-place but some things are still slipping through. I think because they have a blank line in them? but my attempts to filter out blank lines with something like Update: removing context lines with |
@DarkWeird Is this the right package organization? Do we need a stricter policy on what packages things like facade and subsystems use? This splits the existing (I did take a quick look to see if any of your current open PRs address that kind of thing for TypeHandlerLibrary, but I didn't find any.) |
I think that org.terasology.sibsystem better. |
engine-tests/src/main/java/org/terasology/ModuleEnvironmentTest.java engine-tests/src/main/java/org/terasology/TerasologyTestingEnvironment.java engine-tests/src/test/java/org/terasology/config/flexible/AutoConfigManagerTest.java engine-tests/src/test/java/org/terasology/persistence/internal/StorageManagerTest.java engine/src/main/java/org/terasology/entitySystem/event/internal/EventSystemImpl.java engine/src/main/java/org/terasology/recording/EventSystemReplayImpl.java
subsystems/DiscordRPC/src/main/java/org/terasology/engine/subsystem/discordrpc/DiscordRPCSubSystem.java subsystems/DiscordRPC/src/main/java/org/terasology/engine/subsystem/discordrpc/DiscordRPCSystem.java
There is one test failure in this branch: http://jenkins.terasology.io/teraorg/job/Terasology/job/engine/view/change-requests/job/PR-4560/4/testReport/org.terasology.engine.config.flexible/AutoConfigSerializerTest/testSerializeNonDefault__/ an AutoConfigSerializerTest that says
I guess for a serializer, the ordering should be stable. But I'm confused if it's a bug that's really specific to this branch. |
If I had all of modulespace checked out in to one IntelliJ project when I did the package-move refactorings, I suppose IntelliJ would have updated all the module code for me, if it didn't explode from the size of it. But I didn't, so now I'm trying to figure out how to apply those changes to the modules after the fact. I was about to try some regular expression search-and-replace when I came across IntelliJ's migration feature. If you grab the xml file from this gist: https://gist.github.com/keturn/9a6b598c11ba7f9c3b710c8fe1e3a6c5 Caveats:
|
but most worryingly, I can't get the result to build. https://scans.gradle.com/s/3w3pazserxguc Lots of "could not find class" stuff that looks like it should be available. Not sure if I have skewed versions somehow, or if my build is cursed by the "moving packages without moving files" trick. |
That scan says that only DynamicCities and SimpleFarming actually failed, so if I remove those from my workspace, it does pass https://scans.gradle.com/s/vbjifnzxkhooa but there is a lot of noise from reflections in the log about not being able to find classes. probably during the cache-reflections step while building module jars. I haven't checked to see if that's because it hates the file layout in this branch, or if it's something the recent upgrade to 0.9.12 caused. |
okay, have made some progress. I have all of CoreSampleGameplay building and I can at least attempt to start a single-player game without getting any module resolution failures. I guess that means I should check stuff in to a branch on all those modules? |
Ah, how could I have forgotten about Master of Oreon! I checked out Omega and gave gradle more RAM and I think that should be all of them now. If I haven't created a |
I'm still haven't decided what to do about that one test failure. I see a PR #4235 with "autoconfig" in the title, so I've kinda been waiting to see if it gets merged before this one and it deals with the problem somehow. |
Just double-checked and it seems like all modules that don't have a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I won't look at each file and into all module PRs, but I checked out omega with all the chore/move-in-place branches, it compiled and JS, MR and LaS started and looked as expected.
…working on the merge conflicts… |
engine-tests/src/test/java/org/terasology/entitySystem/BaseEntityRefTest.java engine-tests/src/test/java/org/terasology/entitySystem/OwnershipHelperTest.java engine-tests/src/test/java/org/terasology/entitySystem/PojoEntityManagerTest.java engine-tests/src/test/java/org/terasology/entitySystem/PojoEntityPoolTest.java engine-tests/src/test/java/org/terasology/entitySystem/PojoEventSystemTests.java engine-tests/src/test/java/org/terasology/persistence/ComponentSerializerTest.java engine-tests/src/test/java/org/terasology/persistence/EntitySerializerTest.java engine/src/main/java/org/terasology/engine/ComponentSystemManager.java engine/src/main/java/org/terasology/engine/bootstrap/EntitySystemSetupUtil.java engine/src/main/java/org/terasology/entitySystem/event/internal/EventSystem.java engine/src/main/java/org/terasology/entitySystem/event/internal/EventSystemImpl.java engine/src/main/java/org/terasology/entitySystem/systems/RegisterMode.java
engine-tests/src/test/java/org/terasology/config/flexible/internal/SettingImplTest.java engine/src/main/java/org/terasology/config/flexible/SettingArgument.java engine/src/main/java/org/terasology/config/flexible/internal/SettingBuilder.java engine/src/main/java/org/terasology/config/flexible/internal/SettingImpl.java engine/src/main/java/org/terasology/config/flexible/internal/SettingImplBuilder.java engine/src/main/java/org/terasology/engine/modes/StateLoading.java engine/src/main/java/org/terasology/engine/modes/loadProcesses/InitialiseWorld.java engine/src/main/java/org/terasology/engine/subsystem/common/MonitoringSubsystem.java engine/src/main/java/org/terasology/i18n/TranslationSystemImpl.java engine/src/main/java/org/terasology/logic/console/commands/CoreCommands.java engine/src/main/java/org/terasology/logic/console/commands/ServerCommands.java engine/src/main/java/org/terasology/logic/players/DebugControlSystem.java engine/src/main/java/org/terasology/persistence/internal/ReadWriteStorageManager.java engine/src/main/java/org/terasology/rendering/nui/editor/layers/NUIEditorSettingsScreen.java engine/src/main/java/org/terasology/rendering/nui/layers/ingame/metrics/DebugOverlay.java engine/src/main/java/org/terasology/rendering/nui/layers/mainMenu/settings/PlayerSettingsScreen.java engine/src/main/java/org/terasology/telemetry/metrics/GameConfigurationMetric.java
Merged the autoconfig PR, but the same test still fails here. http://jenkins.terasology.io/teraorg/job/Terasology/job/engine/job/PR-4560/10/testReport/junit/org.terasology.engine.config.flexible/AutoConfigSerializerTest/testSerializeNonDefault__/ Thing is, if the output order isn't stable because HashMap ordering isn't stable in general, I'd expect it to be a flaky test. But it hasn't been failing in develop, and it seems to be failing every build here.
my hunch is that we've somehow uncovered a bug that shows the output is not stable, and it doesn't really have anything to do with this branch. In that case, should we disable the test? or is a fix small enough to include in this branch? I'd think it should either be insertion-order (that's how it's written now), or some locale-independent sort on the key. |
getSettingFields returns a Set from Reflections, so that ordering is undefined: Terasology/engine/src/main/java/org/terasology/config/flexible/AutoConfig.java Lines 24 to 25 in b00f1b9
if we want to sort the output, this looks like the place to do it Terasology/engine/src/main/java/org/terasology/config/flexible/AutoConfigSerializer.java Lines 72 to 76 in b00f1b9
|
This is what I did about the AutoConfigSerializer test: dd09b91 |
…yer-control-system # Conflicts: # engine/src/main/java/org/terasology/engine/logic/players/LocalPlayerSystem.java # engine/src/main/java/org/terasology/engine/persistence/serializers/ComponentSerializeCheck.java chore: update engine package paths for #4560
In the
engine
project:See this comment for a migration file: #4560 (comment)
In
engine-test
:Subsystems remain the same:
DiscordRPC: org.terasology.engine.subsystem.discordrpchas been moved indevelop
Facades remain the same:
Since the engine package seems to be a blocker for starting gestalt-v7,
and nobody wants to move the packages for fear file moves causing git conflicts with other work in progress,
here is a wacky and whimsical alternative:
Leave the files in place, but use some config overrides to make them think they are in a package named something else.
I don't recommend leaving it configured this way for very long because someone or something WILL get terribly confused, but maybe it helps get the ball rolling?
warning: I failed to learn all the lessons from #4144 and forgot to turn off the copyright-updater before doing mass file operations.