I am handling multi module Maven project in which I have defined a property productversion which is inherited by all child modules. I am using this even in the parent tag defined in child pom's. The build when ran is successful and the correct version jar is being deployed in local repository.
Problem I am encountering is that I am not able to build a child module in isolation. it is saying "Non-resolvable parent pom" . this might be because of using this property and maven install the pom file in repository and then on running; parent child relationship are read from local repository pom only.
Is this issue addressed in any of the Maven version?
Can we update the pom in local repo as part of the build process?
I would strongly recommend to upgrade to a more up-to-date version of Maven cause Maven 2.2.1 is EoL for a year now (has been done in february 2014).
To solve what you like to achieve you can use Maven 3.2.5 (or Maven 3.3.1)
Excerpt from the release notes:
A simple change to prevent Maven from emitting warnings about versions
with property expressions. Allowed property expressions in versions
include ${revision}, ${changelist}, and ${sha1}. These properties can
be set externally, but eventually a mechanism will be created in Maven
where these properties can be injected in a standard way. For example
you may want to glean the current Git revision and inject that value
into ${sha1}. This is by no means a complete solution for continuous
delivery but is a step in the right direction.
Related
I would like to use the jgitver maven plugin to automatic define the version of eclipse plugins, features, repository that are built with tycho in pomless mode.
The version management of this 3 plugins are:
jgitver computes a version depending on git tree and tags, create a logical copy of pom, set the new version and associate the new pom to the current plugin in the maven reactor.
For tycho, version are defined in pom and in manifest.mf or feature.xml files. A version consistency check is performed.
When the pom is not defined, pomless maven generates a temporary pom file named .polyglot.build.properties using versions defined in manifest or feature file.
The input path are defined here and depends on PolyglotModelUtil.
The easier way would be a Jgitver evolution to locally update the feature.xml and manifest.MF. It would be a bad idea because a local file would be modified that is not compliant with the plugin philosophy.
A better way would be a Jgitver evolution to generate temporary feature.xml and manifest.MF files that would have been updated with the computed version. Then tycho and tycho-pomless should be forced to use them.
It seems to be possible if i succeed in setting a new ModelProcessor.LOCATION option
Do you think it's an effective way to solve this compatibility problem?
Do you see an alternative?
Thanks for your help.
You could also use directly the jgitver library to participate into your build environment ; it is a pure java library.
The library is the base of both the maven and gradle plugins.
I'm working in eclipse and I have a problem that I can't import my personal java libraries.
I created the libraries and 'installed' them into my local maven repo (using mvn install). This created a subdirectory related to the 'version' name that was in the POM file from when I ran the command. Which seemed fine.
So in this directory there where the usual jar files and other stuff.
When I released this file I manually changed the name of the version in the POM. going from 0.0.1-SNAPSHOT to 0.0.1-RELEASE
This seems to have worked as I would have expected.
However I can't seem to find import the new release jar.
Using the maven repositories browser in eclipse I can see that the new artifact is in the 'local' repository.
I try to add the dependency in the following methods:
Select the main project -> Maven -> add dependency.
This adds the dependency details into the pom but with a type value detail of <type>pom.lastUpdated</type>
Select the project pom.xml file -> Maven -> add dependency.
This time the artifact for the 0.0.1-RELEASE is greyed out I can select it, but I guess nothing is actually happening.
The original 0.0.1-SNAPSHOT it selectable, and if I use this I do not have a <type> detail in the pom.
I don't understand why there is a difference in the RELEASE and SNAPSHOT artifacts, as they have both been generated in the same way, and clearly they are both visible in the browser, the contents of the directory on disk are the same. The file names and contents are identical with the exception of the word RELEASE or SNAPSHOT.
I know that I can simply add in the RELEASE jar to my build path, but this seems to be a ridiculous thing to have to do if I intend to use maven (or do I need to do this).
I don't want to use an external repo for storing my artifacts, and I'm not too keen to go to the trouble of installing nexus (or similar) on my local machine (just because I've had trouble with it in the past).
What am I missing so as I can get my maven project to see my local repository and all its artifacts.
Thanks in advance.
David
ps I've already tried things such as mvn dependency:purge-local-repository which definitely pulled in / updated all the local jar dependencies.
So I've managed to work around my problem.
As such this solution is ridiculous, and breaks all the purpose of maven.
So I found (from running maven from the cli) that there was an error in the parent of the project I was attempting to use.
The parent was missing a direct link to the scm plugin (version error).
Once I solved this problem, I then returned to the sub project, and got a lot of errors from missing stuff from the parent.
Essentially it was not 'seeing' all the log4j dependencies.
The solution (well non-solution really).
Add all the log4j dependencies to the sub project.
Edit in SCM and surefire test plugins (as it also started to fail the test code due to missing junit).
So this is great.
I have to define all my dependencies on log4j and in my sub / child project's pom.xml file.
I also need to define them all in my parent's pom.
As it then still refused to run tests in my new project (that used the above as a dependency), and refused to find log4j also. I then decided to add all of these as dependencies for my current project.
Great.
I thought the whole point of maven was I could define my dependency on log4j in my my logging library that I use (which is the dependency), and then it would 'automagically' pull in all the required from this dependency.
Clearly not.
As stated at the start. This is NOT AN ANSWER it is a crazy work around.
My logging library that I use should be able to define its own requirement on a specific log4j version (such as moving from log4j to log4j2), and then when I include this as a maven dependency any change to the required dependency should be seen automatically.
But No : I have to import the dependency on log4j in my other projects also. So now if I had updated my logging library from log4j to log4j2 I would need to go to all my project that use this library and update their pom's to ensure that I have the correct version of log4j.
Seems the whole point of maven has just been lost!
Can someone please tell me where I am going wrong!
David.
I am including another pom file as parent in my current maven project.
There is a dependency for hibernate 3.3.2 defined in parent pom file.
I want to use the latest version of hibernate 4.3.5 in my current project. my question is how to exclude the older version so that antlr and other dependencies gets properly generated in my war file.
I also want my war file not to have duplicate jar files
Please help
Just put the version you want in your own POM file.
When there are multiple versions of same artifact resolved transitively (through parent, or through transitive dependencies), Maven is going to resolve find the version to use. Normally it use the "nearest" one. If you are declaring the dependency in the POM of the project itself, it will always be the "nearest" and hence will be used.
In your case, just put hibernate:4.3.5 in your POM, and hence this version will be taken instead of hibernate:3.3.2 (which is declared in parent), no related transitive dependencies of hibernate:3.3.2 will be included in project.
Just one thing to be careful: such kind of version resolution is done only for same artifact, which means, artifact with same Group ID and Artifact ID. If the old version in parent is org.hibernate:hibernate:3.3.2 while the newer version is org.hibernate:hibernate-core:4.3.5, it will not work. In such case, you need some trick to explicitly exclude the dependency from parent, for which you can look into https://stackoverflow.com/a/7898553/395202 for one method.
In build section of my effective pom there is a Maven plugin that I don't want to use (it was used before, but now I want to remove it).
I removed this plugin from every parent of my project, but is is still applied.
How do I find out where this plugin declaration come from?
UPDATE:
It turns out this plugin was an implicit dependency of another one. It was not declared as such, but referenced from plugin's components.XML leading to runtime dependency injection. The problem was found by pure luck. I think the question is still relevant - it should be possible to find implicit plugin dependencies without wasting a day or two.
Have you run
mvn install
on the parent pom when you deleted the plugin from there?
When you run mvn from submodule it actually looks into your local repository for parent/siblings modules (jars, poms), not to filesystem (compared to maven using the result of the build when you run whole parent project build with submodules).
If it doesn't help, have a look if it's not coming from super pom. You can see super pom on maven website:
http://maven.apache.org/ref/3.0.5/maven-model-builder/super-pom.html
I want to create maven project in Netbeans. So, I do File->New project->Maven->Java Application. After that I try to build the project and get error:
The POM for org.apache.maven.plugins:maven-surefire-plugin:jar:2.10 is missing, no dependency information available.
But I can build this project from command line with mvn compile. Could uou tell me what is the problem with Netbeans?
NetBeans is using 3.0.4 maven by default. Unless you change that in Tools/Options menu. Are you building with 3.0.4 as well or are you using some earlier versions (2.x)?
That would explain the behaviour because 3.0.4 will not blindly rely on what artifact is in local repository but some additional metadata is also consulted to make sure your project build with the given set of defined repositories.
A common example when the problem occurs to me.
I use central directly everything downloads. when I later add a mirror, all artifacts are checked again through the mirror to make sure they are accessible. if teh Mirror doesn't actually mirror central, I get an error that way.
Another common example is: when building with 2.x, the additional metadata is not written, when later building with 3.0.4, all remote context is checked no matter what is present in local repo and the additional metadata files are constructed.