In the source mappings, I specify many different directories. All works well.
However if I specify the directory which has the name executable the RPM plugin returns an error code of 1. The files strangely enough are still copied to the RPM buildroot, but the RPM plugin overall fails. I renamed the directory to 'lib' and it builds fine.
Is the executable a reserved word or keyword of some sort??? The mapping below causes the build to fail. I have checked spelling and that is fine. The path exists. So why is it failing???
<mapping>
<directory>/executable</directory> //rpm directory
<filemode>0644</filemode>
<sources>
<source>
<location>/path/to/directory/executable</location> // local dir under target
</source>
</sources>
</mapping>
Related
I do not ever want maven-dependency-plugin:3.1.2:unpack to overwrite existing files in any circumstances. This is my current pom.xml configuration:
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.2</version>
<executions>
<execution>
<id>unpack-zip-files</id>
<phase>generate-test-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.foo</groupId>
<artifactId>bar</artifactId>
<version>${foobar.version}</version>
<type>zip</type>
<classifier>exe-archive</classifier>
<overWrite>false</overWrite>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
<includes>**/*.exe</includes>
</artifactItem>
</artifactItems>
<overWriteIfNewer>false</overWriteIfNewer>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>false</overWriteSnapshots>
</configuration>
</execution>
</executions>
</plugin>
Scenario:
Projects foo and bar
foo has a .exe file as build artifact, inside a ZIP file
bar runs the .exe file during tests
In situation X, bar must use the snapshot version of the mainline development branch of foo. In that case, the directory target/lib shall be empty before mvn install. This is guaranteed by starting from an empty workspace and running mvn clean as a separate build step. This question is not about situation X.
In situation Y, bar must use a custom build of a feature branch of foo. This is done by unpacking the ZIP file with the .exe to the directory target/lib in a separate build step between mvn clean and mvn install.
We are working in situation Y, where the target/lib directory is already pre-filled with the .exe from the correct feature branch.
This is the target/lib directory before mvn is run:
+ ls -al fooBar.exe
-rw-rw-r-- 1 ubuntu ubuntu 18368427 Apr 12 21:27 fooBar.exe
+ md5sum fooBar.exe
03acc8b5c3da700c31efcd6635feb56a fooBar.exe
This is the target/lib directory after mvn is run:
+ ls -al fooBar.exe
-rwxrwxr-x 1 ubuntu ubuntu 18368393 Apr 11 23:10 fooBar.exe
+ md5sum fooBar.exe
ab6dd45c5cc4e41534ad2363c5767601 fooBar.exe
The change in md5sum is hard evidence that the existing fooBar.exe was overwritten by Maven.
Maven command used:
mvn --global-settings /home/jenkins/workspace/bar#tmp/config15592668079584895681tmp \
-Dmaven.repo.local=/home/jenkins/workspace/bar/.repository \
install \
-DgsExec=/usr/bin/gs -DcompareExec=/usr/local/bin/compare \
-Dtest=RunCucumberTest -Dcucumber.options=--plugin json:target/cucumber.json
Expected results
The mvn install command shall not overwrite existing files when overWrite, overWriteIfNewer, overWriteReleases, overWriteSnapshots are all set to false.
The md5sum of fooBar.exe shall be the same before and after running mvn install.
Question
Which magical incantations do I need to add to pom.xml so that existing files are never overwritten in any circumstances?
Documentation referenced
Apache Maven Dependency Plugin – Usage – Overwrite Rules
Apache Maven Dependency Plugin – dependency:unpack
OK, I think I know what might be happening: Like I said in my comment:
I just read your message on the mailing list and tried in one of my own projects, also using plugin version 3.1.2. Actually, just specifying <overWrite>false</overWrite> inside the <artifactItem> was enough to avoid overwriting. I just executed the unpack goal once, then manually modified an unpacked file and it did not get overwritten. I even see my-artifact-1.3.jar already unpacked in the log.
I continued experimenting some more and noticed that even when deleting many unpacked files, they will not be recreated, so the check must be on a more global level, not on a per-file basis.
Even when deleting all files or the whole output directory, the dependency will not be unpacked again. That was a sure indicator that some kind of meta information must be stored somewhere outside the output directory. The first place to look for it was of course the target directory, and obviously enough, in subdirectory target/dependency-maven-plugin-markers there are (empty) marker files like my-dependency-1.3.marker. Deleting one of those files has the effect of the dependency getting unpacked again during the next build, overwriting possibly existing files.
So the way for you to solve this problem is to avoid cleaning the target directory or at least to make sure to keep the corresponding marker file.
Update: You could also create the marker file by yourself if the EXE file you want to protect exists and if for some reason your build workflow needs the clean in between. But the latter would be a bit ugly, you should try to avoid it. With Antrun or some Beanshell or Groovy scripting it would be possible, though.
Somewhat more elegant would be a profile with auto-activation if the EXE file does not exist, then putting the dependency plugin inside the profile, i.e. it would only get active if the EXE does not exist in the first place.
I'm using the rpm-maven-plugin to build an rpm install of my app.
As part of the rpm install I want to deploy a few tools to the machine that installs the rpm. The downloads are tar files and I want to unzip it to a specific location as part of the post-install steps.
During the prepare step (%pre) I'm downloading a few tools via the prepareScriptlet tag :
wget some-url-tool1 -O ${rpm.info.downloads_dir}/tool1.tar.gz
wget some-url-tool2 -O ${rpm.info.downloads_dir}/tool2.tar.gz
wget some-url-tool3 -O ${rpm.info.downloads_dir}/tool3.tar.gz
I added to the mapping the downloads dir :
<mapping>
<directory>${rpm.info.install_dir}/rpms</directory>
<filemode>700</filemode>
<sources>
<source>
<location>${rpm.info.downloads_dir}</location>
</source>
</sources>
</mapping>
The problem is that the downloads_dir doesn't exist and I need to create it before the spec file is created. I'm getting the following error because I set the directory in the mapping because it doesn't exist (otherwise I will get other error for unchecked files):
[ERROR] Failed to execute goal org.codehaus.mojo:rpm-maven-plugin:2.2.0:rpm (default-rpm) on project my-project-rpm: Source location /tmp/rpmbuild-downloads does not exist -> [Help 1]
I don't want to download the files to a directory that already exist (/tmp for example) and add a specific include tag for every tar file. Any way to create the directory before the spec file is created?
I have below configuration in pom.xml file for rpm. I want to copy a jar at specific folder when rpm runs. The code is as below in pom.xml:
<mapping>
<directory>/var/lib/abc</directory>
<filemode>777</filemode>
<username>aaa</username>
<groupname>aaa</groupname>
<sources>
<source>
<location>/opt/lib/temp.jar</location>
</source>
</sources>
</mapping>
The same configuration I have in another pom file for another rpm.
The problem is, when I run the any rpm first it created the folder, copy the file.
Working as expected but I run another rpm file, it generated error that the files are already present and not overwrite those file.
I just want to know, is there any way to overwrite those file or any way avoid the error if the files are already present to that location.
Thanks,
Atul
The issue has been resolved.
There is strange fix I did:
<filemode>777</filemode>
This line I have to added in pom file, where it was missing.
I thought, it would allow me, as the directoy is already created.
I have a Maven RPM plugin mapping thus:
<mapping>
<directory>/etc/myconfig</directory>
<configuration>true</configuration>
<sources>
<source>
<location>${project.build.directory}</location>
<includes>
<include>*.conf</include>
</includes>
</source>
</sources>
</mapping>
However, depending on the packaging process, there may be zero .conf files to put in /etc. When this occurs, RPM plugin says:
[ERROR] Failed to execute goal org.codehaus.mojo:rpm-maven-plugin:2.1.2:rpm (default) on project clients:
Unable to copy files for packaging: You must set at least one file. -> [Help 1]
Is there any way to have a mapping section that is happy with including zero files?
The best I've been able to come up with is omitting the <includes> tag, which takes everything from what's specified in <location>.
location
The file or directory to include. If a directory is specified, all files and subdirectories are also included.
You will need to be as specific as possible in the path for these mappings that don't have include patterns specified. I added confs to the location below to avoid pulling in everything else in project.build.directory.
Even if no files are selected, the <directory> will still be created.
<mapping>
<directory>/etc/myconfig</directory>
<configuration>true</configuration>
<sources>
<source>
<location>${project.build.directory}/confs</location>
</source>
</sources>
</mapping>
Me too faced the same issue and was trying hard to resolve it. The error message is not so intuitive. It's really hard to address such issue.
error :
[ERROR] Failed to execute goal org.codehaus.mojo:rpm-maven-plugin:2.1-alpha-3x:attached-rpm (generate-rpm) on project XXX_assembly: Unable to copy files for packaging: You must set at least one file. -> [Help 1]
I was using below version of plugin
*
<groupId>org.codehaus.mojo</groupId>
<artifactId>rpm-maven-plugin</artifactId>
<version>2.1-alpha-3x</version>
*
Below is my Mapping tag from plugin
What this mapping was trying to is copy batch-test-1.0.war from ../batch/target location to target location at ${app.prefix}/batch
Issue was tag was having name of war file which does not exist and incorrect. i have given wrong name of war file so Maven was complaining that it should have something to copy.i corrected it by giving correct name of my war file as below.
batch-test-1.0.war
I'm building a package using the Maven RPM plugin, and it's generating the %files section in the .spec file in a way that causes conflicts during installation. I want to install a file into /usr/bin, but the .spec file contains the following directive:
%attr(755,root,root) /usr/bin
This causes the RPM install to fail due to a conflict with another package which already owns that directory.
What I would like to do is have Maven specify the filename directly, which would avoid the entire issue. Here's the mapping section for that particular file:
<mapping>
<directory>/usr/bin</directory>
<filemode>755</filemode>
<sources>
<source>
<location>src/main/scripts/foobar.sh</location>
<destination>foobar</destination>
</source>
</sources>
</mapping>
Any suggestions?
(I've opened an issue at the plugin bug tracker for this)
As pointed out in the bug, the directoryIncluded[1] mapping controls this behavior. If you set this to false you will get the behavior you desire.
[1] - http://mojo.codehaus.org/rpm-maven-plugin/map-params.html#directoryIncluded
One of the maintainers answered my question on the issue tracker. It turns out that the directoryIncluded mapping does exactly what I want.