I am using maven-gae-plugin from http://code.google.com/p/maven-gae-plugin/ to create a multi-module project using inheritance (parent-project reference)
The structure that I have is as below:
|
`-- pom.xml
|-- base-api-project (packaging=jar)
| `-- pom.xml
|-- main-www-project (packaging=war)
| `-- pom.xml
The root pom.xml is configured as parent + aggregator (with reference to the modules).
When I build using the root pom.xml, everything is compiled and packaged great.
However, when I run mvn gae:run in the main-www-project folder, I get an error that the base-api-project is not found in the registered repositories. I scans all registered repositories...
But my question is... if it's already there in ~/.m2/repository, then why should I hunt across the net?
I there something wrong that I'm doing?
When using snapshot versions maven will always look for the latest snapshot, whereas releases will be resolved locally first.
However, each artifact in the local repo will also need the corresponding POM, and that POM may declare dependencies that are not in the local repo, or are snapshot versions (etc. recursively).
Related
I'm working on a Spring multi-module project. One of the child modules has some files under /test/resources/certs/ and a property file under /test/resources/test-ssl.properties.
───resources
│ test-ssl.properties
├───certs
│ test-keystore.p12
test-ssl.properties has a property that points to /certs/test-keystore.p12file.
server.ssl.trust-store=/certs/test-keystore.p12
In child modules pom.xml I'm using Maven plugin test-jar and in parent pom I've added this module as a dependency.
With this structure integration test present in parent module is able to successfully read classpath:test-ssl.properties but it fails to resolve its property value.
Spring throws FileNotFoundException: \certs\test-keystore.p12. What change we can do to make Spring read a file present in test jar?
Also tried the following patterns,
server.ssl.trust-store=classpath:/certs/test-keystore.p12
server.ssl.trust-store=classpath:certs/test-keystore.p12
server.ssl.trust-store=classpath*:/certs/test-keystore.p12
Please note that this test property doesn't try to load any certificate. It is there because property placeholder can find some value for the property during build.
Issue is resolved by changing integration-test phase to process-test-resources.
Credit goes to the following answer of Pascal Thivent:
The content of the test output directory (target/test-classes) is on the class path, not src/test/resources. But resources under src/test/resources are copied to the test output directory by the resources:testResources goal (which is bound by default to the process-test-resources phase).
I've a multi-module maven application that we need build through Jenkins.
Project structure is like:
a.xml
<artifactId>parent-1</artifactId>
<modules>
<module>lookup-1</module>
<module>lookup-2</module>
</modules>
lookup-1.xml
<artifactId>lookup-1</artifactId>
<parent>
<groupId>com.lookup</groupId>
<artifactId>parent-1</artifactId>
<version>1.0.1-SNAPSHOT</version>
</parent>
<name>lookup-1</name>
lookup-2.xml
<artifactId>lookup-2</artifactId>
<parent>
<groupId>com.lookup</groupId>
<artifactId>parent-1</artifactId>
<version>1.0.1-SNAPSHOT</version>
</parent>
<name>lookup-2</name>
now,
mvn clean install -f a.xml works fine. For this I created one Jenkins job.
Now, same as a.xml, I've another project with b.xml. b.xml has the same code as of a.xml except different Ids. So, I've created another jenkins job for b.xml.
Both jobs work fine. But, now I want to build both these project from single Jenkins job based on which project we commit in Git. For, this I want to have a new project(pom.xml) and where I want to put both a and b under modules tag. Like this:
pom.xml
<name>combined_project</name>
<artifactId>combined_project</artifactId>
<modules>
<module>a</module>
<module>b</module>
</modules>
a.xml
<artifactId>parent-1</artifactId>
<name>a</name>
<parent>
<artifactId>combined_project</artifactId>
</parent>
<modules>
<module>lookup-1</module>
<module>lookup-2</module>
</modules>
But, its not working for me. I'm getting following exception in maven:
Child module D:\....\a of D:\....\pom.xml does not exist
Maven not able to find child module.
I've following project structure:
project
|_ lookup-1
|_ lookup-1.xml
|_ lookup-2
|_ lookup-2.xml
|_ a.xml
|_ b.xml
|_ pom.xml
Any hint?
a.xml has 2 sub modules lookup-1 and lookup-2. By default maven is looking for the sub modules in the nested maps. So you need to have the following directory structure:
<parent>
|
+- a/pom.xml
| |
| +- lookup-1/pom.xml
| |
| +- lookup-2/pom.xml
|
+- b/pom.xml
|
+- pom.xml
Alternative is to change the parent into
<name>combined_project</name>
<artifactId>combined_project</artifactId>
<modules>
<module>a</module>
<module>b</module>
<module>lookup-1</module>
<module>lookup-2</module>
</modules>
Maven follows a project structure and each <module> will contain a pom.xml file. As you have explicitly stated the pom file in command line that file will be selected as the pom.xml for that project. However, for every submodule that is listed maven will search for the exact file named "pom.xml" for each submodule.
From the folder structure provided, it can be inferred that a.xml can act as a pom file when explicitly specified in command-line but it cannot act as a module as it does not have a dedicated folder with pom.xml.
A maven project in general has the following structure:
archetype-id(folder)
pom.xml(packaging: pom)(with one module module-artifact-id)
module-artifact-id(folder)
pom.xml
If you are attempting to build only the module that has been updated then the module that is not checked in recently will not be part of the newly created archive. But if you still would want to do it for some "special" reason. The following method might be the one you are looking for:
(I wouldn't recommend it -- as it is messy and goes against conventions)
Have two sub-modules in a single project and also Have two .xml files (pom files to be specified in commandline). In one xml file lets say "a.xml" "module-1" is to be specified as a module and in "b.xml" "module-2" is to be specified as a module.
Using the currently modified module invoke the build on that pom file. Example, if module-1 is modified specify a.xml in the command line as the pom.xml.
Please note that I have not attempted it but if it is possible this is one of the ways I can think of by which we can accomplish what you are looking for.
Reference for passing parameters : Pass a dynamic parameter in Jenkins build
Two possibilities :
Either you need to fix the path of your submodules in the modules section of the parent pom.
While creating a jenkins job you will have to tell jenkins to clone submodules as well. when I started with jenkins, I faced similar problem. The solution was to enable "Recursively update submodules" checkbox under Advanced scm behaviors in Jenkins UI.
Using this method, I could successfully resolve (but NOT retrieve the actual jars) all dependencies of a library when its organization, name and revision are given, all programatically using Apache Ivy.
During the resolution process, it parses given library's POM and finds a parent POM if specified, and Ivy's POM parser always tries to resolve sources and javadoc, which generally doesn't exist for parent POMs.
The problem is that when a non-existing jar's URL is queried to our local artifactory, it takes 2~3 seconds to refresh its cache, adding up tens of minutes to total dependency resolution time when I have many transitive dependencies having parent POMs.
For example, the following is the log message I get when I try to resolve Google Guava 17.0:
:: loading settings :: url = jar:file:.ivy2/cache/org.apache.ivy/ivy/jars/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
:: resolving dependencies :: com.google.guava#guava-envelope;17.0 [not transitive]
confs: [default]
validate = true
refresh = false
resolving dependencies for configuration 'default'
== resolving dependencies for com.google.guava#guava-envelope;17.0 [default]
== resolving dependencies com.google.guava#guava-envelope;17.0->com.google.guava#guava;17.0 [default->master]
tried http://artifactory/repo/com/google/guava/guava/17.0/guava-17.0.pom
resolver: found md file for com.google.guava#guava;17.0
=> http://artifactory/repo/com/google/guava/guava/17.0/guava-17.0.pom (17.0)
downloading http://artifactory/repo/com/google/guava/guava/17.0/guava-17.0.pom ...
resolver: downloading http://artifactory/repo/com/google/guava/guava/17.0/guava-17.0.pom
[SUCCESSFUL ] com.google.guava#guava;17.0!guava.pom(pom.original) (58ms)
tried http://artifactory/repo/com/google/guava/guava-parent/17.0/guava-parent-17.0.pom
resolver: found md file for com.google.guava#guava-parent;17.0
=> http://artifactory/repo/com/google/guava/guava-parent/17.0/guava-parent-17.0.pom (17.0)
downloading http://artifactory/repo/com/google/guava/guava-parent/17.0/guava-parent-17.0.pom ...
resolver: downloading http://artifactory/repo/com/google/guava/guava-parent/17.0/guava-parent-17.0.pom
[SUCCESSFUL ] com.google.guava#guava-parent;17.0!guava-parent.pom(pom.original) (20ms)
resolver: revision in cache: org.sonatype.oss#oss-parent;7
tried http://artifactory/repo/com/google/guava/guava-parent/17.0/guava-parent-17.0.jar
tried http://artifactory/repo/com/google/guava/guava-parent/17.0/guava-parent-17.0.jar
tried http://artifactory/repo/com/google/guava/guava-parent/17.0/guava-parent-17.0-sources.jar
CLIENT ERROR: Could not find resource url=http://artifactory/repo/com/google/guava/guava-parent/17.0/guava-parent-17.0-sources.jar
tried http://artifactory/repo/com/google/guava/guava-parent/17.0/guava-parent-17.0-src.jar
CLIENT ERROR: Could not find resource url=http://artifactory/repo/com/google/guava/guava-parent/17.0/guava-parent-17.0-src.jar
tried http://artifactory/repo/com/google/guava/guava-parent/17.0/guava-parent-17.0-javadoc.jar
CLIENT ERROR: Could not find resource url=http://artifactory/repo/com/google/guava/guava-parent/17.0/guava-parent-17.0-javadoc.jar
tried http://artifactory/repo/com/google/guava/guava/17.0/guava-17.0.jar
tried http://artifactory/repo/com/google/guava/guava/17.0/guava-17.0-sources.jar
tried http://artifactory/repo/com/google/guava/guava/17.0/guava-17.0-javadoc.jar
found com.google.guava#guava;17.0 in resolver
resolved ivy file produced in cache
:: resolution report :: resolve 2593ms :: artifacts dl 0ms
:: modules in use:
com.google.guava#guava;17.0 from resolver in [default]
---------------------------------------------------------------------
| | modules || artifacts |
| conf | number| search|dwnlded|evicted|| number|dwnlded|
---------------------------------------------------------------------
| default | 1 | 1 | 1 | 0 || 0 | 0 |
---------------------------------------------------------------------
report for com.google.guava#guava-envelope;17.0 default produced in .ivy2/cantabile/com.google.guava-guava-envelope-default.xml
resolve done (2593ms resolve - 0ms download)
You can see that Ivy wasted a few seconds while trying nonexistent -sources.jar, -src.jar, -javadoc.jar URLs for parent POMs.
Is there an option to disable this behavior when resolving a parent POM? Ideally I don't want to make HTTP requests to any .jars during resolution. Currently I need a programmatic solution but if anyone knows a command line/XML option it will be a great help.
PS: I think this is also the case when using sbt to resolve library dependencies; it takes very long while resolving oss-parent, commons-parent etc.
You need to specify a configuration mapping that excludes both optional dependencies and implicit dependencies like source and javadoc files.
In an ivy file you'd declare the dependency as follows:
<dependency org="myorg" name="mymodule" rev="1.0" conf="default"/>
Another option is to declare this dependency mapping as the default for your project.
<dependencies defaultconfmapping="default">
<dependency ..
<dependency ..
See the following SO questions on how to exclude sources and how ivy translates Maven repositories:
Ignore sources jar in Ivy retrieve
How are maven scopes mapped to ivy configurations by ivy
In conclusion Maven modules by default only have a single arefact. More can be stored (like sources and Javadocs) but there is no module metadata listing them. This is why Ivy performs a HTTP request to see if the artefacts exist or not. Changing the configuration mapping settings should help guide ivy to do the right thing :-)
PS
I think this can be done by called the "addDependencyConfiguration" method to the DefaultDependencyDescriptor object.
I'm currently working on changing building process of legacy project. Right now it is built by a custom-made solution and our aim is to adjust it to a standard one - maven.
This is a standalone application and current output of a build is a directory with following structure:
OUR_APPLICATION
|
|_bin
| |_start.sh
| |_stop.sh
|
|_etc
| |_app.properties
|
|_jar
| |_app_classes1.jar
| |_app_classes2.jar
|
|_lib
|_third_party_library.jar
I am wondering what's the best way to achieve similar output with maven and still follow best practises (or at least break them as little as possible).
I'm leaning towards creation of multi-module project (separate modules for Java code, configuration files and shell scripts) and then using maven-assembly-plugin for combining it all together, but I'm not entirely sure how (if at all) it can be properly done.
Still I'm not sure whether its the best fit for me and I will be very grateful for any feedback.
You are on the right way (imo): Maven is a good tool for producing deployable artifacts. And the maven-assembly-plugin fits the needs that you described. It could produce a ZIP file containing the application structure you described.
The default artifact type that Maven produces is simply a JAR. This is ok for libraries. The application structure that you described seems to have three of them: app_classe1.jar, app_classes2.jar, and third_party_library.jar (I know, there could be more of them).
The Maven setup that I would suggest (and keep in mind: other ways exist): Create a multi-module project, which has modules for each application JAR and one module for assembling them. The parent project then simply builds them all. Like this:
ParentProject
|
|-- pom.xml (the parent one, that describes all modules)
|
|-- Module1 (producing app_classes1.jar)
| |
| |-- pom.xml
| |-- src/...
|
|-- Module2 (producing app_classes2.jar)
| |
| |-- pom.xml
| |-- src/...
|
|-- AssemblyModule (the one that produces a ZIP, for example)
|
|-- pom.xml (with type POM because it does not produce a JAR)
The assembly module should not have the default artifact type (JAR), but should be set to type POM. The pom.xml of that assembly module then configures the maven-assembly-plugin to create a ZIP file. The content of this ZIP file is highly configurable. Additionally, this plugin attaches the result artifact (the ZIP) to the build, so that it will be uploaded to a repository, if that is also configured.
I have a mojo annotated with #requiresDependencyResolution test.
It works for multi-module projects with a single layer of nesting, but a user has reported an issue with a structure such as below.
-- my_project
|
-- pom.xml
-- submodule1
|
-- pom.xml
-- submodule2
|
-- pom.xml
-- submodule21
|
-- pom.xml
-- submodule22
|
-- pom.xml
If submodule21 depends on submodule1 maven reports
Failed to execute goal on project submodule21: Could not resolve
dependencies for project org.my:submodule21:jar:1.0-SNAPSHOT: Could
not find artifact org.my:submodule1:jar:1.0-SNAPSHOT
Removing the requiresDependencyResolution=test annotation prevents this problem but then I do not have access to the information I require for the mojo to run.
From brief scan of the surefire code on github, it looks to also use requiresDependencyResolution=test but is able to run against this project without issue.
https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
The only obvious difference from my own code is that it uses java annotations rather than old style javadoc ones.
How is the surefire mojo achieving this?
My code is
http://code.google.com/p/pitestrunner/source/browse/pitest-maven/src/main/java/org/pitest/maven/PitMojo.java
Example project displaying issue
http://code.google.com/p/pitestrunner/issues/detail?id=71
For the benefit of anyone else having this issue - I eventually solved this problem. There was no issue with the plugin.
The difference between surefire and my own plugin was simply the way in which they were being run. Surefire was bound to the test phase, my own plugin was being run by calling a goal directly. When I bind my plugin to the verify phase, everything resolves without issue.