I'm able to create a zip file using maven-assembly-plugin in my pom, but what I need to do is to make this zip has "lastmodified" timestamp of a directory that was zipped. Is it possible to achieve?
I know I can use for example maven-antrun-plugin and property preservelastmodified="true" when copying resources. Is there anything similar for creating archive of a file?
Related
I want to store some additional files in the JAR that gets created. Those files are in a directory that is a subdirectory of a repository which is pulled in via a git submodule.
I want to copy that submodule to my src resources directory before compiling, but I also want to make sure that any old files at that location are removed first.
How can that be achieved best with Maven plugins? I did not find any option to remove any destination files with the copy-resources goal of the maven-resources-plugin and I could not get the maven-clean-plugin to run right before the copy-resources either. So how does one accomplish such a trivial task with Maven?
UPDATE: as mentioned above, the reason why I want to do this is because what is copied should become part of what gets added to the resulting jar (and could potentially be part of what gets compiled). So I need to copy these files into the src directory and NOT the target directory. What should get copied before each build is the input to the build, not an additional output.
There is one flaw in your approach, and it probably explains most of the obstructions you encountered.
During a build, the only directory in which you may write is target. Copying files to src or changing them is strictly discouraged.
The target folder is erased by clean, so no need to tidy up yourself or to manage old files.
I was working on a maven project and this project is generating some weird file.
The file name are like:
[PROJECT]/target/classes.531226305.timestamp
[PROJECT]/target/classes.1241815416.timestamp
[PROJECT]/target/test-classes.-1983166104.timestamp
And the content of the file are only a .(dot) inside it. Anyone has any idea of how this is generated? Thanks!
Does the project use the scala-maven-plugin? The scala-maven-plugin adds ".<hashcode>.timestamp" to files in the target directory. It's used for the incremental compile feature that is available for that plugin.
We are using TeamCity as CI and we are struggling with the final build step: We pull a dependency from another build step (a zip) and want to add a few extra files. Do we really need to extract the zip (quite large file), copy the files over there and zip it again? Is there support or a plugin to add files to existing zip files?
TeamCity itself does not support this and I haven't seen any related plugins, however, if you really need to wait until the final step to add the extra files (maybe you are doing some kind of file generation at this point), then I would recommend using something like 7Zip.
you can update existing zip files (assuming they are not "solid" archives") with a very simple command:
7za.exe u targetZip.zip file.ext
this will add "file.ext" to the zip file "targetZip.zip" without decompressing and re-compressing the archive.
you can find 7Zip here: http://www.7-zip.org/
It would be much better to include those files at the previous step, which lists which files should be included to the final artifact. Rather than trying to modify the already generated artifact. So basically all you need is to add an additional build step that will simply copy those other files to the output folder from which you are producing your final artifact.
With the Maven assembly plugin I know I can set the permissions of the files contained within my tar such as here. However can I use the plugin to set the permissions of the tar itself?
Maybe I should just the ant plugin but this is a little messy
I haven't tested this, but you might be able to use "exec-maven-plugin" to do this.
How to change permission of jar packaged by maven? I am using maven assembly plugin
"Use maven:exec plugin to execute chmod"
So the idea is that you would add another plugin to the pom.xml file that sets the permission on the tar itself.
The only drawback that I see is that you have to have the name of the file in the plugin xml code in the pom file. That's fine as I have that listed in in the maven-assembly-plugin. But the file extension is found in assembly.xml (.zip, or .tar-gz), so if you change the file extension in assembly.xml, you would have to remember to change it in the pom.xml file. Not a big hassle, but it might be easy to miss on your first review.
I have a zip archive artifact. I'm interested in downloading a single file from that artifact. I can't upload that file outside of the archive right now. The documentation says you download an archive like this
/repository/download/BUILD_TYPE_ID/BUILD_ID:id/ARTIFACT_PATH
So, my URL for that looks like this (and I need anonymous access, so you see the guest flag). And it works!
/repository/download/bt23/2253:id/mypackage.zip?guest=1
However, I want one single file from that artifact. And the docs are confusing on how to do that. They do not specify what replaces <zip or jar archive>. And I am not constructing the whole buildNumber or buildTypeId values properly.
/repository/archive/<zip or jar archive>/buildTypeId/BUILD_TYPE_ID/buildNumber/BUILD_NUMBER/index.html
I tried using zip and `.zip'. I tried filling in the build values directly, but it's much different from the working archive download URL.
/repository/archive/zip/buildTypeId/bt23/buildNumber/2253/myfile.txt?guest=1
Does anyone have working concrete example of the URL for a single file in an archive?
You need to replace <zip or jar archive> with relative path to your artifact. For example, if you want to retrieve file.txt from package.zip which is uploaded under dist directory in your build artifacts you need to use this url:
http://server/repository/archive/dist/package.zip/buildTypeId/bt23/buildNumber/2253/file.txt?guest=1
BTW, a new, more straightforward URL syntax will be available in TeamCity 7.0:
http://server/repository/download/bt23/2253/dist/package.zip!file.txt?guest=1
Old URLs will be supported too.