According to the documentation, after entering fields the wizard should ask me about relationships. Instead it skips this step entirely and just goes ahead and creates the files. I'm sure this used to work but I don't see what I could have done to break it?
I'd be happy to provide more info but not sure where to look.
Rather embarrassingly I've found the solution. It's been a few weeks since first installing jHipster and beginning to really try creating entities. I created a couple of simple ones to begin with and then played around with it to work out how I was going to use it.
Now I'm ready to start generating entities I looked at the website again and it says about these relationships. I think this is a new feature that has been added since I first installed jHipster though.
In the end I ran this
npm update -g generator-jhipster
And then when I tried to create an entity I got the question about relationships. Not sure if I need to somehow update my project to the new jHipster version now too.
How to update the JHipster project after updating JHipster generator?
Related
I'm new to jhipster, and have created a JDL file for Entities in my service using JDL Studio.
My goal is to keep iterating on my DB design, using JDL Studio, and then run the service so I can see the Entity screens that jhipster has created. How should I do this?
I have reviewed the docs on database updates, but I find it doesn't lay out this common development task clearly - wanting to iterate on a DB design. I see suggestions fo using jhipster entity ... but does that mean JDL Studio can only be used at the start of development?
My current process I'm hoping will work in some fashion is this:
Make changes to my entities in JDL Studio
Download changes to entities.jdl
run jhipster import-jdl entities.jdl
Tell it to overwrite everything - I have no customizations to the code yet in anyway.
Try and run the service using ./mvnw
I currently have very little code that is custom so far, and what I have is committed to git, so I can diff/revert changes if need be.
The problem is that I see to get conflicts, or the app breaks and won't compile, around things that seem related to the entities not being updated correctly. I'm perfectly fine with overwriting everything to just get the updated entities, and front end files
I've tried removing node_modules, target, and .jhipster/* files to see if I could cleanly recreate the entities, but it still has conflicts.
Note I'm only using H2 at this point, and don't plan on using liquibase/a real db until I actually release something, so probably months from now. Thanks!
As suggested in the question comments, the basic process is as I listed in my question. I think there were 2 things that solved my problem
completely removing the src folder, and allowing it to be regenerated
supplying both my JDL files at once on the command line.
I have 2 JDL files, one for entities, and one for relationships, which I broke out separately while trying to figure out how to best do these updates. I was running them separately as well, which worked fine for the entities JDL file, but wouldn't for the relationships one, as it needed the entities too.
So my solution seems to have been the following:
cd my_project
rm -fr src target
jhipster import-jdl entities.jdl relationships.jdl
If I found my entities weren't being regenerated, I also deleted the .jhipster folder, but not sure if this is required or not
rm .jhipster/*
Once again - I am completely new to jhipster, so there may be better processes, but this seems to have resolved my issues !
I'm making app with using Xamarin.forms. (PCL Project)
Today, I added new three solution packages named SVG.Forms.Plugin.Abstractions, SVG.Forms.Plugin.iOS, SVG.Forms.Plugin.Android on workspace that downloaded from github.
I have used realm for Xamarin.
But After I added new packages, "Realms.RealmException has been thrown".
Message is "Fody not properly installed. allbX.Baby is a RealmObject but has not been woven."
Is it Fody's problem or Realm's or new packages'(SGV Control)?
And could you let me know how to solve it?
Better Answer
The check which is delivering that message is because Fody is not running.
So, they may have a RealmObject in their component but Fody doesn't get run building in your solution so weaving doesn't occur.
The easiest fix is to just use NuGet to add Fody to your main application project. That should install it in the right place for the solution.
Background
NuGet manages dependencies so if a package relies on Realm, it will go on in turn and install Realm. Realm itself relies on Fody, for example, so will in turn trigger a Fody installation.
You can manually install Realm but it is a little fiddly, having to add a couple of lines to your csproj to specify imports. We have chosen to only document installation via NuGet at this stage.
If you want to manually add Realm to another solution without using NuGet, I suggest you take a new clean solution, save a copy, and diff with the changes made to that solution by adding Realm via NuGet. You will then see the lines to copy into your existing solution.
i'm newbie in JHipster and i'm trying to figure this, when i create a new entity JHipster generates several files, angular, html and java classes, now if i want a common code for all this generated code i must edit each time that i use the yeoman generator? what i want is:
Custom Index template, and pages, is secure to edit them?.
Customize the entity tables, entity forms using angular, maybe extending yeoman generators
Customize generate java classes, maybe i think using AOP
So i need to edit each time for each generated code? and is a good practice this or what i want? for clarify more i want to use a Custom Bootstrap/angular Dashboard template like Minovate, i see how to customize bootstrap in the documentation but not about what i'm asking for, Thanks.
JHipster is just a code generator, once generated the code is yours.
For angular screens I would say do as much as you can in CSS/SASS.
But it's very likely that you will need to build some screen mixing several entities and change the structure of entity screens.
So you should rather consider them as a starting point and do your own stuff in another folder so that it does not get overwritten by next re-generations.
This way you can still update your entity definitions in .jhipster folder and re-run yo jhispter:entity <entity name> on the entities you modified.
Customising java Entities is usually much simpler and you can easiliy achieve this by merging generated code with git and defining your service classes.
AOP seems overkill here.
Extending a yeoman generator is a lot of work.
I suggest to use some VSC (git, subversion or whatever you like) have a branch dedicated to plain jhipster generated code and another one where you make customization.
Eventually regenerate on jhipster branch and merge back on yours.
You should at least reduce manual intervention.
Good day,
I have an app with CoreData that is in the Apps Store. I have now coded some
cosmetic changes in the interface without changing anything in the CoreData model.
I did not add/delete/or change any entity or property. Now, I am ready to upload my
version 2 of the app. I am unsure whether I have to do anything so that the old data
of the users in the first version will not be deleted but will be saved in the
new app (with exactly the same CoreData model). Please be tolerant with this noob.
Great thanks,
Romeo
When someone installs a new version of an app they already have, all the app's data stays where it is-- it doesn't get deleted.
Whether this data is compatible with the new version is a different question. If you haven't made any changes to the data model, then it should be fine. But you should make sure. Testing the upgrade process is one of the most important parts of testing a new version of an app. Install the current version, generate some data, and then install your new version and make sure everything looks OK. As you describe it, there shouldn't be any problems, but you should never just trust that this is the case.
In Marcus Zarra's Core Data Migration Course on iDeveloper TV, he suggests manually locking your xcdatamodel file so that you can't accidentally make updates to it and force a migration when you didn't plan it. But I agree with Tom, test it first.
iDeveloper.TV Core Data Migration
I've run the Update-SPSolution command which I am guessing has worked as I have no errors returned. However, my extra feature in the WSP file doesn't show in the site collection features.
I've never really upgraded a solution I've always done the long winded retract it all and then reinstall. This is possibly down to my lack of understanding and I have been told upgrading can be sketchy by several people I have worked with.
How come the extra feature hasn't shown up in my collection features?
Does the upgrade solution only replace the WSP file and then you need to run the install command again?
If anyone could point out some decent articles on this it would be hugely appreciated.
I have managed to get the feature installed by re running the install solution powershell command and it seems to have worked!
However is this best practice? I can't see any detrimental affect of doing it this way currently!
You would need to run the Install-SPFeature command after the Update-Solution to install the newly added feature. http://technet.microsoft.com/en-us/library/ff607825
From my experience I use Update-SPSolution only when I need to deploy an updated dll for the whole existing solution (wsp).
If you updated other files or added a new feature then these changes will not be available, as update doesn’t instantiate manifest file to make your new feature available.
To "really" update solution you need to write an "UpgradeActions" as described here.
http://msdn.microsoft.com/en-us/library/ee535723.aspx