I am having issues using the "entity" sub generator when attempting update an existing entity.
After running:
jhipster entity <existingEntity>
..and answering the subsequent questions e.g. "Yes, add more fields and relationships", I am asked if I want to overwrite files (which I do), however one of those is master.xml. It adds 2 new entries:
include
file="classpath:config/liquibase/changelog/20170604231923_added_entity_Car.xml"
relativeToChangelogFile="false"/>
And
include
file="classpath:config/liquibase/changelog/20170604231923_added_entity_constraints_Car.xml"
relativeToChangelogFile="false"/>
This is in addition to:
include
file="config/liquibase/changelog/20170604231923_added_entity_Car.xml" relativeToChangelogFile="false"/>
And
include
file="config/liquibase/changelog/20170604231923_added_entity_constraints_Car.xml"
relativeToChangelogFile="false"/>
... which already existed (from JDL import).
They both refer to the same files. Except the new entries include classpath. Anyway, the end result when selecting overwrite and doing a mvn clean install are errors about the entity and constraints already existing (as you would expect). Am I missing a trick here? Should I be not allowing the overwrite in this case? (I had assumed this would just work).
JHipster version is 4.6.2 (I recently updated it) and I've not used the sub generator before as originally did an import from JDL studio.
Thanks in advance for any help you can give.
This has been resolved now.
I had a mismatch between the version the project was upgraded to (v4.6.2) and the global JHipster Generator (v4.6.1).
Updating the JHipster Generator version to v4.6.2 resolved the issues.
Related
When I try to use the stereotype DISCUSSION with Oracle I get an error because of the entity DiscussionComment column named "comment". Although I'm using the correct dialect for my Oracle version, Hibernate is not quoting DDL as needed. This is a very common problem with simple solution. I just want to apply the solution to OpenXava.
I tried to change the DiscussionComment source in OpenXava project (the one that comes with the OpenXava IDE). I changed the column name but it had no effect.
What and where should I change to alter the mapping of the entity?
The same problem applies to "YourFirstEntity", the demo entity of every project because of the "date" column.
Add the property hibernate.globally_quoted_identifiers to true in your persistence unit in persistence.xml
To modify OpenXava Java code, XML or i18n files:
Modify the code on OpenXava/src, OpenXava/xava or OpenXava/i18n.
Execute the Ant target buildOpenXava from
OpenXava/build.xml. It compiles the OpenXava Java code and creates
openxava.jar.
Refresh OpenXava project in Eclipse (F5).
Execute the Ant target updateOX from the build.xml of your own project.
Refresh your own project in Eclipse (F5).
reference:
https://openxava.org/OpenXavaDoc/docs/modify-openxava-code_en.html
Credits to #javierpaniza
I had a working project in Android-Studio, including Databinding. That eleminates some possible sources of error. ;-)
Then I decided to get my feet wet with Kotlin and began to migrate some classes from Java to Kotlin.
Unfortunately I also klicked to update Android-Studio to 3.4 in the middle of this process. So now I have many moving parts ...
Now after some editing, when I try to compile my app, the databinding-classes are not generated any more. Usually this is a problem of missing getters or setters or something like this. But currently I have no compiler errors that indicate such problems. Only all the references to my BR. class are red as this class is not generated.
In the layout-files the getters and setters from the data-variable are not shown - so there is a problem already there.
The build-log tells me to check the log for details, but I can not find any log with error-messages that could lead to a solution.
Android-Studio 3.4, mixed Java/Kotlin sourcecode
Besides those missing BR class, I have no other compilation errors at the moment.
I checked the raw gradle output and also tried to run those steps with the more verbose output - no luck.
Maybe this is related:
- I also have problems to edit my existing layouts with constraint-views. Somehow the constraints are read-only.
After some fiddeling around I managed to get one layout back to read-write mode. Not shure what I did to accomplish this ...
- Also I have the problem that Android-Studio "remembers" the last project and mixes the configurations from the last project with that of the current one. To fix this I have to delete the .idea folder in the project ... After that I can work with my project until I change to another or open a second one in parallel ... :-/
In order to get logs I also changed to generate the binding-classes by the compiler instead on the fly by Android-Studio - no luck.
As this is an installation with some history, I also tried to delete the configuration-files from Android-Studio - also no luck.
Clean- and Rebuild Project, Restart Android-Studio, Invalidate Caches ... all that tried without success.
Currently I am out of ideas where to look. Maybe somebody out there has a tip for me?
if you use imports in xml like
<import type="java.lang.Integer"/>
you have to delete it because android studio is imported automatically.
ref :
Just as in managed code, java.lang.* is imported automatically.
Finally I found the source of my problems!
After many attempts to find an error in my code or maybe in Android-Studio (also downgraded to 3.3 and tried the current 3.5 canary version) I decided to strip down the code to the max.
So I created a new project. In that project I created 2 observable classes and copied the minimal code from https://developer.android.com/topic/libraries/data-binding/observability#observable_objects.
I created one class in java and one class in Kotlin (with an index-Number at the properties so that I could see which properties are generated in the BR class).
Only the properties from the Java-class were generated in the BR class, those from the Kotlin class were missing. No error messages besides the missing BR-properties were generated. :-(
With this information I started a new research and finally found, that for Kotlin currently the apply plugin: 'kotlin-kapt' was missing in the project build.gradle file.
Once I added this, also the properties from the Kotlin class were added to the BR class.
Some (older) articles also add kapt "com.android.databinding:compiler:x.x.x" to the dependencies, but with the latest compiler I got null-pointer exceptions. Seems that this component is already referenced somewhere else, because it is not necessary (any more).
I also added this to my other project and now those BR-properties are also present there. So I am confident to have found the answer to my question and can now focus on bugfixing my app.
I am using Liferay 6.2 GA5 Community Edition.
Sample case I have 2 entities in my service.xml, let's say entity A & B.
When I run Service Builder then it will generate many JAVA files in my source code, and also generate JAR file located in
".\my-app\liferay-plugins-sdk-6.2\portlets\my-app-portlet\docroot\WEB-INF\lib\my-app-service.jar"
I open it with 7-zip, and I can see in package com.mycompany.myapp.model contains classes of entity A & B.
Then I try to remove entity A in service.xml, and I have removed the corresponding JAVA files generated in my source code, then I run Service Builder again, but inside my-app-service.jar, entity A is still exist.
How do I completely remove it from JAR file? because in my case, Service Builder will not remove it, although I have remove generated JAVA files manually.
ServiceBuilder is a code generator, thus it only generates new code.
If you want to get rid of the once generated code, there's a lot more than just the java classes to get rid of: Spring configuration, Hibernate configuration etc. are there as well for you to take care of. All of these will have to be deleted manually. And if the code still remains in the jar, good old ant clean (or whatever build environment you use) should get rid of the my-app-service.jar file (which you otherwise also can also just delete manually, so that it will be rebuilt next time a build process or ServiceBuilder runs)
I recommend searching for occurrences of A in all your project's files to see if you still find leftovers, because otherwise some component might complain at runtime that a declarated class can't be found.
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 trying to do a small test project using ActionBarSherlock library but having the same issue as in this post -> android-support-v7-appcompat has same attrs as actionbarsherlock library
Ref: http://pastebin.com/ERDHsQbe
Has anyone found a solution yet?
Thanks.
remove support-v7-appcompat library from your project, its in build with sherlock .
Then in the styles.xml change parent="Theme.AppCompat.Light" to
parent="android:Theme.Light" .This will be sufficient .
If you are gettin any errors related to android-support-v4 , try and copy the latest android-support-v4 into the Sherlock library folder in your workspace.
I have the same problem since I changed attributes in attr.xml file which is identical to another attributes in support-v7-appcompat library
and changing every thing related to it in the actionbarshelock project manually
I lost much of time but finally I did it
replace your ActionBarSherlock library by this one
https://drive.google.com/file/d/0B-XiEeIClMuTb2t3S0h0d2lsUUE/view?usp=sharing
the only change is in the attr.xml file and it's reflection on the java code and layouts
note : you must be sure that you have only one android-support-v4 library file to avoid jar mismatch