A while back I generated a project with JHipster Registry, among other things (let's call it conf1). After a few months I realized I don't need it and changed everything I need to so my project would work properly (this one will be conf2) and it work as expected.
Now, every time I want to upgrade my project, JHipster generates everything based on config1 instead of config2, which means my changes to get rid of anything I don't want, for instance JHipster Registry, get overridden by the upgrade.
So my question is: what do I need to change so that every time I upgrade to a new JHipster version, I don't get it done based on config1?
Deleting the jhipster_upgrade branch solved the issue.
Related
for the first time I updated an app with the jhipster upgrade command.
It seems all ok but at the end of the updating it noticed me about three conflicts that I have to resolve manually.
My first problem is: how to update the Liquibase scripts?
In this case, have been added some uniqueConstraintName but I can't to add them in my scripts because they have already been executed.
So, which is the best solution? Don't update the scripts? Mark them as merged? Add manually another script in order to add these constraints?
And how I have to solve other conflicts like the image below?
Simply copy and paste from new file to old file?
Thanks a lot,
Andrea
If you have a live database, then you must not upgrade your liquibase scripts but add new ones to do the migration. What you can do is running the new scripts against a blank dev database (same type of db as prod), then revert to old scripts, then call ./mvnw liquibase:diff to get the delta script, then add the delta script to the scripts to run.
I have an Azure Web application that I checked into TFS yesterday with no issues. Upon checking in, the resource manager will inject our nuget packages and deploy if it builds successfully.
I made a few changes (added a class) and checked in today. I received this error on the build:
Here's the quote to help the future search bots:
Exit code 1 returned from process: file name 'tf', arguments 'vc unshelve Gated_xxxxxx;****** /loginType:OAuth /login:.,******** /noprompt'.
I looked into the log response, to see if I get more detail, but it says the exact same thing. I have not changed my password or username.
How can I debug this to figure out the issue?
UPDATE
To save others from the headache. The issue was that we had CI builds per project. A file from another project had snuck in as well. So I was checking in for 2 different projects on 2 different solutions (Which both go to the same TFS server). So make sure you only check in for that one project!
To save others from the headache. The issue was that we had CI builds per project. A file from another project had snuck in as well. So I was checking in for 2 different projects on 2 different solutions (Which both go to the same TFS server). So make sure you only check in for that one project!
You can receive that error as well if you try to check in a file that is in a project that is not mapped in your build definition.
Let's say that you have a file named FileA.cs that is in a project named ProjectA.csproj. If you do changes in FileA.cs and this file is included in your changes, you need to map ProjectA.csproj in the Get source step of the build definition.
When building a new version of my application, it's possible that files that were needed in a previous version are no longer needed. I would like these to be cleaned up during an upgrade. My ideas so far:
I considered using the InstallDelete, but this would require the current build to know what files the previous build contained. The build process is automated, and I'd prefer that the build didn't have to check in anything. (It makes tagging and the like rather messy.)
I also considered running an uninstall, but this would mean that the upgrade could not be fully rolled back (since the application would have been uninstalled).
Is there a way to detect files that were present in the old install but not the new one during the install and to have Inno delete them in a way that could be rolled back (or that happens only if the install was successful)?
I've been playing around with how I want to setup my upgrades for an application install I'm creating using Installshield, using basic MSI projects.
I don't support any additional features/components and most of the upgrades will just be files/folders being added/removed from the default component.
I seem to be having difficulty in removing files/folders when creating an upgrade. I create my upgrade by copy/pasting the original setup.ism (i.e Version 1 of my install), so that I have all the files/folders of the original install, and then I just add/remove any changes. Is this correct? or should the upgrade.ism only contain newly added/removed files folders?
I first tried a Minor upgrade. I figured out how to remove files (right click - delete, and then add an entry to the RemoveFiles editor), but I haven't figured out how to remove folders. I don't want to have to manually add each file to the RemoveFiles table as there is likely to be hundreds of them. How can I have an upgrade remove a folder and all its children?
I've also tried the Major upgrade, which is very easy as I don't have to worry about removing files/folders due to it uninstalling first. But then I don't get the dialog that informs the user that it is actually an upgrade.
You can use your Action property defined in the UpgradeTable to detect if a major upgrade is occurring a present different UI elements to your user.
Most people will never need minor upgrades and/or patches. For most applications the major upgrade is the simplest approach to maintain and the downside of shipping the entire package is minimal. It's only for really large installers shipped to thousands or millions of customers this becomes an issue.
To remove a file during a minor upgrade you need to 'puncture' the component. You author it as transitive (InstallShield condition reevaluate=true) and give it an expression that always returns false. Checkout:
Uninstall a component during minor upgrade
Your approach of removing the component and authoring a rule in the RemoveFile table is incorrect. This breaks the component rules and reference counting.
It's a good idea to learn how minor upgrades work and what you can and can't do but don't be surprised if you find yourself leaning on major upgrades more.
I have an app that I have been working on and I did a bunch of changes and then realized later I should have been adding versioning to the Core Data model. So I'm trying to go back and do that now.
Basic information:
I think everything I've done would fall under the lightweight migration feature.
I'm using git
I already have the app in user's hands
My question is: what is the easiest way to do this?
Since I'm using git, could I simply checkout the data model from when I submitted it to apple, create a new version for it, and add my changes? My main fear with this idea is that my project.pbxproj file would be incorrect. Would this an issue? Is there a way to get around this?
IF I could do this, would I need to recreate my class files or would that be ok (assuming I get it back to being identical to what I currently have).
IF I CAN'T do this, then what can I do? If its a matter of starting from the last version I pushed to Apple and applying changes I guess I should look into doing it with git rebase, right?
This has nothing to do with git.
You need to create a new version of your app, provide the new data model, set it for lightweight migration and then release it as an update. Core Data will basically assume that any model without version info is version zero and attempt a migration to the new version.
When the user downloads the update, the automatic migration will trigger the first time the app runs.
Creating a new version means nothing more than changing the version number in the project info. When submitted, that will trigger the upgrade and the migration.