The Bixby Import and search template uses a library module textLib which throws an error due to the library having been deprecated. The template uses a javascript file named "transaction_util.js" that requires the library via var textLib = require('textLib'). The library contains functions that were used for various text-related functions for fuzzy matching.
Is there a replacement module or a workaround for this?
Sorry for the inconvenience. We had an emergency update to the template capsule. You can try it now and should use externalTextLib which is included in the template.
If you already started your coding, you may want to create a new template capsules, copy and paste code/lib/externalTextLib.js to your existing capsule and change the line to var textLib = require('externalTextLib'), which should work without any additional coding change.
Or start a new project with the new template. It might be a safer option.
If I open a Kotlin project and try to create my own template for JUnit Test Classes I get the generated template generated as a Java file instead of as a Kotlin file.
Is there any way to make this generation to happen as a Kotlin file?
I attached some images to easily show the issue I am facing.
The question marks on one of the images have to do because I don't know what that default parse function does. I tried to change it to #parse("File Header.kt") but that does not work.
The issue was I was trying to add kotlin code to the template.
All I had to do is create the template using Java code and it automatically gets generated in Java.
However, if anyone know a way to specifically use this feature using your own kotlin code instead of generated one, please let me know.
I have an Android project (I'll update soon with the source once public) that has code in Kotlin.
When I try to import a class it shows on the auto-complete but then it does a full name reference instead of adding the reference to the class on the imports of the file. Also, when I try to do an import, there is no option to include the import to the class.
It's happened so far in two projects I've worked on. The first one had a mix of Java a Kotlin and I thought that may be the issue, however, the last one doesn't have any Java code.
The code is in the debug configuration. However, a file that is on the same package and folder as this one with the issue doesn't seem to have the same problem and imports work as expected.
Update after duplication suggestion
This was marked as a duplicate, but it's not for several reasons:
This one involves Kotlin and not Java
The reported problem was with project imports, this is a library (system) import
Tried the suggested solution and it doesn't solve this issue.
This one has a gif ^_^
Best what you can do it build new Empty Project and copy old classes and files on new project.
I'm trying to generate NSManagedModels from my datamodel. Generation works but after I got many errors :
error: filename "Station+CoreDataProperties.swift" used twice:
'/Users/Me/MyApp/Models/CoreData/Station+CoreDataProperties.swift' and
'/Users/Me/Library/Developer/Xcode/DerivedData/MyApp-gwacspwrsnabomertjnqfbuhjvwc/Build/Intermediates/MyApp.build/Debug-iphoneos/MyApp.build/DerivedSources/CoreDataGenerated/Model/Station+CoreDataProperties.swift'
:0: note: filenames are used to distinguish private
declarations with the same name
I try clean build folder and derivedData directory hard delete. I'm using Xcode 8 BETA maybe it's a bug ?
I get this in Xcode 8.1
For me following steps solved the issue. Please note that order matters.
1) Create entity in Core Data model.
2) Under class section, make settings as on following image.
Module: Current Product Name
Codegen: Manual/None
3) Generate your NSManagedObject subclass.
This post greatly helped me solve this problem myself. Personally I look at this as an Xcode bug. Bug or not this is a huge chicken and egg situation.
I ran into this by:
Created a new Project using Core Data
Generated my NSManagedObject subclass+extension (while codegen: ClassDefinition)
I accidentally saved the generated classes in the Wrong folder
I deleted the generated files
Re-generated in folder I wanted
đź’Ą- Xcode used twice errors
As others have posted I kept cleaning my build (and clean build folder) but that never fixed the build issue.
I finally figured out if you originally created your NSManagedObject generated classes with codegen: ClassDefinition, as I did without knowing then you are locked in for the chicken and egg issue.
I then deleted the auto generated classes thinking I had to re-generate, so I did. Once re-generated I would get the used twice build error again. I manually went into the ../DerivedSources/CoreDataGenerated/Model/.. and deleted the duplicates. Again, I re-generated thinking I'd only have 1 copy (in my project) but I was wrong. If codegen: ClassDefinition was originally set then Xcode will keep creating the auto-generated classes+extensions and put them in the buried folder ../DerivedSources/CoreDataGenerated/Model/... I repeated this chicken and egg a few times before catching on.
I later realized you do indeed need to mark codegen: Manual/None however to get things back in sync you need to delete the auto-generated files in ../DerivedSources/CoreDataGenerated/Model/.. and in your project if you have any there still.
Be careful setting codegen: Manual/None, for me it was bit tricky because codegen: Manual/None wouldn't stick. I had to click back and forth between entities multiple times to double/triple check each entity was set to codegen: Manual/None. Then auto generate the files. At this point your only copy of the auto generated files should be in your project and not in ../DerivedSources/CoreDataGenerated/Model/...
Last, I think this is a bug because if you specify codegen: Manual/None I don't expect Xcode to auto generate files at all, yet it does and puts them in your project. More confusing if your setting is codegen: ClassDefinition, who the heck knows Xcode will put the files in a buried directory yet it is available for use in your project. My beef with this is the auto generated files aren't source controlled and if I change computer I have to know to auto-generate them on the new station.
Hope this helps someone else!
Cheers!
This is indeed not a bug. As #Morrowless suggests both class definition and properties extension are created. If this is not wanted, select Manual/None under Codegen before generating the code. If the code is already generated, just delete them, and try Editor->Create NSManagedObject Subclass... again from the menu (after setting Manual/None).
Note, in the picture below, the Class Name 'Contact' is specific to my project. You will see your entity name instead.
If you generated CoreData subclasses with codegen: ClassDefinition your basically screwed. The only way to fix it is to:
Delete your CoreData subclasses.
Delete your derived data folder.
Clean your project (CMD+K).
Generate new CoreData subclasses, this time select Codegen: Manual/None and Module: Current Product Module
This is not a bug. Codegen generates these files in the DerivedData folder, so you don't need to create them again in your project, hence the compile error.
From Xcode 8.0 Release notes:
Xcode automatically generates classes or class extensions for the entities and properties in a Core Data data model. Automatic code generation is enabled and disabled on an entity by entity basis, and is enabled for all entities in new models that use the Xcode 8 file format. This feature is available for any data model that has been upgraded to the Xcode 8 format. You specify whether Xcode generates Swift or Objective-C code for a data model using the data model’s file inspector.
When automatic code generation is enabled for an entity, Xcode creates
either a class or class extension for the entity as specified in the
entity's inspector: the specified class name is used and the sources
are placed in the project’s Derived Data. For both Swift and
Objective-C, these classes are directly usable from the project’s
code. For Objective-C, an additional header file is created for all
generated entities in your model. The header file name conforms to the
naming convention “DataModelName+CoreDataModel.h”.
However, if you selected Category/Extension under the codegen pulldown menu in the data model inspector (because you want to add logic to your model): codegen will wrongly generate both the class definition and properties extension.
The solution is to simply delete the properties extension (ClassName+CoreDataProperties.swift). Your project should now compile.
After following the guidance from oyalhi and Vladimir Shutyuk, (deleting the NSManagedObject files, changing the entity codegen to Manual/None), I had to restart Xcode to allow it to index again before I could re-generate the NSManagedObject files and get a successful compile.
For the sake of completeness..:
I just ran into the same error, but none of the proposed solutions worked. What puzzled me was that even switching from automated code generation to manual for the one (as I thought) problematic entity didn't do anything.
Finally, I figured out that I had several entities with the same name, but they all shared the same classname. The reason for this was that I copy&pasted one entity several times to save me some work, because they also have a few attributes in common.
Turns out XCode renames the duplicates by adding 1, 2,... to the entity name, but leaves the class name as before. And since now entity name and class name are "unrelated", renaming the entity won't change the class name either.
Hope it helps someone - I have also filed a bug report for this.
I am using a UI component from J2ME Polish. I found a simple bug in the code, and want to quickly fix it but cannot find any build scripts in the download package, although source-code is included.
The problem cannot be solved by extending the class as it involves members with private access.
How should I go about fixing it? Should I simply compile the class in question with Javac or should try to locate build script in their repository?
There is no binary code for J2MEPolish UI library, because these classes are also preprocessed during your application compilation. This is why there is also no build script for J2MEPolish UI part - the resulting binary, if it compiles, would not make any sense :)
If you are using this UI class directly (there is no Polish magic involved) I would suggest to copy it into your own project, make the changes there and you should be just fine.
But there is a small issue. I'm not 100% sure, but Polish build process should be as follows: first your classes are preprocessed and then Polish classes will be preprocessed. If the UI component, that you copied into your project, will stay in the same java package, it could happen that your changes will be overwritten by buggy Polish implementation. You can check it by running the application or looking at the final java code in build directory.
If the overwriting problem happens, then you have two options - move UI class in your project into different package (I'm 99% sure this should be fine if you use it directly) or you need to modify Polish build process, so that it would preprocess Polish classes first and you could overwrite changes done by it.
/JaanusSiim
I know this question has been answered and accepted but an easier method would be to used their built in property (for any one coming here via the magic search engines)
polish.client.source=/projecthome/j2me-polish-source
which is simply a copy of their sources packaged with the installer. You can copy this into your own source tree and thus have version history of your changes.
While JaanusSiim's method might work I would not recommend it as it becomes confusing having de.enough.** packages in your own source tree I normally create a src for my personal source and a src-j2mepolish for their source files this was it is VERY explicit what I have added to the standard versions.