Current Product Module avoid Human generation with Swift

[yageek]

By setting class part of Current Produc Module, the human version of the class is not well generated.

Expected Behavior

Having the regular generation.

import Foundation

@objc(Stop)
public class Stop: _Stop {
    // Custom logic goes here.
}

Actual Behavior

Classes are generated with a . as prefix and the project does not compile.
For example:

import Foundation

@objc(.Stop)
public class .Stop: _.Stop {
    // Custom logic goes here.
}

Additional Information

OSX 10.11.5 Xcode 7.3.1 mogenerator 1.30.1

[jayjayesh]

I am facing this error too....

OSX 10.12.6 Xcode 9.0 mogenerator 1.31

[darronschall]

I am seeing this issue as well. I wanted to share my workaround in the event someone else is running in to it.

I am running mogenerator (1.31) with this Run Script Build Phase:

cd MyProject
mogenerator --swift --model Model/MyProject.xcdatamodeld --human-dir Model/Entities --machine-dir Model/Generated

I don't recall when I first ran mogenerator, but it ran OK back then. I have existing classes like Model/Entities/SomeEntity.swift with a corresponding Model/Generated/_SomeEntity.swift.

I recently had to change my data model, which meant I needed to generate the entity code again. When I ran mogenerator, it created new Model/Entities/_SomeEntity.swift and Model/Generated/__SomeEntity.swift files instead of overwriting the existing ones. Additionally, the Human classes had the leading "." in their names. The Generated classes were OK (but had the wrong file name, two underscores instead of one).

My workaround: I deleted all of the bad Human classes with the leading _ because I already had those generated correctly previously (before this bug manifested). I then copied the contents of all of the Generated classes with the leading __ into the existing Generated classes. That allowed me to use mogenerator successfully to update my existing generated code.

[johnclayton]

I've also encountered the issue, which is a problem because the generated classes are in their own framework and without the current module setting they collide with some objc names in the global namespace. Setting the @objc(name) can fix that but then screws up some other frameworks expecting the class name to match (core data is obviously using the objc runtime to get class information in places).

Xcode 10.1, mogenerator 1.32