I had to google what to do after installation to cause the auto code generation to take effect.

I found this link: http://stackoverflow.com/questions/3563145

An answer is provided by Marcus S. Zarra. I'll summarize below.

The explanation is very simple. After installing, right click your .xcdatamodel file, select "Get Info" then select the "Comments" tab. In the comments section at the text: "xmod".

The "xmod" in the comments tab is the flag that causes mogenerator to generate files. This gives you the ability to enable / disable generation per .xcdatamodel.

Hi,

First time user of mogenerator. Had troubles in Xcode 4 not knowing where to find the model comments field so I could put the "xmod" string in it? Anyway so tried to use command line in the meantime but got the following - any ideas? Are there any issues with command line usage on XCode 4 (if that makes any sense)? Not sure how one can get more log/info with the error to assist in fault finding?

Gregs-MacBook-Pro:weekendviewer greg$ mogenerator --version
mogenerator 1.22. By Jonathan 'Wolf' Rentzsch + friends.

Gregs-MacBook-Pro:weekendviewer greg$ mogenerator -m weekendviewerModel.xcdatamodeld -O mogen
Assertion failed: (model), function -[MOGeneratorApp setModel:], file /Users/wolf/code/github/mogenerator/mogenerator.m, line 432.
Abort trap

Xmod script assume that model is in a /project/path/MODEL.xcdatamodel
Then it works on /project/path/MODEL node / folder

So iIt fails with versionned models which are in /project/path/MODEL.xcdatamodeld/MODEL.xcdatamodel
because trying to work on read only bundle path : /project/path/MODEL.xcdatamodeld/MODEL

I'm currently fixing that script so it work correctly on /project/path/MODEL whatever version is saved...
Too bad I'm an AppleScript noob ;)

Grea work on the generator btw, I'm loving it, would not consider using CoreData without.
Thanks a lot.

that's it.

As one can see from Xcode's GUI for editing .xcdatamodel files, Core Data supports signed 16, 32, and 64 bit integers for attributes types. In turn, mogenerator creates accessors that return scalars for these attributes. The types returned are: short, int, and long long. These are correct for the current Mac OS ABI.

However, it would be even more correct to return int16_t, int32_t, and int64_t instead.

We once tried to make this change, but it was tricker than I thought because IIRC it assumed that there are NSNumber methods named Value, like 'shortValue' but there is no int16_tValue method.

My two computers' copies of mogenerator perpetually overwrite one another's machine files. This sounds like the definition of user error, and it presumably is, but I've ruled out the obvious explanations so far.

mogenerator 1.15 is installed on both machines, via the final package installer. 'md5 /usr/bin/mogenerator' returns the same hash on both machines. The projects live at the same path, and I invoke mogenerator by hand, using the same command. The two machines are a Mac Pro and a Macbook Pro, each with 10.6.1 and Xcode 3.2.1, sharing an up-to-date Xcode project through svn.

The machine files generated by 1.15 on the Mac Pro are identical (against unchanged entities) to those I first committed using 1.13, when I initially mogeneratified this project in September.

'locate' indicates no other copies of mogenerator on the Mac Pro, and in any case I'm now using the full /usr/bin/ path in my invocation. MD5 evidence aside, there was no change in behavior after I downloaded and reinstalled a fresh copy of 1.15 this morning.

The differences between the two sets of output span the newInManagedObjectContext/insertInManagedObjectContext change, so I effectively can't use mogenerator on the Mac Pro until I sort out the problem.

I thought I'd realize what I was doing wrong before I finished writing this out, but you're reading it, so that didn't work. Any suggestions would be warmly appreciated.

In mogenerator version 1.21, adding "xmod" to the comments of the versioned data model no longer correctly re-generate the Objective-C source files.

This is to re-open issue https://github.com/rentzsch/mogenerator/issues/issue/7 for version 1.21

I am using mogenerator 1.20 and XCode 3.2.4. I dont see any files being generated. even though I have typed in xmod in the comments section. Please help.

I have just added a new model version, and set it as current.
When I make changes I get no updates happening on the generated files.
If I make changes to the old model version and save them, I do get changes in the generated files.
I looks like it is tracking the wrong model version - it's odd as it is tracking version 3, and now I'm on 4, so it's not like its always following the first version.

Having undefined types for C-structs in the .xcdatamodel (for example a frame attribute that is intended to hold a CGRect and so is declared as Undefined -- to be supported manually) with a companion frameAsString type for allowing these C-structures to be persisted, generates primitive method names that don't compile:

• (*)primitiveFrame;
• (void)setPrimitiveFrame:(*)value;

For more information, see "A Non-Object Attribute" at:

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdNSAttributes.html%23//apple_ref/doc/uid/TP40001919-SW1

Hi

Would you be so kind to add these convenience methods to the machine-generated classes? I know that I should be able to add these myself to the *.motemplate files but I fear that if I do that it'll break my code when I upgrade mogenerator.

/* This is for type safety so that the code doesn't break in case the entity name is edited in the data model file. */
+(NSString*) entityName;

/* This is to be used for custom fetches. */
+(NSEntityDescription*) entityDescriptionInManagedObjectContext:(NSManagedObjectContext*) ctx;

Thank you.

I'm using mogenerator 1.15 on Mac OS X 10.6.1. My model contains one abstract entity with two entities that inherit from it. The output has two problems:

1. The classes for the abstract entity inherit from each other. Unit is a subclass of _Unit (good), and _Unit is a subclass of Unit (bad).
2. The inheriting entities are missing; mogenerator did not generate any classes for them.

I told mogenerator to put the underscore classes and the underscore-free classes in separate directories; all of the underscore classes, including the broken _Unit, are in the correct directory.

Apologize if this is something simple, but I can't seem to get any classes generated. I added "xmod" to my data model comment box and when I save the model I do get a generated folder with my data model's name, but no classes in it. Am I just missing something? I'm on Xcode 3.2.1, OSX 10.6.2

1/13/11 5:37:46 PM  kam[50342]  Xmod.scpt exception: Finder got an error: Can’t get folder "iOSReferenceViewer" of folder "iOSReferenceViewer" of folder "samples" of folder "reader-mobile-sdk" of disk "PDFL8".

The actual directory path is /Volumes/PDFL8/reader-mobile-sdk/samples/iOSReferenceViewer. Maybe it somehow got an extra folder in there?

Now that Apple is trying to force us to use Xcode 4, I'm in front of a problem: it seems Xmo'd doesn't work with this major Xcode release. Is there a solution for that out there? If not, are you planning on adding the support for Xcode 4 anytime soon? Can I help on that?

How do I uninstall? Particularly Xmo'd.

I am having a huge problem where xcode is not generating my compiled object models anymore and I want to eliminate any possibiity that Xmo'd is the culprit.

mogenerator failes on Lion because momc has moved to "/Developer/usr/bin/momc"
Error msg:
sh: /Developer/Library/Xcode/Plug-ins/XDCoreDataModel.xdplugin/Contents/Resources/momc: No such file or directory
/Users/wolf/code/sf/redshed/cocoa/mogenerator/mogenerator.m:259: failed assertion `model'
Abort trap: 6

Generated code for fetching supports variable substitution (FTW). However, fetch request templates which use relationships invariably use a custom class from the model. Those classes are not declared in generated header files using @Class directives, resulting in compilation errors.

Solution may require caching of prettyFetchRequests before template merge is performed so that entity class names can be extracted from fetch request bindings.

AnalysisTool (http://www.karppinen.fi/analysistool/) which in turn uses the llvm static analyzer generates warnings for mogenerated code. ex:

• (BOOL)primitiveIsLeafValue {
  NSNumber *result = [self primitiveIsLeaf];
  return result ? [result boolValue] : 0;
  }

It warns "coercion from 'int' to 'BOOL' may alter its value". Of course, there isn't really anything wrong with the code above, but the warning could be easily silenced by changing that 0 to a NO. That would fix it because the definition of NO includes a cast to BOOL.

This warning is useful in other situations but all these false positives are generating a lot of noise.

Hi,

I've been having issues running mogenerator and XMo'd. After realizing that I needed to define model classes for every entity, I ran the following command:

mogenerator --model MyModel.xcdatamodeld/MyModel.xcdataModel -M Classes/GeneratedModel -H Classes/HumanModel

The output was:
24 machine files and 24 human files generated.

However, those files are not anywhere in the file system. I ran again with the --list-source-files command, and the correct source files list appeared, but the files were still not created.

Any idea what could be causing this?

Hi,

With xmod 1.22 the output directory is created, but the files aren't. Manually creating the files by running mogenerator works, so it isn't an issue with generation itself, but the fact generation never occurs.

It appears the script is breaking on getting a xcode group:

11/04/11 1:06:37 AM steve[63136]    Xmod.scpt exception: Xcode got an error: Can’t get group id "29B97314FDCFA39411CA2CEA" of project "XXXX-XXXXXXX".

I made a new project just to test this, and Xmod failed with the same group id:

11/04/11 1:09:37 AM steve[63168]    Xmod.scpt exception: Xcode got an error: Can’t get group id "29B97314FDCFA39411CA2CEA" of project "test".

Cheers,
Steve

see title.

When messaging nil, the return values are:

Ints up to 64 bits: 0
Pointers: nil
Structs: undefined
Float, double, long double: 0.0 on i386; 0.0 on ppc 10.5 and later; undefined on ppc 10.4 and earlier

mogenerator 1.16 creates code like this:

• (int)volumeTypeValue {
  NSNumber *result = [self volumeType];
  return result ? [result intValue] : 0;
  }

The check for nil is not needed if the min deployment target is 10.5. Since mogenerator is now also unconditionally using @dynamic, 10.5 is now required, right? If so, we can remove these nil checks.

Crashfile: http://cloud.coneybeare.net/2j3w0B3q0J0L2X0b1J0m
Data: http://cloud.coneybeare.net/3h1A381Y0W040g1b411R

The crash occurs shortly after saving. My work flow was to create 2 entities by themselves, then cut/paste about 10 new entities in from another project. After rearranging and making alterations, I pressed save and in 5 seconds: crash. !00% reproducible.

While mogenerator detects Fetched Properties and adds property declarations in the header of the generated classes, it doesn't put anything in the .m, requiring me to put @dynamic statements in every time I update my entities with fetched properties.

Hi Wolf, thanks a million for this beautiful tool. Just wanted to report two types of warnings I can see in the console since installing mogenerator and copying Xmod.pbplugin manually from /Developer to /Developer3 (my install of Xcode 3.2.2 I keep for SDK 3.0 simulator). I did just that cause otherwise Xmo'd wouldn't kick while using Xcode 3.2.2. (I had also called xcode-select to the rescue to point to /Developer3, to no avail)

1. "implemented in both" : see 27 of these, one for each class in ( XDPMCodeGenerationController, XDPersistenceDocumentController, etc.)

8/14/10 1:37:08 PM [0x0-0x79079].com.apple.Xcode[918] objc[918]: Class XDDisablingTextField is implemented in both /Developer3/Library/Xcode/Plug-ins/XDCoreDataModel.xdplugin/Contents/MacOS/XDCoreDataModel and /Developer/Library/Xcode/Plug-ins/XDCoreDataModel.xdplugin/Contents/MacOS/XDCoreDataModel. One of the two will be used. Which one is undefined.

2. One 'parentEntity' is not a valid class name :

8/14/10 1:37:57 PM Xcode[918] .scriptSuite warning for class synonym in suite 'XDPluginSuite': 'parentEntity' is not a valid class name.

Apart from this, Xmo'd works for me. Not sure how safely I can ignore these warnings... I realize my plugin copy/paste approach is ugly but couldn't find another way to get Xmo'd to kick on model save in my 3.2.2 install.

If the name of a directory has an apostrophe in it then it won't generate any files (it will generate the folder, but it will be empty).

Generated files should be encoded and added to Xcode as unicode.

mogenerator always creates properties that are 'retain', which is a sensible default, but I'd like to see it able to generate 'copy' properties too.

Perhaps this could be done using the user info dictionary, like how transformable attributes can specify an 'attributeValueClassName' key/value pair.

We've been using an old mogenerator and just tried 1.16. I notice that it's still not forward declaring classes that are specified for transformable-type attributes using attributeValueClassName.

In our custom templates, we added this to solve the problem:

<$foreach Attribute noninheritedAttributes do$><$if Attribute.hasTransformableAttributeType$>@Class <$Attribute.objectAttributeType$>;<$endif$>

Could it be added?

Names were changed to protect the innocent ;)

This is happening with Xcode 3.2.5 final with iOS4.2(GM).

From the console.log, I got this:

Xmod.scpt exception: Finder got an error: Can’t get folder "ModelName" of folder "ModelName" of folder "Projects" of folder "userName" of folder "Users" of startup disk.

ModelName is the ModelName.xcdatamodel that was changed.

To solve it I manually added a folder called ModelName to the project folder, then it worked.

Additionally I had to change the applescript's permission to allow admin write permission before I got this error. Not really sure why it is opening it up for a write.

With the frequent releases of iPhone SDK versions, Apple encourage you to install newer versions in specific directories (e.g. /Xcode 3.2.2). The paths in mogenerator are hard coded to /Developer. It would be great if you could specify the Xcode installation directory.

When I run mogenerator via the command line, the generated files have the following import statements:

#import <CoreData/CoreData.h>
#import "NSManagedObject.h"

These files can't compile, and, from looking at the template, it seems that mogenerator thinks NSManagedObject.h is the custom base class, which obviously isn't the case. Any idea if I'm doing something wrong? This is the complete command-line call I'm using:

mogenerator -m MyAppDataModel.xcdatamodel -M Classes/Generated/ -H Classes/

For reference, I am using XCode 4 Preview 5, with the Clang compiler that ships with it (LLVM 2.0).

Thanks!

The files mogenerator 1.21 created don't compile, and just don't look right at all. For my three entities, I have identical contents in each of the four types of files. Here is the contents of each human-editable .h file:

import "_managedObjectClassName.h"

@interface managedObjectClassName : _managedObjectClassName {}
// Custom logic goes here.
@EnD

The computer .h files all start with this:

import <CoreData/CoreData.h>

if#import "customSuperentity.h"endif

foreach@class Relationship.destinationEntity.managedObjectClassName;
endforeach
foreachif@class Attribute.objectAttributeType;endif
endforeach
@interface managedObjectClassNameID : NSManagedObjectID {}
@EnD

my setup is a xmod dir with several models. It works fine in Xcode 3.2.5 but just doesn't run in Xcode 3.2.6

Hey there,

in my case CoreData always returns NSManagedObject objects instead of my custom ones when using mogenerator (this does not occur when generating my managed object classes by hand).
Of course I have set the class names in the model editor according to my corresponding custom classes beforehand.

I don't know if this is related, but when I first installed mogenerator and put the xmod comment in my .xcdatamodel it wouldn't generate files. Only after I generated the models from hand one time (and deleted them right away), mogenerator would start working as it should.

XCode: 3.2.4
mogenerator: 1.20

Cheers,

Sebastian

Using 1.8 on my versioned model is causing this to be output into Console:

7/1/10 10:13:41 AM  [0x0-0x149c49b].com.apple.Xcode[6290]   /Developer/Library/Xcode/Plug-ins/Xmod.pbplugin/Contents/Resources/Scripts/Xmod.scpt: 
7/1/10 10:13:41 AM  [0x0-0x149c49b].com.apple.Xcode[6290]   execution error: sh: -c: line 0: unexpected EOF while looking for matching `''
7/1/10 10:13:41 AM  [0x0-0x149c49b].com.apple.Xcode[6290]   sh: -c: line 1: syntax error: unexpected end of file (2)
7/1/10 10:13:41 AM  ReportCrash[8576]   Saved crash report for mogenerator[8574] version ??? (???) to /Users/justin/Library/Logs/DiagnosticReports/mogenerator_2010-07-01-101341_Bodhi.crash

Howdy Wolf - You know how much I already love this solution, but I'm having a small problem: My header files are not automatically added to my Xcode project on regeneration - is this expected behaviour?

I was using Xmo'd and mogenerator successfully with Xcode 3.2.3 until I added a parent entity to several of my entities. Now nothing is generated and I see the following in the console. Google has been unhelpful in finding any reference to this error message, so I thought I'd post a bug. Seems to be Xmo'd rather than mogenerator (but that could just be my misinterpretation)

22/07/2010 12:07:29 Xcode[21793]    .scriptSuite warning for class synonym in suite 'XDPluginSuite': 'parentEntity' is not a valid class name.
22/07/2010 12:07:29 ReportCrash[21841]  Saved crash report for mogenerator[21837] version ??? (???) to /Users/acf/Library/Logs/DiagnosticReports/mogenerator_2010-07-22-120729_CardboardMac.crash
22/07/2010 12:07:29 [0x0-0x403403].com.apple.Xcode[21793]   /Developer/Library/Xcode/Plug-ins/Xmod.pbplugin/Contents/Resources/Scripts/Xmod.scpt: 
22/07/2010 12:07:29 [0x0-0x403403].com.apple.Xcode[21793]   execution error: sh: -c: line 0: unexpected EOF while looking for matching `''
22/07/2010 12:07:29 [0x0-0x403403].com.apple.Xcode[21793]   sh: -c: line 1: syntax error: unexpected end of file (2)

How to reproduce:
Add a relationship to an entity and leave the Destination set to "No Destination Entity". Save model and run mogenerator.

What I got:
Assertion failed: (model), function -[MOGeneratorApp setModel:], file /Users/wolf/code/github/mogenerator/mogenerator.m, line 430.
[1] 32505 abort mogenerator -m Plex.xcdatamodel

What I expected:
An error message like [MyModel].xcdatamodel:[EntityName].[RelationshipName]: error: [EntityName].[RelationshipName] -- relationship does not have a destination

Rationale:
I never would have guessed the issue if XCode hadn't given me a "destination entry can't be nil in relationships" error when I later attempted to build. That assertion message isn't clear to anyone who isn't looking at the mogenerator code.

Hi,

I'm having an issue with using fetch requests causing mogenerator to present the following error:
mogenerator -m ./Resources/DataModel.xcdatamodel/ -O ./Classes/Managed\ Objects/
/Users/wolf/code/github/mogenerator/mogenerator.m:80: failed assertion `relationship'
Abort trap

This seems to come down to creating a fetch request that uses substitution variables in combination with a request that gets the LHS from a relationship. So this causes mogenerator to fail: user.username == $username, wheras this does not requestIdentifier == $request_identifier. I'm not too good at explaining technical details so I have uploaded a screencast so you can see what I am on about. The screencast is available here: files.me.com/insertjokehere/qa9jg7.mov

Hi, I'm running mogenerator 1.19 with Xcode 3.2.3 on 10.6.4.

The source files are being generated correctly, however, they're not being added to the "Compile Sources" group of the main executable target.

Any ideas as to what might be causing this? I've checked the Console and the only error I see there is "osascript: couldn't save changes to /Developer/.../Xmod.scpt: Permission denied"

Thanks!

One thing that seems to burn me often is giving one of my Entities an attribute with a name that clashes with the other methods in Cocoa.

It would be cool if mogenerator gave me a warning that although I have an attribute named description the class mogenerator will create will have a method that will collide with NSObject's -description.

I've seen similar issues with -name -type -value and a few others.

Please make a homebrew formula for this.
https://github.com/mxcl/homebrew/wiki/Formula-Cookbook

Check out how Homebrew installs things. It installs command-line tools like RVM, except for all command-line tools, not just Ruby. It installs everything to /usr/local, which is owned by me. So, I never have to enter my root password. And, it has a strict policy of not modifying files outside of /usr/local. So, to remove homebrew and everything I've installed with it, I can just do rm -rf /usr/local. (But, there's a brew uninstall command to make this easier and just allow you to uninstall certain command line tools.)

Thanks!

Hi,
Im new to using xmod and have found serch entries about a previous bug with xmod not creating folders etc but cant find a fix.
I have given the plugin 777 permission, the script does create a folder withing the folder where the datamodel file exists with its name but the folder is always empty.
Is there something else I can try?
Cheers

Running mogenerator with 3.2.3 and when I save the model I get the following error in the console.

7/2/10 10:05:23 AM [0x0-0x5a75a7].com.apple.Xcode[33556] osascript: couldn't save changes to script /Developer/Library/Xcode/Plug-ins/Xmod.pbplugin/Contents/Resources/Scripts/Xmod.scpt: Permission denied

When you have added a version to your Core Data model (Design > Data Model > Add Model Version), automatic entity generation using the 'xmod' comment text stops working.

It's not exactly clear to me whether this should work, is still unimplemented, or whether the 'xmod' comment tag should be placed elsewhere (for example on the .xcdatamodeld directory?).

Any experiences with versioned models and auto-generating classes?

I understand that XCode 3.2.1 prevents the very cool automatic Applescript from working. I have tried to run mogenerator from the command line on my project by:

mogenerator <my_data_model>.xcdatamodel

and I get the result:

0 machine files and 0 human files generated.

I can't find any documentation that would suggest some other incantation. Should this work with Snow Leopard 10.6.2?

This looks like a great utility - thanks for creating it.

I have noted when migrating from the XCode4 generated classes to mogenerator, that for mogenerator, I now get more warnings for the cases where I have a "Transformable" attribute in my core data model. For example a NSDateComponent.

In the XCode4 auto-generated header it would look like:
@Property (nonatomic, retain) id weStartDayTime;

In the mogenerated header it would look like:
@Property (nonatomic, retain) NSObject *weStartDayTime;

Mogenerator seems to use "NSObject" as opposed to "id" - I'm not an objective-C expert however the end result is that with mogenerator I get the following warnings:

NSInteger endPeriodDay = [self.weView.weEndDayTime weekday];
// WARNING: 'NSObject' may not respond to '-weekday'

// WARNING: Initialization makes integer from pointer without a cast