I tried to add custom jar into my project (to pom.xml). When I made an operation
mvn install:install-file -Dfile=<path-to-file> -DgroupId=<myGroup> -DartifactId=<myArtifactId> -Dversion=<myVersion> -Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>
I actually received an error: the specified file not exists. But the file is in the folder - that's the problem. How I can resolve this? Or how I can add custom jar without this step? I know about scope , but it's not working properly - maven variable ${basedir} cannot be used in systemPath.
Maven 3.3.9
UPDATE 1: Actually, now I find smth new: Maven doesn't like dots in groupId and version. After some tries I installed file, but it's wrong path, because instead of (e.g) org.my.local.file tree I received file in org_my_local_file folder in maven repo.
I did this many times and it worked as expected.
What do you exactly mean with :
Maven doesn't like dots in groupId and version.
What exception do you get ?
You get org_my_local_file because I think you exachanged '.' in the groupId against '_' ?
You find a good tutorial here where you can see how it is done correctly :
How to include custom library into maven local repository?
EDIT :
It looks like you are using windows. Especially powershell is known to cause problems. Have a look here, may be you have to escape some characters, there are some possible solutions :
install maven artifact
I encountered this issue when trying to initialize our base development environment. We use an Ant script to initialize Maven, our developer server and other tools and includes installing a few 3rd party jars into the local Maven repository. This error, "The specified file '<path>\true' not exists" was occurring when invoking Maven from within Ant 1.9.11.
I also used this answer to specify paths identified in the Ant script and set them in the batch script template before running the batch script.
Specifically, this answer offered a lot to get the batch script constructed: https://stackoverflow.com/a/36298099/2336934. Didn't take much:
<!-- generate the batch file -->
<tempfile property="temp.file" suffix=".properties" deleteonexit="true" destdir="${env.TEMP}" />
<echoproperties destfile="${temp.file}" />
<replaceregexp file="${temp.file}" match="([^=]*)=" replace="#\1#=" byline="true" />
<copy file="${basedir}/scripts/install-jars.template" tofile="${basedir}/scripts/install-jars.bat" />
<replace file="${basedir}/scripts/install-jars.bat" replacefilterfile="${temp.file}" />
<echo message="Running batch file for Maven setup" />
<exec executable="${basedir}/scripts/install-jars.bat" />
<delete file="${basedir}/scripts/install-jars.bat" deleteonexit="true" />
There weren't any issues with the parameters being passed, but this must be specified correctly. Running the command you're trying to execute in a script temporarily in a command window is useful to verify the command syntax and function before trying to embed in a script.
I even created a empty true file to satisfy the error which complained the file was not a valid POM file. Filling it with basic POM content led to another error. So reader beware, this business about "true not exists" is a Red Herring.
Moving the Maven install:install-file commands out to the batch file was the key to get past the issue. It also allowed me to specify the quotes in the command as " rather than " due to the commands originally being specified in the Ant script (xml).
Related
I'm having an issue where an external tool is being used to make a call which causes mvn to download a dependency on the fly. This download however is calling the "central" enterprise artifactory repo rather than one of our normal artifactory repos and I'm trying to figure out how to make it mirror the enterprise repo to point to the appropriate repo.
All I've seen indicates I should be able to do this by setting the mirror in the settings.xml file, and I've passed the path to this settings file via the -s option.
But the mirror is still being ignored.
Is there something special about making a command to use a dependency via the commandline that bypasses mirrors?
It appears that the reason setting mirrors wasn't working was because the deployment mechanisms in place weren't actually setting the xml files as intended. To get around it we added code to modify the .m2 folder to contain the xml files as part of the script run during deployment.
I have a maven project which I want to build on Jenkins. I am giving goal as
clean install -Desb_env=dev
I have mention esb_env in mule-app.properties file. Same command is working fine & picking up the value of esb_env in local machine.But same command is not working on jenkins. It gives error as
Property ESB_ENV could not be found
Like this there few more goal need to give, I could not proceed further. Don't know what is wrong with Jenkins.
I have checked path for repo as well.
Any help would be appreciated.
This is the way we are specifying parameter in mule-app.properties file. keeping it blank & providing value through command.
ESB_ENV=
secure.properties=key
key=
I have a Bamboo plan that involves building with maven on Windows. The default path to the build directory under the bamboo user is long, and some files end up over the 255-char Windows limit. I wanted to solve the problem by (for this plan only) change the location where the Mavens are run to a short dir, C:\build. I can check out files, then run a script step to copy them from the build dir to C:\build. The Maven bamboo task is configured to override the project file, using C:\build\pom.xml instead. That all works fine. However, when it gets to the 'check in the updated pom' part of release:prepare, it somehow decides that the original build directory with the long path is right, dying with an error.
Anybody know how to specify that the updated pom is also supposed to come from C:\build? I tried overriding the 'Working Sub Directory' entry, but that won't let me specify a full path, so C:\build is out.
Did you try to override the localRepoDirectory parameter?
The command-line local repository directory in use for this build (if specified).
Default value is: ${maven.repo.local}.
You may set this parameter using a property in the POM:
<properties>
<propertyName>C:\build</propertyName>
</properties>
...
<localRepoDirectory>${propertyName}</localRepoDirectory>
It can be overridden in the Bamboo Maven command:
mvn -DpropertyName="D:\build" clean package
(Bamboo variables can also be used to set the propertyName)
You may define a single property with the desired path and use it in several places in the pom.xml.
Turns out there were several different things going on with the Maven 3.x task:
By setting the Override Project File to C:\build\pom.xml, I was able to get the task to try to build in C:\build.
Part of my copying of files from the normal root directory to C:\build was wrong. I'd used xcopy but forgot to add a /H to copy the .svn data as well, so the 'check-in updated pom' step failed because it couldn't find the .svn files.
Once the release:prepare and release:perform were finished, a bamboo 'Artifact Copy' step had been defined earlier to copy several generated artifacts back to the maven repository. Turns out that while this step is somewhat configurable about what files to copy and where they are to be found, it does not support providing an absolute path as the directory to copy from, unlike the Override Project File for the maven tasks. So I had to introduce yet another step, a script to copy the generated artifacts back from C:\build... to under the build root.
All in all, I wasn't able to mess with the build root as I wanted to, but by using the Override Project File and two scripts to copy the source files to C:\build and the artifacts back from C:\build, I got done what I needed to do.
I would like to use Maven to produce an artifact in zip format. To give you some background; my project includes an APS package (Application Packaging Standard, used to provision cloud applications on the Parallels platform). This package is a zip file that contains a combination of XML as well as PHP files. It is generated by an APS plugin from within Eclipse and its name always includes the version and release number of its contents.
What I am trying to do is generate a zip file with Maven that would be kind of a release candidate that will be eventually sent to customers and would include not only the actual APS package but also other files such as README, User Guide.pdf, etc;. I would like the name of this zip file to contain the version number of the version number of the APS package. Currently I can generate this manually by using something like "mvn -Dversion=1.2.3-4 package" but I would like to automate the process and ideally run this from Jenkins.
Basically, my strategy is to run a script that would extract the version number from the initial APS package, once that is done, my script can invoke Maven and can pass this parameter to it so it can generate the final zip with the proper version number. This is fine but again, I need to run this script manually and I am looking for an automated process.
My question is; is it possible to invoke this script from within Maven and use its return as a parameter to set the version name (or the name of the file that will be generated) at run time? As I mentioned, I would like eventually Jenkins to handle this. It can pick up the pom file but I am not sure how it could kind of "auto configure" itself to have the proper version number.
Thanks is advance.
From jenkins build you can use profile with ${BUILD_NUMBER}:
<profile>
<id>jenkins</id>
<build>
<finalName>${artifactId}-${version}-${BUILD_NUMBER}</finalName>
</build>
</profile>
Then run in jenkins:
clean install -Pjenkins
I use the SVN (or any source versioning system) version to identify the software builds.
By simply executing this
REVISION=`svn info | grep '^Revision:' | sed -e 's/^Revision: //'`
on the sourcers folder you get the right value in $REVISION, then you can use it for your maven build
mvn -Dversion=1.2.3-$REVISION package
easy and clean
I am using Maven 3.0, and my .m2 folder location is C:\Users\me\.m2.
However, I do not have write access to that folder, but I want to change the repository location from the one defined in the settings.xml.
Due to restricted access, I am not able to edit the settings.xml to change the repository location.
How can I override the values of my settings.xml -or change the default location of the .m2 folder- without editing my C:\Users\me\.m2\conf\settings.xml file?
You need to add this line into your settings.xml (or uncomment if it's already there).
<localRepository>C:\Users\me\.m2\repo</localRepository>
Also it's possible to run your commands with mvn clean install -gs C:\Users\me\.m2\settings.xml - this parameter will force maven to use different settings.xml then the default one (which is in $HOME/.m2/settings.xml)
It's funny how other answers ignore the fact that you can't write to that file...
There are a few workarounds that come to my mind which could help use an arbitrary C:\redirected\settings.xml and use the mvn command as usual happily ever after.
mvn alias
In a Unix shell (or on Cygwin) you can create
alias mvn='mvn --global-settings "C:\redirected\settings.xml"'
so when you're calling mvn blah blah from anywhere the config is "automatically" picked up.
See How to create alias in cmd? if you want this, but don't have a Unix shell.
mvn wrapper
Configure your environment so that mvn is resolved to a wrapper script when typed in the command line:
Remove your MVN_HOME/bin or M2_HOME/bin from your PATH so mvn is not resolved any more.
Add a folder to PATH (or use an existing one)
In that folder create an mvn.bat file with contents:
call C:\your\path\to\maven\bin\mvn.bat --global-settings "C:\redirected\settings.xml" %*
Note: if you want some projects to behave differently you can just create mvn.bat in the same folder as pom.xml so when you run plain mvn it resolves to the local one.
Use where mvn at any time to check how it is resolved, the first one will be run when you type mvn.
mvn.bat hack
If you have write access to C:\your\path\to\maven\bin\mvn.bat, edit the file and add set MAVEN_CMD_LINE_ARG to the :runm2 part:
#REM Start MAVEN2
:runm2
set MAVEN_CMD_LINE_ARGS=--global-settings "C:\redirected\settings.xml" %MAVEN_CMD_LINE_ARGS%
set CLASSWORLDS_LAUNCHER=...
mvn.sh hack
For completeness, you can change the C:\your\path\to\maven\bin\mvn shell script too by changing the exec "$JAVACMD" command's
${CLASSWORLDS_LAUNCHER} "$#"
part to
${CLASSWORLDS_LAUNCHER} --global-settings "C:\redirected\settings.xml" "$#"
Suggestion/Rant
As a person in IT it's funny that you don't have access to your own home folder, for me this constitutes as incompetence from the company you're working for: this is equivalent of hiring someone to do software development, but not providing even the possibility to use anything other than notepad.exe or Microsoft Word to edit the source files. I'd suggest to contact your help desk or administrator and request write access at least to that particular file so that you can change the path of the local repository.
Disclaimer: None of these are tested for this particular use case, but I successfully used all of them previously for various other software.
Nobody suggested this, but you can use -Dmaven.repo.local command line argument to change where the repository is at. In addition, according to settings.xml documentation, you can set -Dmaven.home where it looks for the settings.xml file.
See: Settings.xml documentation
Below is the configuration in Maven software by default in MAVEN_HOME\conf\settings.xml.
<settings>
<!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ~/.m2/repository
<localRepository>/path/to/local/repo</localRepository>
-->
Add the below line under this configuration, will fulfill the requirement.
<localRepository>custom_path</localRepository>
Ex: <localRepository>D:/MYNAME/settings/.m2/repository</localRepository>
You can change the default location of .m2 directory in m2.conf file. It resides in your maven installation directory.
add modify this line in
m2.conf
set maven.home C:\Users\me\.m2
You can point to a different-settings.xml when you deploy your project. When deployed from the project folder you can have a relative path to get back to your home folder:
mvn clean deploy -s ../../.m2/different-settings.xml