feat: move packages into engine (gestalt-v7 prereq)

[pollend]

@DarkWeird so I did a git move so the source changes should be minimal. correct the packages from this PR and we can merge this first then it should make the delta for gestalt-v7 much smaller. previous PR's should work since this includes a move so those file changes should still be valid.

[lgtm-com]

This pull request introduces 1 alert and fixes 1 when merging 1f035be into 3a426b0 - view on LGTM.com

new alerts:

• 1 for Equals method does not inspect argument type

fixed alerts:

• 1 for Equals method does not inspect argument type

[DarkWeird]

You didn't move packages. only files.
Then you should update package of classes and imports

[keturn]

If we do want to do a big move like this, it is probably better to get it over with and do them all at once, but I'd like to be clear on what the dependencies are.

1. Can we move java files like this without changing their package? Just from a project-compiles-and-runs perspective? I know IntelliJ gets grumpy about it when the directory structure doesn't match the fully qualified class name, but I haven't been clear if it just thinks "this is a bad idea" or if it's a hard error.
2. Does it mess up any getResource calls? That's one place where the package name is used to determine the name of files at runtime. (In practice, it looks like there is very little in engine/src/main/resources/org/terasology.)
3. Are package-modules required for v7 of gestalt-module and gestalt-asset, or could we hypothetically stick with archive & directory modules for now and adopt the package-module strategy later?
4. What creates the requirement for all engine's code to be under the org.terasology.engine package? The "engine module" isn't sandboxed anyway, right?

[DarkWeird]

1. It is old convention package = directory. And seems it will not works properly.
2. Package moving is not resources moving.
   Mostly resource handling in gestalt-assets.
   Resourses for package module should be placed at package folder.
3. Packages module required only for engine module. Other module is directory module or archive module.
4. Engine-module should be(dependencies, and systems). It sandboxed. Engine moduld is classpath module now(detecting via classloader's protection domain)

[DarkWeird]

hehe.
Conflicts

[keturn]

Still unclear on this. Is moving files like this without changing their package something we intend to do in its own PR as this does, or does it need to be combined with other adjustments?

In any case, it has conflicts that GitHub that cannot one-click auto-resolve, so I am this as "draft" for now.

[pollend]

@keturn you would move the files first create a commit then another commit will modify those files else git will associate those as new files.

[keturn]

I understand that much of the intent, but what does that mean for this as a PR?

[pollend]

I understand that much of the intent, but what does that mean for this as a PR?

probably need to redo it since other PR's were merged. umm I guess we can't avoid conflicts.

[keturn]

an alternative option, starting from the other end: #4560

[keturn]

Notes from #4560 for when we bring this up to date:

In both engine and engine-test:

• org.terasology.engine.* → org.terasology.engine.core.*
• org.terasology.* → org.terasology.engine.*

Also undo the gradle hacks I used to make IntelliJ sort-of content with the files being in a weird place:

remove srcDirs = entirely, the defaults are fine in

Terasology/engine/build.gradle

Lines 45 to 49 in ecb5c56

	main.java.srcDirs = [
	"src/main/java/org/terasology",
	// and because old "engine" was renamed to "engine.core":
	"src/main/java/org/terasology/engine"
	];

remove the matching idea settings in

Terasology/engine/build.gradle

Lines 280 to 283 in ecb5c56

	settings {
	packagePrefix["src/main/java/org/terasology"] = "org.terasology.engine";
	packagePrefix["src/main/java/org/terasology/engine/"] = "org.terasology.engine.core";
	}

do the same in engine-test.