1. Background
My maven project has a lot of modules and submodules with jars and wars and everything works. I also can deploy it on server without any problem.
I decided to follow this maven naming conversion, I am making some tests with project.name and project.build.finalName to have an appropriate name.
The pattern I defined to create project.name for the root artifact is company-${project.artifactId} and for the modules and sub-modules is ${project.parent.name}-${project.artifactId}:
company-any-artifact-any-module1
company-any-artifact-any-module2-any-submodule1
company-any-artifact-any-module2-any-submodule2
The pattern for project.build.finalName is ${project.name}-${project.version}:
company-any-artifact-any-module1-1.0.jar
company-any-artifact-any-module2-any-submodule1-2.0.jar
company-any-artifact-any-module2-any-submodule2-3.0.war
But instead of producing these files, maven gives me a StackOverflowError.
2. The example to reproduce the error
You can clone this example from github: https://github.com/pauloleitemoreira/company-any-artifact
In github, there is the master branch, that will reproduce this error. And there is only-modules branch, that is a working example that uses ${project.parent.name} to generate the jar finalName as I want.
Let's consider a maven project with one root pom artifact, one pom module and one submodule.
-any-artifact
|
|-any-module
|
|-any-submodule
2.1 any-artifact
<?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.company</groupId>
<artifactId>any-artifact</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<name>company-${project.artifactId}</name>
<modules>
<module>any-module</module>
</modules>
<!-- if remove finalName, maven will not throw StackOverflow error -->
<build>
<finalName>${project.name}-${project.version}</finalName>
</build>
</project>
2.2 any-module
<?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>
<parent>
<artifactId>any-artifact</artifactId>
<groupId>com.company</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<groupId>com.company.any-artifact</groupId>
<artifactId>any-module</artifactId>
<packaging>pom</packaging>
<name>${project.parent.name}-${project.artifactId}</name>
<modules>
<module>any-submodule</module>
</modules>
</project>
2.3 any-submodule
<?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>
<parent>
<artifactId>any-module</artifactId>
<groupId>com.company.any-artifact</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<groupId>com.company.any-artifact.any-module</groupId>
<artifactId>any-submodule</artifactId>
<name>${project.parent.name}-${project.artifactId}</name>
</project>
3. Problem
When try to mvn clean install, maven gives me a StackOverflowError:
Exception in thread "main" java.lang.StackOverflowError
at org.codehaus.plexus.util.StringUtils.isEmpty(StringUtils.java:177)
at org.codehaus.plexus.util.introspection.ReflectionValueExtractor.evaluate(ReflectionValueExtractor.java:194)
at org.codehaus.plexus.util.introspection.ReflectionValueExtractor.evaluate(ReflectionValueExtractor.java:163)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:266)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:143)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:174)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:143)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:429)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:143)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:174)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:143)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:429)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:143)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:174)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:143)
It is important to know that the error occurs only when we are working with submodules. If we create a project with a root POM artifact and a jar module, the error don't occur.
4. The question
Why this error occurs only when we are using submodules?
Any suggestion to solve my problem? Should I forget it and set project.name and project.build.fileName manually for each project, following the pattern I want?
IMPORTANT UPDATED:
Some answers just say to use &{parent.name}, but it does not work. Please, it is a question with a bounty, consider test your solution with Maven version 3.3.9, before answering this question.
Maven version 3.3.9
Edit - Adding details to the question with the phase when the error occurs, things are working fine until the prepare-package phase, but the StackOverflow occurs at the package phase on maven lifecycle for the project.
The strict answer to your question is that ${project.parent.name} will not be resolved as part the model interpolation process. And in turn, you have a StackOverflowError, in a completely different place of the code, namely when... building the final JAR of your project.
Part 1: The Model built is wrong
Here's what happens. When you're launching a Maven command on a project, the first action it takes is creating the effective model of the project. This means reading your POM file, reasoning with activated profiles, applying inheritance, performing interpolation on properties... all of this to build the final Maven model for your project. This work is done by the Maven Model Builder component.
The process of building the model is quite complicated, with a lot of steps divided in possibly 2 phases, but the part we're interested in here in the model interpolation part. This is when Maven will replace in the model all tokens denoted by ${...} with a calculated value. It happens after profiles are injected, and inheritance is performed. At that point in time, the Maven project, as represented by a MavenProject object, doesn't exist yet, only its Model is being built. And it is only after you have a full model that you can start constructing the Maven project from it.
As such, when interpolation is done, it only reasons in terms of the information present in the POM file, and the only valid values are the ones mentioned in the model reference. (This replacement is performed by the StringSearchModelInterpolator class, if you want to look at the source code.) Quite notably, you will notice that the <parent> element in the model does not contain the name of the parent model. The class Model in Maven is actually generated with Modello from a source .mdo file, and that source only defines groupId, artifactId, version and relativePath (along with a custom id) for the <parent> element. This is also visible in the documentation.
The consequence of all that, is that after model interpolation is performed, the token ${project.parent.name} will not be replaced. And, further, the MavenProject constructed from it will have a name containing ${project.parent.name} unreplaced. You can see this in the logs, in your sample project, we have
[INFO] Reactor Build Order:
[INFO]
[INFO] company-any-artifact
[INFO] ${project.parent.name}-any-module
[INFO] ${project.parent.name}-any-submodule
Meaning that Maven consider the actual name of the project any-module to be ${project.parent.name}-any-module.
Part 2: The weirdness begins
We're now at a time when all of the projects in the reactor were correctly created and even compiled. Actually, everything should theoretically work just fine, but with only completely borked names for the projects themselves. But you have a strange case, where it fails at the creation of the JAR with the maven-jar-plugin. The build fails in your example with the following logs:
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) # any-submodule ---
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] company-any-artifact ............................... SUCCESS [ 0.171 s]
[INFO] ${project.parent.name}-any-module .................. SUCCESS [ 0.002 s]
[INFO] ${project.parent.name}-any-submodule ............... FAILURE [ 0.987 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
meaning that something went wrong well after the model was built. And the reason is that the plugin injects the name of the project as a parameter:
/**
* Name of the generated JAR.
*
* #parameter alias="jarName" expression="${jar.finalName}" default-value="${project.build.finalName}"
* #required
*/
private String finalName;
Notice project.build.finalName as the default value of the generated JAR name for the submodule. This injection, and the interpolation of the variables are done by another class called PluginParameterExpressionEvaluator.
So what happens in this:
The JAR plugin on the any-submodule injects the final name of the project, named ${project.parent.name}-any-submodule.
Thanks for inheritance from the parent projects, and the declaration of <finalName> in your top-most POM project, it inherits <finalName>${project.name}-${project.version}</finalName>.
Maven now tries to interpolate ${project.name} for any-submodule.
This resolves to ${project.parent.name}-any-submodule, due to Part 1.
Maven tries now to interpolate ${project.parent.name} for any-submodule. This works correctly: the MavenProject is built and getParent() will be called on the project instance, returning the concrete Maven parent project. As such, ${project.parent.name} will try to resolve the name of any-module, which is actually ${project.parent.name}-any-module.
Maven now tries to interpolate ${project.parent.name}-any-module, but still on the any-submodule project instance. For PluginParameterExpressionEvaluator, the root "project" on which to evaluate tokens hasn't changed.
Maven now tries to interpolate ${project.parent.name} on any-submodule, which, again, works correctly and returns ${project.parent.name}-any-module.
Maven now tries to interpolate ${project.parent.name} on any-submodule... which works and returns ${project.parent.name}-any-module so it tries to evaluate ${project.parent.name}...
And you can see the endless recursion happening here, which results in the StackOverflowError you have. Is this a bug in PluginParameterExpressionEvaluator? This is unclear: it reasons on model values that were not correctly replaced in the first place. In theory, it could handle the special case of evaluating ${project.parent} and create a new PluginParameterExpressionEvaluator working on this parent project, instead of always working on the current project. If you feel strongly about this, feel free to create a JIRA issue.
Part 3: Why it works without the sub module
With what has been said above, you could now deduce why it works in this case. Let's reason with what Maven needs to do to evaluate the final name, as has to be injected in the Maven Jar Plugin:
The JAR plugin on the any-module injects the final name of the project, named ${project.parent.name}-any-module.
Thanks for inheritance from the parent project, and the declaration of <finalName> in your top-most POM project, it inherits <finalName>${project.name}-${project.version}</finalName>.
Maven now tries to interpolate ${project.name} for any-module.
This resolves to ${project.parent.name}-any-module, same as before.
Maven tries now to interpolate ${project.parent.name} for any-module. Just like before, this works correctly: the MavenProject is built and getParent() will be called on the project instance, returning the concrete Maven parent project. As such, ${project.parent.name} will try to resolve the name of any-artifact, which is actually company-any-artifact.
Interpolation has succeeded and stops.
And you don't have any errors.
As I stated in my answer to Difference between project.parent.name and parent.name ans use of finalName in pom.xml
Let's first look at the basics:
as stated in POM Reference:
finalName: This is the name of the bundled project when it is finally built (sans the file extension, for example: my-project-1.0.jar). It defaults to ${artifactId}-${version}.
name: Projects tend to have conversational names, beyond the artifactId.
So these two have different uses.
name is purely informational and mainly used for generated documentation and in the build logs. It is not inherited nor used anywhere else. It is a human readable String and can thus contain any character, i.e. spaces or characters not allowed in filenames. So, this would be valid: <name>My Turbo Project on Speed!</name>. Which is clearly at least a questionable file name for an artifact.
as stated above, finalName is the name of the generated artifact. It is inherited, so it should usually rely on properties. The only two really useful options are the default ${artifactId}-${version} and the versionless ${artifactId}. Everything else leads to confusion (such as a project named foo creating an artifact bar.jar). Actually, My turbo Project! would be valid, since this is a valid filename, but in reality, filenames like that tend to be rather unusable (try adressing a filename containing ! from a bash, for example)
So, as to why the Stackoverflow happens:
name is not inherited
project.parent.name also is not evaluated during interpolation, since the name is one of the few properties which are completey invisible to the children
parent.name actually used to work in older Maven versions, but more due to a bug (also it is deprecated to access properties without the leading project).
a missing property is not interpolated, i.e. stays in the model as is
Therefore, in your effective pom for any-submodule, the value for finalName is (try it with mvn help:effective-pom) still: ${project.parent.name}-any-submodule
So far so bad. Now comes the reason for the StackOverflow
Maven has an addtional feature called late interpolation that evaluates values in plugin parameters when they are actually used. This allows a pluing to use properties that are not part of the model, but are generated by plugins earlier in the lifecycle (this allows, for instance plugins to contribute a git revision to the final name).
So what happens is this:
edit: made the actual reason for the error clearer (see comments):
The finalName for the jar plugin is evaluated:
#Parameter( defaultValue = "${project.build.finalName}", readonly = true )
The PluginParameterExpressionEvaluator kicks in and tries to evaluate the final name (${project.parent.name}-any-submodule, which contains a property expression ${project.parent.name}.
The evaluator asks the model, which in turn returns the name of the parent project, which is: ${project.parent.name}-any-module.
So the evaluator tries to resolve this, which return ${project.parent.name}-any-module (again), since a property is always resolved against the current project, the cycle begins again.
A StackOverflowError is thrown.
How to solve this
Sadly, you can't.
You need to explicitly specify name (as well as artifactId) for every project. There is no workaround.
Then, you could let finalName rely on it. I would however advise against it (see my answer to Difference between project.parent.name and parent.name ans use of finalName in pom.xml)
The problem in changing the final name that way is that the name of the locally build artifact and the one in the repository would differ, so locally your artifact is named any-artifact-any-module-any-submodule.jar, but the artifact name in your repository would be still any-submodule.jar
Suggestion
If you really need to differentiate that fine, change the artifactId instead: <artifactId>artifact-anymodule-anysubmodule</artifactId>.
Don't use dashes for the shortname to differentiate between levels of your structure.
hint: the path of the module can be still anymodule, is does not need to be the actual artifactId of the module!
While we are at it: use the name for what it was intended, to be human readable, so you might consider something more visually appealling (since this is the name that appears in the build log): <name>Artifact :: AnyModule :: AnySubModule</name>.
It is actually very easy to simply create the name entries automatically using a very short groovy script.
You could also write an enforce rule to enforce the naming of the artifactIds
This is issue with attribute inheritance.
Try to use ${parent.name} instead of ${project.parent.name}.
Look at: Project name declared in parent POM isn't expanded in a module filtered web.xml.
---UPDATE---
Benjamin Bentmann (maven committier) said: "In general though, expressions of the form ${project.parent.*} are a bad practice as they rely on a certain build state and do not generally work throughout the POM, giving rise to surprises".
https://issues.apache.org/jira/browse/MNG-5126?jql=text%20~%20%22parent%20name%22
Maybe you should consider is using ${project.parent.*} is a good way.
change pom.xml in company-any-artifact to below and it will work .
<?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.company</groupId>
<artifactId>any-artifact</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<name>${project.groupId}</name>
<modules>
<module>any-module</module>
</modules>
<!-- if remove finalName, maven will not throw StackOverflow error -->
<build>
<finalName>${project.groupId}-${project.version}</finalName>
</build>
</project>
change pom.xml in submodule to below
<?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>
<parent>
<artifactId>any-artifact</artifactId>
<groupId>com.company</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<groupId>com.company.any-artifact</groupId>
<artifactId>any-module</artifactId>
<packaging>pom</packaging>
<!-- <name>${project.parent.name}-${project.artifactId}</name> -->
<modules>
<module>any-submodule</module>
</modules>
<build>
<finalName>${project.parent.name}-${project.artifactId}</finalName>
</build>
</project>
change submodule pom.xml to below
<?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>
<parent>
<artifactId>any-module</artifactId>
<groupId>com.company.any-artifact</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<groupId>com.company.any-artifact.any-module</groupId>
<artifactId>any-submodule</artifactId>
<!-- <name>${project.parent.name}-${project.artifactId}-${project.version}</name> -->
<build>
<finalName>company-${project.parent.name}-${project.artifactId}-${project.version}</finalName>
</build>
</project>
then the output was : company-any-module-any-submodule-1.0-SNAPSHOT
Interesting! I started off cloning the repo and reproducing the error. I would appreciate any leads that can be taken from any of the steps mentioned below that helped me debug the problem -
Maven Life Cycle Phases
The phase where the issue occurred was the package phase of the lifecycle. Meaning mvn package reproduces the issue with your project.
Went through the stack trace lines in the error. Getting to know its the expression evaluation where it's failing -
#Override
public Object evaluate( String expr ) throws ExpressionEvaluationException {
return evaluate( expr, null ); // Line 143
}
It's also not the finalName attribute which was causing it. Since specifying the default value of the same
<finalName>${artifactId}-${version}</finalName>
works fine with the same project configs.
Then tried changing the packaging of the any-submodule as
<packaging>pom</packaging>
and the error went away. Meaning while packaging as jar , war etc the expression evaluation is different and results in an overflow.
Modifying the any-module or the any-submodule pom.xml content I can say with some confidence that it's the project.parent.name that is causing a recursion in evaluating the expression and causing the stack overflow(How? - is something I am still looking for..). Also, changing
<name>${project.parent.name}-${project.artifactId}</name>
to
<name>${parent.name}-${project.artifactId}</name>
works for me in the sense that I do not get an error but the jar generated is of type -
${parent.name}-any-module-any-submodule-1.0-SNAPSHOT.jar and
${parent.name}-any-submodule-1.0-SNAPSHOT respectively with the change.
Looking for the solution according to the requirement, I am seeking a tail to the recursion that you are using.
Note - Still working on finding an appropriate solution to this problem.
Related
I want to pass parameters from the pom.xml to the java files.
I tried to set a properties in the pom.
The java files didn't read them.
---- Here's the 2 minute introduction to filtering resource files ----
First you need to specify that you want your resource filtered, by adding a "filtering" element, containing the "true" value.
In this example, I reconfigured the default resource directory:
<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.edwinbuck.examples</groupId>
<artifactId>template-value</artifactId>
<version>1.0-SNAPSHOT</version>
<name>Template example</name>
<description>
A simple pom file that copies a value into a propertie file.
</description>
<licenses>
<license>
<name>The MIT License</name>
<url>http://www.opensource.org/licenses/mit-license.php</url>
<distribution>repo</distribution>
</license>
</licenses>
<properties>
<project.build.outputEncoding>UTF-8</project.build.outputEncoding>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.project.outputEncoding>UTF-8</project.project.outputEncoding>
<property.to.be.copied>some-value</property.to.be.copied>
</properties>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
</project>
This implies that the default resource directory exists, which (to match the example) should be at
${basedir}/src/main/resources
Inside that directory, there should be a resource (a file). For this example, the file's contents look like
maven.build.number=${project.version}
customValue=${property.to.be.copied}
And the file is named
${basedir}/src/main/resources/example.properties
Upon a mvn build this will create a copy of the file into
${basedir}/target/classes/example.properties
but the contents of the file under the target directory will be
maven.build.number=1.0-SNAPSHOT
customValue=some-value
I hope this example (tested on Maven 3.5.4) will provide you with enough of a template to make better use of the documentation.
Cheers!
---- Original posts follow ----
Maven strives to have reproducible builds. That means that if the build required input, you would have to provide exactly the same input to get a proper reproduction, each time.
Effectively this won't happen, as you might be unavailable, or might not type in the same item. So, I would look to the src/main/resources directory and create a properties file. Put the settings in there, and then rewrite your program to use settings from there.
When reading the properties file, there are a number of options. Look to the technique that loads the properties file from the ClassLoader, as it is the approach that has the best maintainability, and offers the most amount of flexibility in the placement of the properties file.
In the event you want to support more than one kind of build, and all the builds can be done without human input, you might create a maven profile for each build. That said, each profile will still be a reproducible build.
--- I see you've changed your wording, here's an update ---
Use a template, and the copy-resources target of the resources plugin. You can leverage it to replace items in the resources as they get moved into the target directory
I have a multi module maven project, and in the dao module, I added the JSON-IO dependency. When I try to deserialize my object, it gives me:
Exception in thread "main" com.cedarsoftware.util.io.JsonIoException: Class listed in #type [hu.kleatech.projekt.model.Employee] is not found
The class name is correct, the Employee is public, and the dao has the module as dependency. What could have gone wrong?
Edit: Since this is an old question and have been answered long ago, I'm deleting the github repository that I made specifically for this question. The solution to the problem is in the accepted answer, the exact code is not relevant.
Please try adding an empty constructor to Employee class.
Edit: Actually, while adding an empty constructor solves the problem, it is not necessarily required. Json-IO "will make a valiant effort to instantiate passed in Class, including calling all of its constructors until successful. The order they tried are public with the fewest arguments first to private with the most arguments."
(copied from MetaUtils.java javadoc)
Also, when calling a multi-argument constructor, the library fills the arguments with nulls and defaults for primitives. Then any exceptions thrown during the constructor call is ignored. In your case, a NullPointerException was thrown, because the constructor is not null-safe. So either modify the constructor so that it can handle nulls, or add an empty constructor.
Maven dependency configuration is hierarchical from <parent> element not from <modules> element.
It means that in the project's pom.xml file where you have dependency on "JSON-IO dependency" you do not have dependency on your dao project or where that class is.
<modules> stands only to define what projects to build. Order of modules definition does not matter, since Maven detects order by required dependencies
So, you can define dependency in <parent> pom.xml either in
<dependencies> element. then all children will have it.
or in <dependencyManagement> - then children who need it can include it in their <dependencies> without common configurations like version, scope etc...
look at quite similar answer here:
How to minimize maven pom.xml
As per your project and modules Pom your main Pom should have modules in following order ....
<modules>
<module>core</module>
<module>controller</module>
<module>service</module>
<module>dao</module>
</modules>
service depends on core so core should be build before service
dao depends on service and core both so dao should be after core and service.
Employee class is available in core and it should be available in core jar.
You should add depencyManagent in main Pom and then add all the module as dependencies in dependencyManagement so whoever adds your main Pom as dependency will be able to access all your jars.
Once you change order build your project again and then update your maven project.
If this code is being used in another project then make sure that you have uploaded jars to repository (mvn deploy) so whoever uses it can download it when they are building their project.
One way to verify whether this jar is downloaded in the main project where it is used or not is check in project explorer there would be a Maven Dependencies section where you can see all dependency jars and check if core is present or not.
I am not sure what controller module is doing in main Pom as I couldn’t find a module by that name in your project so you should either remove it or add a module (folder) for it.
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.
I am working on a maven based project. I have a parent pom file for the parent module and a child pom file for the child module. In parent module I am using a custom property (databaseType) and it is declared in parent pom.
<properties>
<databaseType>${databaseType}</databaseType>
</properties>
While building the application, I am passing it as -D argument and its building successfully. However, when I am creating a maven project in eclipse, I am getting below error in child pom (Though the maven build is happening fine)
Project build error: Resolving expression: '${databaseType}': Detected
the following recursive expression cycle in 'databaseType': [databaseType]
What could be the issue? Any help is appreciated.
The problem is that both the argument you pass with -D and the property have the same name. If you provide the argument, it works because when maven resolves the expression it first finds the provided argument by -D databaseType and then assigns that value to the <databaseType> property. If the argument is missing, maven tries to resolve the expression but only finds the definition of the <databaseType> property in the same pom, which creates a circle.
Maven and Eclipse are either using different approaches to resolve variables here (which might a bug in eclipse) or it's caused by some misconfiguration. I would guess that passing the variable with -D is not working in Eclipse for some reason.
The example doesn't really do anything anyways. If ${databaseType} is available, you shouldn't need to explicitly define the property again. Or use a different property name in the parent pom if it makes sense, like this:
<properties>
<databaseType>${defaultDatabaseType}</databaseType>
</properties>
This doesn't help if the argument is missing though. I would use the enforcer plugin to make sure it the property is defined.
I'm having some troubles with IDE configurations. I can't update my maven project.
Could not calculate build plan: Failed to parse plugin descriptor for org.apache.maven.plugins:maven-war-plugin:2.1.1 (C:\Users\dolgopolov.a\.m2\repository\org\apache\maven\plugins\maven-war-plugin\2.1.1\maven-war-plugin-2.1.1.jar): invalid LOC header (bad signature)
Failed to parse plugin descriptor for org.apache.maven.plugins:maven-war-plugin:2.1.1 (C:\Users\dolgopolov.a\.m2\repository\org\apache\maven\plugins\maven-war-plugin\2.1.1\maven-war-plugin-2.1.1.jar): invalid LOC header (bad signature)
at pom.xml:
<?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/maven-v4_0_0.xsd">
Marker is locating near xml version and xmlns. It says:
The word 'xml' is not correctly spelled
The word 'xmlns' is not correctly spelled
What's wrong with sts?
First of all: The markers you see are just your IDEs spell checker. It doesn't know those two words but they are right in your pom. You can ignore it.
As for you actual problem: Your downloaded dependency might be corrupt in some way. Try deleting the folder C:\Users\dolgopolov.a\.m2\repository\org\apache\maven\plugins\maven-war-plugin and try to build again. Maven should re-dowload the dependency, hopefully correctly this time.
If this doesn't work you might be behind a proxy and cannot download depencies from the Maven repository correctly at all.