I have a question about flyway migration folder . Does sql's have to reside in project folder Application/foo/bar/main/resources/db/migration. Could it reside outside of the application cource folder?
We are using Maven.
By default Flyway will look for migrations on the classpath under db/migration, which on a Maven project means src/main/resources/db/migration.
You can however also use a location starting with the filesystem: prefix that can be anywhere on your disk.
See the ”Location and discovery“ section of the SQL-based migrations documentation page.
For command-line use, see the locations option on the migrate command reference page.
Related
Visual Studio now generates Dockerfile for dotnet projects, and we are using it (with slight tweaks) for our continuous integration.
However that Dockerfile does not have any provision for configuring nuget. It even only copies the .csproj file from context before running dotnet restore to avoid re-running that step during development.
But our project requires some modules from internal, password-protected repository, so I need to provide package sources and credentials to the dotnet restore command inside.
What is the best current practice for injecting a (environment-specific) nuget configuration?
This is documented here: https://github.com/dotnet/dotnet-docker/blob/main/documentation/scenarios/nuget-credentials.md.
To summarize, there are a variety of ways in which this can be done:
Use a multi-stage build to protect nuget.config that contains hard-coded credentials. Only recommended if you ensure that credentials are kept out of source code control and the nuget.config file is ephemeral.
Passing secrets by file with BuildKit. This is similar to the previous option but makes use of Dockerfile secrets to provide access to the nuget.config file.
Use environment variables in nuget.config. In this scenario, the nuget.config file would reference environment variables for its credential values. The environment variables would then be set by the build machine when executing a docker build.
Use the Azure Artifact Credential Provider. This is only possible if you make use of Azure Artifacts for your package feed.
No matter which option you choose, be sure that credentials are never stored within an image layer that is published.
I'm using Fluent Migrator 1.6.2 in my .Net application.
For migrating up or migrating down the database, Migrate.exe needs to be executed by passing assembly file (the dll file of the database project in which the migration classes exist) from the command line.
And by default, Migrate.exe file gets created inside \packages\FluentMigrator.1.6.2\tools folder.
I want both these files (Migrate.exe and DbProject.dll) to be created inside the same folder.
Is there any configuration setting in fluent migrator by which I can control the location at which Migrate.exe file gets created and create it inside my DB project?
No such configuration exists. You however, can set a specific folder in your solution, where you copy the Migrate.exe file and other needed files, then set the properties of your Migrations project, to build to said folder, resulting in binaries generation every time you build the application.
Recommendation here is to have the migrations in their stand alone project inside your solution.
Follow up to this question:
Application Insights added ConnectedService.json file to my project, what does this do?
When I create a deployment package, via "Publish..." option, the package also include the following folder and files:
Service References\Application Insights\ConnectedService.json
I do not want to deploy something that is not required at runtime. Do I have to include the folder and file in my production server deployment?
No. Those files are only used by visual studio for its information, to know what services have been added and give you links back to them inside VS. None of that needs to be deployed. those files can all be set to do not copy/etc.
I am deploying a spring-mvc application which uses JPA to access MySQL database. Access information is stored in persistence.xml, while creating a deployment war file I would like to replace developer persistence with the production one.
I tried to copy the production xml directly into the deployment folder (intellij settings), but it has no effect a dev. copy is always deployed.
How do I configure IDE to do that?
If your project is mavenised, then you can use the maven-war-plugin or maven-resources-plugin to customise the resources used to build the war, and the ide should honour these plugins.
I've been using Eclipse indigo with m2e and m2e-wtp installed.
I created a dynamic web project using m2e by selecting maven-archetype-webapp. Now the problem is, I could not see src/main/java, src/test/java and src/test/resources in the created structure. Here is a snap of the project.
I stumble around and found this link. I created required directories on file system. Now the question is ideally where should I add "Source Folder" for each directories(src/main/java, src/test/java and src/test/resources)? Should I add them under "Java Resources" or somewhere else?
Thanks
That's exactly how we do it.
src/main/java, src/test/java and src/test/resources
under java resources -> new source folder
Don't forget to add your src/main/java path and the maven dependencies to the deployment assembly of your project if you want to run the web app from eclipse via tomcat.
EDIT
Concerning Eclipse Deployment:
If the project is already facetted as a Dynamic Web Project like yours, you'll need to add a Server in the Server view (We use Tomcat 7 and reference a local tomcat copy in the server setup)
Then you add the web projeect to the server (add/remove on the server)
In the project properties you'll need to add the src/main/resources and src/main/java folders to your deployment assembly as well as the maven dependencies.
We also use a src/main/webapp folder instead of the webcontent folder that is automatically created. This holds the web resources, WEB-INF and views and will be added to the deployment assembly as well and mapped to the root path '/'
Now you'll run an install on your app and then select 'run on server'
Just after the creation of a web application based on the archetype 'maven-archetype-webapp', it is perfectly possible to run the wep application in making usage of 'run as' on Tomcat (by example). You have right to a jsp page, index.jsp.
But if you want like many others create a servlet then you have a problem. The build path of the projects references 'src/main/java' and 'src/test/java' but the directories do net exist yet. I don't know why they forgot to create the directories (within the archetype)...
To correct the problem, you 'simply' have to create the missing directories (from the explorer) and then from Eclipse do a right-click on the project name and then click on 'Maven' and then 'Update Project'. If you create the directories this way you will see that the source directories (src/main/java and src/test/java will appear again).
Then create a new servlet (by example) in src/main/java and deploy the application again. Everyting will work this time.