We have executable spring boot jars. Some environment variables are provided via the runtime account's .bashrc , including SPRING_PROFILES_ACTIVE . This is set at runtime through checking some system parameters.
In order to enable a truly portable application, we would like to set these variables inside a custom version of the Spring Boot executable launch script (launch.script) instead of relying upon a custom .bashrc being deployed somewhere.
i.e. the launch script runs the custom shell code that is currently in our bashrc .
We could then throw the Spring Boot executable jar on one of our boxes without having to deploy the custom .bashrc .
We have copied the default Spring Boot launch.script and prepended setting our environment variables. We replace the default script with our custom one by using the spring-boot-maven-plugin. Using echo statements, we know that the new launch.script replaces the default one.
One environment variable we are setting dynamically is SPRING_PROFILES_ACTIVE . Through an echo statement, I know that the variable is being set correctly inside of our custom launch.script. However, that value is not being propagated to the application. i.e. the spring profile at application startup is always 'default', versus L0, L1 or whatever we're trying to set.
I have exported the variable using export and declare -x .
Is what we are doing at all feasible, or is setting SPRING_PROFILES_ACTIVE in the launch.script too late ?
In the snapshot version(2.0.0.M7) there is a new property substitution named inlinedConfScript, we can use this feature to set some environment variables before application startup.
The <build> setting in pom.xml
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<executable>true</executable>
<embeddedLaunchScriptProperties>
<inlinedConfScript>${project.basedir}/my.script</inlinedConfScript>
</embeddedLaunchScriptProperties>
</configuration>
</plugin>
</plugins>
</build>
Create my.script in the the same directory of the project's pom.xml
export SPRING_PROFILES_ACTIVE=production
I have environment variables in my application.properties like this spring.mail.username=${username}
The ${username} is declare in eclipse environment variable. When I build maven package and install, then deploy it to tcServer. The TC Server does not know ${username}. Another word, the environment variables do not include in the war file during build.
How do I get the environment variable in eclipse to include in war file for deployment?
Using Maven filtering as described in alexbt's answer, is the right approach for including values defined elsewhere. His example touches on including an operating system environment variable. You can extend this to Maven properties also. For example,
<project ...>
<properties>
<spring.mailuser>bob#mycompany.com</spring.mailuser>
</properties>
...
<build>
...
</build>
</project>
defines a Maven properties whose value is retrieved by ${spring.mailuser} and can be used as part
of other Maven configurations or injected as content via Maven filtering. Given this, changing
applicable.properties as follows
spring.mail.username=${spring.mailuser}
will inject the value of the property at build time.
If you wish to have a build-time variable replaced, I would suggest you to use maven filtering:
Have an environment variable (not an eclipse one):
export username=user3184890
Then, in your pom.xml, activate maven filtering on resources (assuming your application.properties is in src/main/resources:
<build>
<resources>
<resource>
<directory>${project.basedir}/src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
...
Also, change your application.properties to this:
spring.mail.username=${env.username}
or
spring.mail.username=#env.username#
Maven 2 is driving me crazy during the experimentation / quick and dirty mock-up phase of development.
I have a pom.xml file that defines the dependencies for the web-app framework I want to use, and I can quickly generate starter projects from that file. However, sometimes I want to link to a 3rd party library that doesn't already have a pom.xml file defined, so rather than create the pom.xml file for the 3rd party lib by hand and install it, and add the dependency to my pom.xml, I would just like to tell Maven: "In addition to my defined dependencies, include any jars that are in /lib too."
It seems like this ought to be simple, but if it is, I am missing something.
Any pointers on how to do this are greatly appreciated. Short of that, if there is a simple way to point maven to a /lib directory and easily create a pom.xml with all the enclosed jars mapped to a single dependency which I could then name / install and link to in one fell swoop would also suffice.
Problems of popular approaches
Most of the answers you'll find around the internet will suggest you to either install the dependency to your local repository or specify a "system" scope in the pom and distribute the dependency with the source of your project. But both of these solutions are actually flawed.
Why you shouldn't apply the "Install to Local Repo" approach
When you install a dependency to your local repository it remains there. Your distribution artifact will do fine as long as it has access to this repository. The problem is in most cases this repository will reside on your local machine, so there'll be no way to resolve this dependency on any other machine. Clearly making your artifact depend on a specific machine is not a way to handle things. Otherwise this dependency will have to be locally installed on every machine working with that project which is not any better.
Why you shouldn't apply the "System Scope" approach
The jars you depend on with the "System Scope" approach neither get installed to any repository or attached to your target packages. That's why your distribution package won't have a way to resolve that dependency when used. That I believe was the reason why the use of system scope even got deprecated. Anyway you don't want to rely on a deprecated feature.
The static in-project repository solution
After putting this in your pom:
<repository>
<id>repo</id>
<releases>
<enabled>true</enabled>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
<url>file://${project.basedir}/repo</url>
</repository>
for each artifact with a group id of form x.y.z Maven will include the following location inside your project dir in its search for artifacts:
repo/
| - x/
| | - y/
| | | - z/
| | | | - ${artifactId}/
| | | | | - ${version}/
| | | | | | - ${artifactId}-${version}.jar
To elaborate more on this you can read this blog post.
Use Maven to install to project repo
Instead of creating this structure by hand I recommend to use a Maven plugin to install your jars as artifacts. So, to install an artifact to an in-project repository under repo folder execute:
mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -Dfile=[your-jar] -DgroupId=[...] -DartifactId=[...] -Dversion=[...]
If you'll choose this approach you'll be able to simplify the repository declaration in pom to:
<repository>
<id>repo</id>
<url>file://${project.basedir}/repo</url>
</repository>
A helper script
Since executing installation command for each lib is kinda annoying and definitely error prone, I've created a utility script which automatically installs all the jars from a lib folder to a project repository, while automatically resolving all metadata (groupId, artifactId and etc.) from names of files. The script also prints out the dependencies xml for you to copy-paste in your pom.
Include the dependencies in your target package
When you'll have your in-project repository created you'll have solved a problem of distributing the dependencies of the project with its source, but since then your project's target artifact will depend on non-published jars, so when you'll install it to a repository it will have unresolvable dependencies.
To beat this problem I suggest to include these dependencies in your target package. This you can do with either the Assembly Plugin or better with the OneJar Plugin. The official documentaion on OneJar is easy to grasp.
For throw away code only
set scope == system and just make up a groupId, artifactId, and version
<dependency>
<groupId>org.swinglabs</groupId>
<artifactId>swingx</artifactId>
<version>0.9.2</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/swingx-0.9.3.jar</systemPath>
</dependency>
Note: system dependencies are not copied into resulted jar/war
(see How to include system dependencies in war built using maven)
You may create local repository on your project
For example if you have libs folder in project structure
In libs folder you should create directory structure like: /groupId/artifactId/version/artifactId-version.jar
In your pom.xml you should register repository
<repository>
<id>ProjectRepo</id>
<name>ProjectRepo</name>
<url>file://${project.basedir}/libs</url>
</repository>
and add dependency as usual
<dependency>
<groupId>groupId</groupId>
<artifactId>artifactId</artifactId>
<version>version</version>
</dependency>
That is all.
For detailed information: How to add external libraries in Maven (archived)
Note: When using the System scope (as mentioned on this page), Maven needs absolute paths.
If your jars are under your project's root, you'll want to prefix your systemPath values with ${basedir}.
This is what I have done, it also works around the package issue and it works with checked out code.
I created a new folder in the project in my case I used repo, but feel free to use src/repo
In my POM I had a dependency that is not in any public maven repositories
<dependency>
<groupId>com.dovetail</groupId>
<artifactId>zoslog4j</artifactId>
<version>1.0.1</version>
<scope>runtime</scope>
</dependency>
I then created the following directories repo/com/dovetail/zoslog4j/1.0.1 and copied the JAR file into that folder.
I created the following POM file to represent the downloaded file (this step is optional, but it removes a WARNING) and helps the next guy figure out where I got the file to begin with.
<?xml version="1.0" encoding="UTF-8" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.dovetail</groupId>
<artifactId>zoslog4j</artifactId>
<packaging>jar</packaging>
<version>1.0.1</version>
<name>z/OS Log4J Appenders</name>
<url>http://dovetail.com/downloads/misc/index.html</url>
<description>Apache Log4j Appender for z/OS Logstreams, files, etc.</description>
</project>
Two optional files I create are the SHA1 checksums for the POM and the JAR to remove the missing checksum warnings.
shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar \
> repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar.sha1
shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom \
> repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom.sha1
Finally I add the following fragment to my pom.xml that allows me to refer to the local repository
<repositories>
<repository>
<id>project</id>
<url>file:///${basedir}/repo</url>
</repository>
</repositories>
This is how we add or install a local jar
<dependency>
<groupId>org.example</groupId>
<artifactId>iamajar</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/iamajar.jar</systemPath>
</dependency>
i gave some default groupId and artifactId because they are mandatory :)
You really ought to get a framework in place via a repository and identifying your dependencies up front. Using the system scope is a common mistake people use, because they "don't care about the dependency management." The trouble is that doing this you end up with a perverted maven build that will not show maven in a normal condition. You would be better off following an approach like this.
Maven install plugin has command line usage to install a jar into the local repository, POM is optional but you will have to specify the GroupId, ArtifactId, Version and Packaging (all the POM stuff).
Using <scope>system</scope> is a terrible idea for reasons explained by others, installing the file manually to your local repository makes the build unreproducible, and using <url>file://${project.basedir}/repo</url> is not a good idea either because (1) that may not be a well-formed file URL (e.g. if the project is checked out in a directory with unusual characters), (2) the result is unusable if this project’s POM is used as a dependency of someone else’s project.
Assuming you are unwilling to upload the artifact to a public repository, Simeon’s suggestion of a helper module does the job. But there is an easier way now…
The Recommendation
Use non-maven-jar-maven-plugin. Does exactly what you were asking for, with none of the drawbacks of the other approaches.
I found another way to do this, see here from a Heroku post
To summarize (sorry about some copy & paste)
Create a repo directory under your root folder:
yourproject
+- pom.xml
+- src
+- repo
Run this to install the jar to your local repo directory
mvn deploy:deploy-file -Durl=file:///path/to/yourproject/repo/ -Dfile=mylib-1.0.jar -DgroupId=com.example -DartifactId=mylib -Dpackaging=jar -Dversion=1.0
Add this your pom.xml:
<repositories>
<!--other repositories if any-->
<repository>
<id>project.local</id>
<name>project</name>
<url>file:${project.basedir}/repo</url>
</repository>
</repositories>
<dependency>
<groupId>com.example</groupId>
<artifactId>mylib</artifactId>
<version>1.0</version>
</dependency>
What seems simplest to me is just configure your maven-compiler-plugin to include your custom jars. This example will load any jar files in a lib directory.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<includes>
<include>lib/*.jar</include>
</includes>
</configuration>
</plugin>
After having really long discussion with CloudBees guys about properly maven packaging of such kind of JARs, they made an interesting good proposal for a solution:
Creation of a fake Maven project which attaches a pre-existing JAR as a primary artifact, running into belonged POM install:install-file execution. Here is an example of such kinf of POM:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.3.1</version>
<executions>
<execution>
<id>image-util-id</id>
<phase>install</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<file>${basedir}/file-you-want-to-include.jar</file>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<packaging>jar</packaging>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
But in order to implement it, existing project structure should be changed. First, you should have in mind that for each such kind of JAR there should be created different fake Maven project (module). And there should be created a parent Maven project including all sub-modules which are : all JAR wrappers and existing main project. The structure could be :
root project (this contains the parent POM file includes all sub-modules with module XML element) (POM packaging)
JAR 1 wrapper Maven child project (POM packaging)
JAR 2 wrapper Maven child project (POM packaging)
main existing Maven child project (WAR, JAR, EAR .... packaging)
When parent running via mvn:install or mvn:packaging is forced and sub-modules will be executed. That could be concerned as a minus here, since project structure should be changed, but offers a non static solution at the end
The problem with systemPath is that the dependencies' jars won't get distributed along your artifacts as transitive dependencies. Try what I've posted here: Is it best to Mavenize your project jar files or put them in WEB-INF/lib?
Then declare dependencies as usual.
And please read the footer note.
If you want a quick and dirty solution, you can do the following (though I do not recommend this for anything except test projects, maven will complain in length that this is not proper).
Add a dependency entry for each jar file you need, preferably with a perl script or something similar and copy/paste that into your pom file.
#! /usr/bin/perl
foreach my $n (#ARGV) {
$n=~s#.*/##;
print "<dependency>
<groupId>local.dummy</groupId>
<artifactId>$n</artifactId>
<version>0.0.1</version>
<scope>system</scope>
<systemPath>\${project.basedir}/lib/$n</systemPath>
</dependency>
";
A quick&dirty batch solution (based on Alex's answer):
libs.bat
#ECHO OFF
FOR %%I IN (*.jar) DO (
echo ^<dependency^>
echo ^<groupId^>local.dummy^</groupId^>
echo ^<artifactId^>%%I^</artifactId^>
echo ^<version^>0.0.1^</version^>
echo ^<scope^>system^</scope^>
echo ^<systemPath^>${project.basedir}/lib/%%I^</systemPath^>
echo ^</dependency^>
)
Execute it like this: libs.bat > libs.txt.
Then open libs.txt and copy its content as dependencies.
In my case, I only needed the libraries to compile my code, and this solution was the best for that purpose.
To install the 3rd party jar which is not in maven repository use maven-install-plugin.
Below are steps:
Download the jar file manually from the source (website)
Create a folder and place your jar file in it
Run the below command to install the 3rd party jar in your local maven repository
mvn install:install-file -Dfile= -DgroupId=
-DartifactId= -Dversion= -Dpackaging=
Below is the e.g one I used it for simonsite log4j
mvn install:install-file
-Dfile=/Users/athanka/git/MyProject/repo/log4j-rolling-appender.jar -DgroupId=uk.org.simonsite -DartifactId=log4j-rolling-appender -Dversion=20150607-2059 -Dpackaging=jar
In the pom.xml include the dependency as below
<dependency>
<groupId>uk.org.simonsite</groupId>
<artifactId>log4j-rolling-appender</artifactId>
<version>20150607-2059</version>
</dependency>
Run the mvn clean install command to create your packaging
Below is the reference link:
https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
A strange solution I found:
using Eclipse
create simple (non-maven) java project
add a Main class
add all the jars to the classpath
export Runnable JAR (it's important, because no other way here to do it)
select Extract required libraries into generated JAR
decide the licence issues
tadammm...install the generated jar to your m2repo
add this single dependency to your other projects.
cheers,
Balint
Even though it does not exactly fit to your problem, I'll drop this here. My requirements were:
Jars that can not be found in an online maven repository should be in the SVN.
If one developer adds another library, the other developers should not be bothered with manually installing them.
The IDE (NetBeans in my case) should be able find the sources and javadocs to provide autocompletion and help.
Let's talk about (3) first: Just having the jars in a folder and somehow merging them into the final jar will not work for here, since the IDE will not understand this. This means all libraries have to be installed properly. However, I dont want to have everyone installing it using "mvn install-file".
In my project I needed metawidget. Here we go:
Create a new maven project (name it "shared-libs" or something like that).
Download metawidget and extract the zip into src/main/lib.
The folder doc/api contains the javadocs. Create a zip of the content (doc/api/api.zip).
Modify the pom like this
Build the project and the library will be installed.
Add the library as a dependency to your project, or (if you added the dependency in the shared-libs project) add shared-libs as dependency to get all libraries at once.
Every time you have a new library, just add a new execution and tell everyone to build the project again (you can improve this process with project hierachies).
For those that didn't find a good answer here, this is what we are doing to get a jar with all the necessary dependencies in it. This answer (https://stackoverflow.com/a/7623805/1084306) mentions to use the Maven Assembly plugin but doesn't actually give an example in the answer. And if you don't read all the way to the end of the answer (it's pretty lengthy), you may miss it. Adding the below to your pom.xml will generate target/${PROJECT_NAME}-${VERSION}-jar-with-dependencies.jar
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<!-- get all project dependencies -->
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<!-- MainClass in mainfest make a executable jar -->
<archive>
<manifest>
<mainClass>my.package.mainclass</mainClass>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<!-- bind to the packaging phase -->
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
I alluded to some python code in a comment to the answer from #alex lehmann's , so am posting it here.
def AddJars(jarList):
s1 = ''
for elem in jarList:
s1+= """
<dependency>
<groupId>local.dummy</groupId>
<artifactId>%s</artifactId>
<version>0.0.1</version>
<scope>system</scope>
<systemPath>${project.basedir}/manual_jars/%s</systemPath>
</dependency>\n"""%(elem, elem)
return s1
This doesn't answer how to add them to your POM, and may be a no brainer, but would just adding the lib dir to your classpath work? I know that is what I do when I need an external jar that I don't want to add to my Maven repos.
Hope this helps.
What works in our project is what Archimedes Trajano wrote, but we had in our .m2/settings.xml something like this:
<mirror>
<id>nexus</id>
<mirrorOf>*</mirrorOf>
<url>http://url_to_our_repository</url>
</mirror>
and the * should be changed to central. So if his answer doesn't work for you, you should check your settings.xml
I just wanted a quick and dirty workaround... I couldn't run the script from Nikita Volkov: syntax error + it requires a strict format for the jar names.
I made this Perl script which works with whatever format for the jar file names, and it generates the dependencies in an xml so it can be copy pasted directly in a pom.
If you want to use it, make sure you understand what the script is doing, you may need to change the lib folder and the value for the groupId or artifactId...
#!/usr/bin/perl
use strict;
use warnings;
open(my $fh, '>', 'dependencies.xml') or die "Could not open file 'dependencies.xml' $!";
foreach my $file (glob("lib/*.jar")) {
print "$file\n";
my $groupId = "my.mess";
my $artifactId = "";
my $version = "0.1-SNAPSHOT";
if ($file =~ /\/([^\/]*?)(-([0-9v\._]*))?\.jar$/) {
$artifactId = $1;
if (defined($3)) {
$version = $3;
}
`mvn install:install-file -Dfile=$file -DgroupId=$groupId -DartifactId=$artifactId -Dversion=$version -Dpackaging=jar`;
print $fh "<dependency>\n\t<groupId>$groupId</groupId>\n\t<artifactId>$artifactId</artifactId>\n\t<version>$version</version>\n</dependency>\n";
print " => $groupId:$artifactId:$version\n";
} else {
print "##### BEUH...\n";
}
}
close $fh;
The solution for scope='system' approach in Java:
public static void main(String[] args) {
String filepath = "/Users/Downloads/lib/";
try (Stream<Path> walk = Files.walk(Paths.get(filepath))) {
List<String> result = walk.filter(Files::isRegularFile)
.map(x -> x.toString()).collect(Collectors.toList());
String indentation = " ";
for (String s : result) {
System.out.println(indentation + indentation + "<dependency>");
System.out.println(indentation + indentation + indentation + "<groupId>"
+ s.replace(filepath, "").replace(".jar", "")
+ "</groupId>");
System.out.println(indentation + indentation + indentation + "<artifactId>"
+ s.replace(filepath, "").replace(".jar", "")
+ "</artifactId>");
System.out.println(indentation + indentation + indentation + "<version>"
+ s.replace(filepath, "").replace(".jar", "")
+ "</version>");
System.out.println(indentation + indentation + indentation + "<scope>system</scope>");
System.out.println(indentation + indentation + indentation + "<systemPath>" + s + "</systemPath>");
System.out.println(indentation + indentation + "</dependency>");
}
} catch (IOException e) {
e.printStackTrace();
}
}
Below is the issue occurred while building project using Jenkins job, this project is having a parent pom.xml which is defining version of dependencies in it and certainly the SNAPSHOTS etc. which are imported are not required or may be a version clash.
I had a deep look into pom and no unused SNAPSHOT are there in effective pom.
Anyone having idea on what could be the problem, any debugging tips would be really helpful.
Thanks in advance.
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.4.0:java (default-cli) on project script: An exception occured while executing the Java class. null: InvocationTargetException: Effective-pom for 'com.xxx.bss.rm.invoicing.messages:compile:pom:0.5.0-SNAPSHOT' contains SNAPSHOT, failing build. Check any properties and make sure they end in .version if they specifify versions.
Properties in Parent pom
<properties>
<coba.cdac-version>7.1.1</coba.cdac-version>
<coba.businessentity-version>6.3.6</coba.businessentity-version>
<com.xxx.bss.vre.version>2.8.0</com.xxx.bss.vre.version>
<java.oam.version>R3F01</java.oam.version>
<cil.service.version>3.0.1</cil.service.version>
<cil.client.version>5.0.3</cil.client.version>
<cil.messaging.version>1.0.0</cil.messaging.version>
<bss.ctrl.jmx.monitor.version>3.0.1-E002</bss.ctrl.jmx.monitor.version>
<bss.ctrl.version>3.0.2</bss.ctrl.version>
<courier.version>4.1.0</courier.version>
<com.google.code.gson.gson.version>2.3.1</com.google.code.gson.gson.version>
<common.oam.version>1.12.0</common.oam.version>
<com.xxx.bss.ecim.cm.observer.version>0.4.0</com.xxx.bss.ecim.cm.observer.version>
<com.xxx.bss.osgi.srstub.serviceregistrystub.version>2.0.0
</com.xxx.bss.osgi.srstub.serviceregistrystub.version>
<org.osgi.service.event.version>1.3.1</org.osgi.service.event.version>
<commons-configuration.version>1.9</commons-configuration.version>
<com.unboundid-ldapsdk.version>3.0.0</com.unboundid-ldapsdk.version>
<org.apache.ant.version>1.9.7</org.apache.ant.version>
<ngee.oam.version>2.0.3</ngee.oam.version>
<cel-version>3.7.3</cel-version>
<avalon-framework-api-version>4.2.0</avalon-framework-api-version>
<xalan-version>2.7.1</xalan-version>
<xercesImpl-version>2.11.0</xercesImpl-version>
<json-version>20140107</json-version>
<curator-framework-version>2.10.0</curator-framework-version>
<akka.version>2.3.4</akka.version>
<scala.version>2.11</scala.version>
<common.akka.version>1.0.1</common.akka.version>
<cql3-version>2.0.2</cql3-version>
<avro-version>1.7.7</avro-version>
<!-- <trace.services.version>0.7.0</trace.services.version> -->
<javax.servlet.version>2.5.0</javax.servlet.version>
<javax.servlet.servlet-api.version>2.5</javax.servlet.servlet-api.version>
<mock-http-server.version>3.0</mock-http-server.version>
<hector-client.version>3.3.1</hector-client.version>
<commons-io.version>2.4</commons-io.version>
<junitparams.version>1.0.2</junitparams.version>
<activemq.version>5.9.1</activemq.version>
<!-- Changed from 2.6 -->
<jersey.version>2.10.1</jersey.version>
<jersey-media-multipart.version>2.5.1</jersey-media-multipart.version>
<jackson.version>1.9.13</jackson.version>
<!-- Changed from 4.3 -->
<com.eclipsesource.jaxrs.publisher.version>4.1</com.eclipsesource.jaxrs.publisher.version>
<com.eclipsesource.jaxrs.jersey.all.version>2.10.1</com.eclipsesource.jaxrs.jersey.all.version>
<org.glassfish.jersey.containers.version>2.10.1</org.glassfish.jersey.containers.version>
<org.apache.felix.eventadmin.version>1.4.2</org.apache.felix.eventadmin.version>
<uncommons.math.version>1.2.2</uncommons.math.version>
<apache.fop.version>1.0</apache.fop.version>
<javax.inject.version>1</javax.inject.version>
<org.ops4j.pax.exam.version>4.7.0</org.ops4j.pax.exam.version>
<pax.url.version>2.4.7</pax.url.version>
<pax.logging.version>1.8.5</pax.logging.version>
<com.xxx.bss.rm.common.datatypes.version>1.20.0</com.xxx.bss.rm.common.datatypes.version>
<com.xxx.bss.ms.registry.version>2.1.0</com.xxx.bss.ms.registry.version>
<bss.osgi.functioncontrol.version>2.1.0</bss.osgi.functioncontrol.version>
<project.msv.fc.version>2.1.0</project.msv.fc.version>
<charging.rf.core.version>1.35.0</charging.rf.core.version>
<com.xxx.bss.osgi.trace.version>1.0.1</com.xxx.bss.osgi.trace.version>
<cpm.cdac.dataenquirey.version>7.1.3</cpm.cdac.dataenquirey.version>
<cpm.cdac.common.version>7.0.0</cpm.cdac.common.version>
<rmca.cdac.version>23.1.2</rmca.cdac.version>
<com.xxx.bss.integrationtest.utils>0.61.0</com.xxxx.bss.integrationtest.utils>
<jive.common.version>0.0.1-alpha.62</jive.common.version>
<karaf.version>3.0.5</karaf.version>
<sigar.version>1.6.4</sigar.version>
<sigar-osgi.version>1.0.0</sigar-osgi.version>
<org.apache.servicemix.bundles.lucene.version>5.3.1_1</org.apache.servicemix.bundles.lucene.version>
<org.apache.servicemix.bundles.jakarta-regexp.version>1.4_1
</org.apache.servicemix.bundles.jakarta-regexp.version>
<org-apache-xmlgraphics-version>1.7</org-apache-xmlgraphics-version>
<org-apache-xmlgraphics-common-version>1.4</org-apache-xmlgraphics-common-version>
<xalan-serializer-version>2.7.1</xalan-serializer-version>
<xml-apis-version>1.4.01</xml-apis-version>
<xml-apis-ext-version>1.3.04</xml-apis-ext-version>
<avalon-framework-version>4.3.1</avalon-framework-version>
<avalon-logkit-version>2.2.1</avalon-logkit-version>
<caf-utility.version>R3B05</caf-utility.version>
<org.eclipse.jetty.version>8.1.3.v20120416</org.eclipse.jetty.version>
<com.springsource.javax.transaction.version>1.1.0</com.springsource.javax.transaction.version>
<com.springsource.javax.jms.version>1.1.0</com.springsource.javax.jms.version>
<org.eclipse.jetty.orbit.javax.servlet.version>3.0.0.v201112011016
</org.eclipse.jetty.orbit.javax.servlet.version>
<commons-lang3.version>3.4</commons-lang3.version>
<com.thoughtworks.paranamer.version>2.7</com.thoughtworks.paranamer.version>
<org.apache.felix.webconsole.version>4.0.0</org.apache.felix.webconsole.version>
<commons-beanutils.version>1.9.2</commons-beanutils.version>
<common-logging.version>1.1.1</common-logging.version>
<commons-fileupload.version>1.2.2</commons-fileupload.version>
<com.squareup.javapoet.version>1.0.0</com.squareup.javapoet.version>
<commons-csv.version>1.1</commons-csv.version>
<cassandra-driver-core.version>3.0.0-E001</cassandra-driver-core.version>
<io.dropwizard.metrics.metrics-core.version>3.1.0</io.dropwizard.metrics.metrics-core.version>
<commons-collections.version>3.2.1</commons-collections.version>
<org.json-osgi.version>20080701</org.json-osgi.version>
<com.eclipsesource.jaxrs.publisher.version>4.1</com.eclipsesource.jaxrs.publisher.version>
<org.eclipse.equinox.common.version>3.6.100-v20120522-1841</org.eclipse.equinox.common.version>
<org.eclipse.equinox.http.jetty.version>3.0.1-v20121109-203239</org.eclipse.equinox.http.jetty.version>
<org.eclipse.equinox.http.servlet.version>1.1.300-v20120522-1841</org.eclipse.equinox.http.servlet.version>
<org.eclipse.equinox.metatype.version>1.2.0-v20120522-1841</org.eclipse.equinox.metatype.version>
<org.eclipse.osgi.services.version>3.3.100-v20120522-1822</org.eclipse.osgi.services.version>
<io.netty.version>4.0.27.Final</io.netty.version>
<io.netty.netty.version>3.8.3.Final</io.netty.netty.version>
<msg-services.version>1.4.2</msg-services.version>
<msg-gateway.version>1.4.2</msg-gateway.version>
<uk.nominet.dnsjnio.version>1.0.3-E005</uk.nominet.dnsjnio.version>
<com.typesafe.config.version>1.2.1</com.typesafe.config.version>
<protobuf-java.version>2.5.0</protobuf-java.version>
<scalabuff-runtime.version>1.3.7</scalabuff-runtime.version>
<jfree.jfreechart.version>1.0.13</jfree.jfreechart.version>
<jfree.jcommon.version>1.0.16</jfree.jcommon.version>
<joda-time.version>2.7</joda-time.version>
<com.google.guava.version>16.0.1</com.google.guava.version>
<javax.ws.rs-api.version>2.0</javax.ws.rs-api.version>
<snappy-java.version>1.1.0-M4</snappy-java.version>
<ical4j.version>1.0.5.2</ical4j.version>
<org.codehaus.groovyall.version>2.2.0</org.codehaus.groovyall.version>
<javax.annotation-api.version>1.2</javax.annotation-api.version>
<validation-api.version>1.1.0.Final</validation-api.version>
<com.springsource.org.apache.commons.codec.version>1.5.0</com.springsource.org.apache.commons.codec.version>
<org.eclipse.tycho.org.eclipse.osgi.version>3.9.0.v20130529-1710</org.eclipse.tycho.org.eclipse.osgi.version>
<geronimo-jms_1.1_spec.version>1.1.1</geronimo-jms_1.1_spec.version>
<org.simpleframework.simple>5.1.6</org.simpleframework.simple>
<zookeeper-version>3.4.8</zookeeper-version>
<kafka.version>0.9.0.0_1</kafka.version>
<org.osgi.version>4.3.1</org.osgi.version>
<!-- Invoice CLI -->
<core.ui.version>1.3.0</core.ui.version>
<charging.core.clamshell>1.5.0</charging.core.clamshell>
<com.github.fge.json.validator>2.2.6</com.github.fge.json.validator>
<com.github.fge.json.schema.core>1.2.5</com.github.fge.json.schema.core>
<com.googlecode.libphonenumber.libphonenumber>7.2.2</com.googlecode.libphonenumber.libphonenumber>
<com.google.code.findbugs.jsr305>2.0.1</com.google.code.findbugs.jsr305>
<net.sf.jopt-simple.jopt.simple>4.6</net.sf.jopt-simple.jopt.simple>
<com.github.fge.uri.template>0.9</com.github.fge.uri.template>
<com.github.fge.jackson.coreutils>1.8</com.github.fge.jackson.coreutils>
<org.mozilla.rhino>1.7R4</org.mozilla.rhino>
<com.github.fge.msg.simple>1.1</com.github.fge.msg.simple>
<com.fasterxml.jackson.core.jackson.databind>2.6.4</com.fasterxml.jackson.core.jackson.databind>
<com.fasterxml.jackson.core.jackson.annotations>2.6.4</com.fasterxml.jackson.core.jackson.annotations>
<com.fasterxml.jackson.core.jackson.core>2.6.4</com.fasterxml.jackson.core.jackson.core>
<com.github.fge.msg.simple>1.1</com.github.fge.msg.simple>
<com.github.fge.btf>1.2</com.github.fge.btf>
<javax.mail.mailapi>1.4.3</javax.mail.mailapi>
<camunda.version>7.3.0</camunda.version>
<com.h2database.h2.version>1.4.190</com.h2database.h2.version>
<org.mybatis.mybatis.version>3.2.8</org.mybatis.mybatis.version>
<org.glassfish.jersey.connectors.version>2.10.1</org.glassfish.jersey.connectors.version>
<org.apache.httpcomponents.httpclient.version>4.3</org.apache.httpcomponents.httpclient.version>
<org.apache.httpcomponents.httpcore.version>4.3</org.apache.httpcomponents.httpcore.version>
<com.xxx.bss.commonschemas.version>0.3.0</com.xxx.bss.commonschemas.version>
<nl.jqno.equalsverifier.version>1.7.5</nl.jqno.equalsverifier.version>
<org.apache.avro.version>1.7.7</org.apache.avro.version>
<org.apache.felix.scr.version>1.8.2</org.apache.felix.scr.version>
<org.quartz-scheduler.version>2.2.2</org.quartz-scheduler.version>
<c3p0.c3p0-version>0.9.1.2</c3p0.c3p0-version>
<org.codehaus.fabric3.api.commonj-version>1.1.0</org.codehaus.fabric3.api.commonj-version>
<javax.ejb.ejb-api-version>3.0</javax.ejb.ejb-api-version>
<org.apache.servicemix.bundles.quartz.version>2.2.2_1</org.apache.servicemix.bundles.quartz.version>
<cassandra-version>2.2.6-E001</cassandra-version>
<com.xxx.bss.rm.cpm.cdac.translation.version>7.0.0</com.xxx.bss.rm.cpm.cdac.translation.version>
<com.googlecode.json-simple.version>1.1.1</com.googlecode.json-simple.version>
<metrics.version>1.0.0</metrics.version>
</properties>
Content in child pom
<parent>
<groupId>com.xxxx.xxx.xx.xxx.top</groupId>
<artifactId>compile</artifactId>
<version>0.6.0-SNAPSHOT</version>
<relativePath />
</parent>
<groupId>com.xxxx.xxx.xx.xxx.messages</groupId>
<artifactId>compile</artifactId>
<version>0.5.0-SNAPSHOT</version>
<name>${project.groupId}.${project.artifactId}</name>
I don't know whether it helps to some extent..
Goals
<goals>clean install -pl script exec:java -Dscript.buildName="invoicing-release" -Dscript.releaseRepository="proj-invoicing-release-local" -Dscript.stagingRepository="proj-invoicing-staging-local" -Dscript.gitWorkArea="${WORKSPACE}/.gitworkarea" -Dscript.repository="${WORKSPACE}/.scriptrepository" -Dscript.mavenSettings="${MAVEN_SETTINGS}" -B -e -Dsurefire.useFile=false --settings ${MAVEN_SETTINGS} -Dorg.ops4j.pax.url.mvn.settings=${MAVEN_SETTINGS} -Dmaven.repo.local=${MAVEN_REPOSITORY} -Dorg.ops4j.pax.url.mvn.localRepository=${MAVEN_REPOSITORY} -Djava.io.tmpdir=${WS_TMP}</goals>
It looks like you are invoking custom Java program performing a variant of mvn release. By convention it is not allowed to release a project which has SNAPSHOT dependencies, i.e. dependencies with version ending on 'SNAPSHOT'. However, your child pom.xml refers to dependency with version 0.5.0-SNAPSHOT. That needs to be changed to a fix version (one not ending on SNAPSHOT), again by convention this would be 0.5.0. It is also likely that the version 0.5.0 of your dependency is not available yet and therefore you need to perform the release for that project beforehand.
The convention for the versioning of maven projects is as follows. During the development are jars versioned with xx-SNAPSHOT. For the xx-SNAPSHOT-versioned jars it is allowed to produce a new jar containing new features and version the new jar with the same xx-SNAPSHOT version (i.e., replace one given xx-SNAPSHOT jar with a new one). Then once the development is finished the project will be released and the jar will be versioned with fixed version xx (no SNAPSHOT anymore). From then on the jar versioned with fixed version xx will not be replaced anymore. Of course if jar versioned xx is not allowed to change then also all of his dependencies must not change, i.e. all dependencies must be in fixed version.
Aparently the program started from the jenkins job checks if the convention is adhered to and after finding the dependency versioned 0.5.0-SNAPSHOT it requires that this is fixed first.
Btw there is probably an error in the artifactId of your dependency - compile is usually a value for the <scope> element.
When I am deploying maven project using the command
mvn clean install
I got the following error
error :
Failed to execute goal org.codehaus.mojo: tomcat-maven-plugin:1.1 :
deploy-only (deault - cli) on project testapp : Cannot invoke Tomcat
Manager : Server returned HTTP response code : 403 for URL : http
: //localhost : 8080/manager/html/deploy?path=%2Ftestapp&war = ->
I changed the code in pom.xml
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<version>1.1</version>
<configuration>
<url>http://localhost:8080/manager/html</url>
<warFile>target/testapp.war</warFile>
</configuration>
</plugin>
when I changed the configuration url
http://localhost:8080/manager/html
chaned to
http://localhost:8080/manager/text
then my maven project was deployed successfully.
am I doing correct?
May I know the exact difference between them?
Thank You.
Basically, maven is trying to invoke commands in tomcat.
Tomcat 7 provides separate manager roles for the GUI (manager-gui), status (manager-status), scripting (manager-script) and JMX proxy (manager-jmx), defined in webapps/manager/WEB-INF/web.xml.
A user with role - manager-script can't use tomcat's web-interface ( i.e. /html URL of manager) while manager-script role is the one used by maven plug in.
So basically, you have to understand difference between Tomcat's manager-script and manager-gui manager roles. /html is not accessible for role - manager-script and only accessible for manager-gui role.
Coming to your original question, /text URL means that you are using tomcat's text-based-interface and /html URL means that you are using tomcat's web-interface.
Some additional information is here
The /manager/html path is the HTML interface to the Tomcat manager. The /manager/text path is the text based interface to the Tomcat manager that allows you to run commands such as deployments or reloads and considered the tools friendly interface. /manager/text is the path used by the Tomcat Maven plugin.