I have found that when creating a .tar.gz archive with the maven assembly plugin, the timestamps of the files being archived are not being preserved. Instead they are stamped with the time of archive creation. This is not the way tar behaves.
I could not find any documentation about this on the maven site and I'm surprised it isn't mentioned more.
Or am I missing something obvious?
I did a quick overview of the plugin source code and while I may be missing something, it seems like the source is all oriented around inclusion/exclusion and directory management with some provision made for permissions. All the file copying methods filter down to a stream copy and I'm betting that once the file is opened into a stream they've forgotten all the file attributes such as timestamps, and thus cannot reproduce them.
I hope I'm wrong.
Failing that, how else might I preserve timestamps while operating in a maven environment?
UPDATE:
A Jira issue was opened on this.
It turns out that timestamps generally are preserved by the plugin, unless you specify the <lineEnding> tags. These are implemented by a routine within the plugin that reads the original file, converts the line endings, and writes a new file. It is apparently not easy to preserve the original date in this case. They make no promises of a quick fix but some possible approaches to fixing it were discussed.
Related
I'm wresting with SonarQube reporting errors on C# files which I didn't write. For example, I might import a particular piece of code from an open source library where I didn't want to take the entire library as a dependency.
This usually raises a lot of SQ warnings.
Instead of dealing with these one by one, is there a way to just mark the entire file to be ignored? I'n thinking something similar to the new #nullable disable directive.
Thanks very much.
Yes, there is way to remove or better to say exclude the particular files from being analysed by sonarqube.
You can use the sonar.exclusionswhich is a sonar analysis parameter, using this parameter you can exclude files or folders.
Here is the article from sonarqube on this https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/
I'm in the process of migrating my build system from ANT to Gradle (as ANT/ADT is now no longer supported by Google) and I ran into an issue in one of the test packages. There is a test that works with an empty png (as if somebody ran 'touch empty.png') and a corrupted png. These png files are in our res/drawable-hdpi folder, as they should be. When building though, Gradle uses libpng to do some sort of processing and it errors on these two files.
My question is: can I tell Gradle to skip processing on these two files, or is there another way to get around this issue?
BTW, on a whim I tried to rename the files to .xml (the only other allowed format) and, still, it wouldn't parse.
To give an answer to others who find this question, I used horatius' answer and made the /res/raw directory and put my corrupted and empty png files in there. Gradle didn't try and process them and they still get indexed by R.java.
I noticed that Xcode 7 creates a new .xcscmblueprint file in the xcshareddata folder. Will it be always auto generated? Should this file be added to the ignore list of the repository, or should it be checked in into repository?
Xcode 6 has the .xccheckout file, I've always gitignore'd that file.
I'm gitignoring them, for exactly the same reason as .xccheckout.
GitHub's maintained .gitignore added that too, for both Objective-C and Swift. https://github.com/github/gitignore
I think it depends. Just like #Ewan Mellor said the reason for ignore .xcscmblueprint is same with it for .xccheckout.
But whether ignore .xccheckout depends on your project . If you are using single project there is no need. If you are using workspace committing xccheckout file is need. For more the answer #Chris Hanson published is feed your need.
Back to the question. The content of the xcscmblueprint contains the main information about your project.
And I'm not sure it will change in the future. As the same reason for xccheckout I would like to commit this file.
The files seems to contain information pertaining to your source code repository. I think the "SCM" part of the filename stands for "Source Code Management". When looking at the one in my project, it indeed contains information about the GitHub repository that my XCode projects it (and also the git submodules that my repository uses, that's neat!). Of course, it also contains hashes so one could wonder if they are stable across developer, but I'd bet they are.
For that reason, I back up the advice given in many comments. You DO want to version this file.
As I create more applications, my /code/shared/* increases.
this creates a problem: zipping and sending a project is no longer trivial. it looks like my options are:
in Xcode set shared files to use absolute path. Then every time I zip and send, I must also zip and send /code/shared/* and give instructions, and hope the recipient doesn't have anything already at that location.
this is really not practical; it makes the zip file too big
maintain a separate copy of my library files for each project
this is not really acceptable as a modification/improvements would have to be implemented everywhere separately. this makes maintenance unreasonably cumbersome.
some utility to go through every file in the Xcode project, figure out the lowest common folder, and create a zipped file structure that only contains the necessary files, but in their correct relative folder locations, so that the code will still build
(3) is what I'm looking for, but I have a feeling it doesn't as yet exist.
Anyone?
You should rethink your current process. The workflow you're describing in (3) is not normal. This all sounds very complicated and all basically handled with relative ease if you were using source control. (3) just doesn't exist and likely never will.
A properly configured SCM will allow you to manage multiple versions of multiple libraries (packages) and allow you to share projects (in branches) without ever requiring zipping up anything.
Whenever we recompile an exe or a DLL, its binary image is different even if the source code is the same, due to various timestamps and checksums in the image.
But, our quality system implies that each time a new DLL is published, related validation tests must be performed again (often manually, and it takes a significant amount of time.)
So, our goal is to avoid releasing DLLs that have not actually changed. I.e: having an automatic procedure (script, tool, whatever...) that detect different Dlls based only on meaningful information they contain (code and data), ignoring timestamps and checksum.
Is there a good way to achieve this ?
Base it off the version information, and only update the version information when you actually make changes.
Have your build tool build the DLL twice. Whatever differences exist between the two are guaranteed to be the result of timestamps or checksums. Now you can use that information to compare to your next build.
If you have an automated build system that syncs source before starting a build, only proceed with building and publishing if there any actual changes in source control. You should be able to detect this easily from the output of your source control client.
We have the same problem with our build system. Unfortunately it is not trivial to detect if there are any material code changes since we have numerous static libraries, so a change to one may result in a dll/exe changing. Changes to a file directly used by the dll/exe may just be fixing a bad comment, not changing the resulting object code.
I've looked previously for a tool to do what you desired and I did not see one. My thought was to compare the two files manually and skip the non meaningful differences in the two versions. The Portable File Format is well documented, so I don't expect this to be terribly difficult. Our requirements additional require that we ignore the version stamped into the dll/exe since we uniquely stamp all our files, and also to ignore the signature as we sign all our executables.
I've yet to find time to do any of this, but I'd be interested in collaborating with you if you proceed with implementing a solution. If you do find a tool that does this, please do let us know.