So we have a project that is basically nothing but test files and other projects depend on it to run tests. Problem in the past has been that these items are being unpacked in locations outside of the target directory. That means you end up with modified files and new files, none of which are committed. The files are XML and are used to generate other files. What is the Maven standard location for these files? I'm looking here and I don't see anything that jumps out at me as a conventional location. I can wing it, of course, but I'd prefer to use a standard if it exists:
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Properties+Guide
I'm considering this location:
${project.build.directory}/generated-test-resources/resources
The standard directory for test resoures like xml files is:
/src/test/resources
The way to include these test-only kind of projects is by using test-jar as described here.
Related
I have a simple question (documentation does not seem to provide a straightforward answer).
I am trying to copy over various resources (images in this case) while running an asciidoctor gradle task.
The directory structure is not the best, meaning that the adoc files and the assorted images are not logically placed but this is something that I cannot change.
I am trying to find a why to do so and I stumbled across the resources option of asciidoctor. Now my main question is how can I configure it correctly in order for it go through all the directories in the base directory and copy over whatever is not a .adoc file over to the target directory (while maintaining the same folder structure)?
Probably you don't need it anymore, but for anyone interested:
The solution is now described in 'Processing Auxiliary Files' section of Asciidoctor Gradle plugin docs.
Here you can see example:
resources {
from(sourceDir) {
include 'images/**'
include 'resources/**'
include 'some_dir/**/*.png'
exclude 'other_dir/**/notThisOne.png'
}
}
If you have a gradle-script anyway, you could use gradles copy task. Just define all sources of your images and copy them to one directory.
https://docs.gradle.org/current/dsl/org.gradle.api.tasks.Copy.html
I use Ruby for writing a code, test it with Cucumber and Rspec and control versions with Git. But here are some unclear things for me. E.g. temporary files, created by tests. I don't want to track their changes with every commit.
So, what way I should use for that:
Locate temporary files inside project folder and use some Git tricks for ignoring changes. gitignore is not useful, because I need some files to be in the place, when tests are started.
Locate temporary files in the /tmp. It gives some unclear for test environment, though.
Any other ways deal with that?
The files required when the tests start should be in source control. Ideally you want temp files created by tests to be in one directory so you can ignore the whole directory. If that's not possible then add each file to the .gitignore file. Really, outside of test results, your specs should clean up after themselves, which should include deleting temp files created during testing.
gitignore is not useful,...
gitignore should be useful here:
either you can limit those temporary files to a dedicated folder within the repo, and you can ignore that all folder;
or you can identify those temporary files by their extension or naming convention, and you can ignore them by a name pattern.
Ruby has facilities for creating temp files and directories and cleaning them up for you, use that. It will pick the correct location for temp files for the current environment, probably well outside your repository, and you never have to worry about them again. While the rule of thumb for tests is to not write files outside your source directory, using a global temp directory is acceptable and reliable.
Otherwise, create a temp directory in your project (possibly inside your test directory) and put all your temp files there. Set .gitignore to ignore that directory. This has the slight advantage of keeping your test artifacts entirely inside your source directory, and you can find them easier for debugging purposes. You should still use Ruby's Tempfile class to manage them, just tell it to use your temp directory, to handle cleanup and to ensure your temp names are unique to allow parallel testing.
I would recommend just using whatever Tempfile.new spits out. Remembering to set the special test temp directory is one more moving part you don't need.
We have a C++ project that uses a custom object-relational-mapping system, in which tables are defined by .tbl files. These are then run through a code-generator that creates, for each, a .h and a .cpp file.
I'm trying to get a custom build rule working for this, in Visual Studio 2008 and 2010.
This is what I have, so far:
<?xml version="1.0" encoding="utf-8"?>
<VisualStudioToolFile
Name="z_dbbld"
Version="8.00"
>
<Rules>
<CustomBuildRule
Name="z_dbbld"
DisplayName="z_dbbld"
CommandLine="$(SolutionDir)\tools\z_dbbld $(InputName)"
Outputs="$(InputName).cpp"
FileExtensions="*.tbl"
ExecutionDescription="z_dbbld $(InputName)"
>
<Properties>
</Properties>
</CustomBuildRule>
</Rules>
</VisualStudioToolFile>
The problem is the dependencies. When I run a build on a clean checkout, where none of the files exist, I get "Cannot open include file" errors, for .h files that are generated by this rule.
I've tried changing Outputs to "$(InputName).h", and I still get the errors.
Now the thing is that these files are created, when the code generator runs. If I compile again, I don't have the errors, because all of the files were created in the first pass. But it makes doing a clean, automated, build from fresh checkout not work.
Any ideas?
I think you need to specify the Output files in the main part of the build (looking at the very last sentence of http://msdn.microsoft.com/en-us/library/hefydhhy.aspx). Probably the easiest way to do that is to add a reference to the files when they exist and then delete them and see if the codegen step runs like it should.
The answer given by sblom is correct, but it does not explain the reason.
For each build rule (custom or native) the VS build system needs to know the complete list of inputs and outputs so that it can decide what part of the project needs to be built.
Your build rule declares the generated .cpp file as an output, so VS knows about it and will automatically build this file for you. Since you omitted the header file, VS does not know about it, so any source files that include this header will not know where to get it from and fail to build. A work around to get the build to work in this situation is to add the directory where this .h file is located to your include path, and then #includes of this file will work. You are basically enabling VS to know about this file in a different way.
Conversely, if you change your build rule to declare the header file as output, then source files that include it will know where to get this file from, but now VS does not know about your .cpp file so it won't build it. A work around for this case is to explicitly add the generated .cpp file to your project as a source file. Like in the above case, you are using a trick to get the build system to recognize the generated file.
But while the workarounds above will get you going they are not the best solution, since they just compensate for VS not knowing about a file. The best way to address this problem is to declare both the .cpp and the .h files as outputs in your rule, separating them with a semi-colon. This will enable VS to apply the correct behavior to both files.
Is it possible to build projects to a common directory, instead of the per project bin folder?
The purpose would be to make it easier to source control all my binaries. How can I do it and, what are the pitfalls of this approach?
You have the option to build projects to another directory (a common directory?) rather than the bin/debug and bin/release.
If you mean building your projects and putting the DLL files in a shared folder, yes, we currently do this, but we use this using continuous integration (CI), so we can know when a change in a project caused another project to break.
You may also experience problems when you use a version-specific DLL file as referenced in your other projects.
You can also, rather than having a bat file copy over the DLL files, use Visual-Studio's built in post-build command. It's the same as a batch file, with the exception that no special setup is required in CruiseControl to copy over the files. If a developer makes a change to the post build command it and check it in it will automatically be executed by CruiseControl.
Also, if you'd like your developers to shared the binaries I'd put them in source control to make sure everyone share the same DLL files rather than their own local built copy of the DLL file (which might be different than the actual build server as some compile directives might/might not be defined).
If you mean DLL files/assemblies, then you build to bin/release as usual, then copy the DLL files you require to a common directory and then reference those, so when you rebuild the original solution, you don't have to worry about which version you are using or recompile other related projects as the version hasn't changed in the common dir.
It happens that people build to another folder than bin (e.g. the bin folder in the solution directory rather than the project directory). I doubt you would have any problems doing this. But since you're going to check it in, you must remember to not have it read-only (so you can build over them). Source control programs often lock the files.
You could also consider having a bat script that copies the files to another location after a successful build.
For C++ projects:
Right click on the project -> Properties -> Linker -> Output File
set your directory there.
For C# Projects:
Right click on the project -> Properties -> Builld -> Output Path
I would not put your binary output into source control. Only put the source files, project files and solution files.
We use post-build scripts to copy to the intended location. This works, but is very fiddly (as the scripts are awkward to write & awkward to debug).
I just started working on my first Visual Studio project, and I imported all the existing code for the project into an SVN repo of mine without checking which files were binary and which weren't. So now I'm trying to clean up the repo and I've come across some .sbr, .pch, and .res files.
I figure the .pch file doesn't need to be in source control because it's binary. But the sbr and res files are currently empty, so I can't tell offhand if they should be in the repo. So should they be in or out?
.res files are compiled versions of .rc files, so they don't need to be in the repository either.
After removing all the files you don't believe are necessary (most non-text files except images are probably not necessary), you should check out your project into a clean directory and attempt to do a full build. If it fails, then you removed too much. (If it succeeds, then you may be able to remove more stuff!)
They should not be in the repo. They are all intermediate files created during compilation.
Res may be necessary since they can contain resources. SBR is source browser and should be created on compile if you're using the /Fr option (I think).
Edit: Never mind, I assume the poster above me is correct. Make sure you have the .rc/rc2 files then.
.pch files are pre-complied headers and do not need to be included in SVN. They will be recreated when you check out your codebase and and do a build.