I have a fairly complicated build workflow for one of my Jenkins builds. The project contains two modules. Module M1 builds a service and module M2 builds the service client. M1 is dependent on M2 (don't ask me why). M2 needs stubs created from the ejb's in M1. So we are at an circular dependency which I tried to circumvent with following build order.
mvn clean install (for the whole project)
mvn package -PCI (for M2 with profile to gather all dependencies incl. M1 jar)
copy build artifacts and dependencies to different machine for stub creation
create stubs
overwrite M2 build artifact with version that contains stubs
mvn install:install (for M2)
when running the final install, it bombs with:
[INFO] [install:install {execution: default-cli}]
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The packaging for this project did not assign a file to the build artifact
[INFO] ------------------------------------------------------------------------
So I came up with the idea, that since I already use Jenkins and I am deploying anyway to our snapshot directory, I have nothing to worry and I can leave out the local deployment since it will pull the newer version from the snapshot repo anyway. The result was, that Jenkins archives the artifact for the job after it ran the install. Since I didn't run the final install, the version without stubs was deployed (from step 2 I believe).
Then, I configured the Jenkins job to explicitly archive my service client jar with the post build option in addition to the automatic archiving feature of the maven integration. The result was, that I had the service client jars archived for the Jenkins job. One was one the Project level (the desired version with stubs) and one on M2 (w/o stubs). Of course the version without stubs was deployed.
Any idea how I can get out of this dilemma, without changing the project structure. I can add stuff to the pom files as long as the developer desires are still fulfilled. The Jenkins job is my domain.
It sounds like you need to reorganize. Is it possible to factor out the server->client dependencies in the client into a separate jar, and change the dependency on the client to a dependency on this new jar?
Related
We have moved from Archiva to Nexus and are still using Maven 2.
We execute eclipse:eclipse locally so that Eclipse .project and .classpath files are generated, based on the dependencies in the POMs, and then we import the projects into Eclipse to do our development. We don't use M2Eclipse for a variety of reasons.
Since using Nexus, we have the problem that projects don't always reference each other in the workspace, rather they reference the respective JAR.
I have noticed that Nexus is appending a timestamp to the JAR name, and the MVN output states, e.g.:
[INFO] Artifact myapp-bom:jar:7.3.0.2.1-SNAPSHOT already available as a workspace project, but with different version. Expected: 7.3.0.2.1-20120508.115037-68, found: 7.3.0.2.1-SNAPSHOT
I get the feeling that is the reason why eclipse:eclipse generates .classpath files which contains JAR references (based on local maven repo) rather than project references. When we used Archiva (and there were no timestamps) then we used to get project references, and that is exactly what we want.
Has anyone else had this problem and how is it solved? I read that maven 3 forces timestamps to always be generated. Again, how do you get eclipse:eclipse to generate sensible .classpath files?
Cheers,
Ant
PS - some of our projects come from different SVN repositories. It seems that if the Eclipse Projects are refernced in the parent pom, eclipse:eclipse creates a project reference, but if the Eclipse Projects are from a different parent pom, but still in the workspace, then it can only generate JAR references.
The problem was resolved by using maven-eclipse-plugin (eclipse:eclipse) version 2.9, rather than 2.8! Doh...
I have an artifact abc which has some tests. I have different versions of abc within my repository. I now want to be able to run the latest tests against the 'old build' of the project.
I tried to add the artifact itself to the test dependencies but this (of course) results in a cyclic reference error of the maven reactor when building the tests via:
mvn compiler:testCompile
mvn surefire:test
Is there any smart way to run tests against a previous old build/artifact?
Must i create a new pom.xml in which i define the solo test execution?
Or should i add a postfix to my current artifact when executing the tests? (This would avoid a cyclic reference error)
Separate the tests out into a separate module/project that depends on the classes it tests. Then create separate profiles where you change the dependency to be on older releases.
The problem I foresee with what you're trying to do is that the package phase comes after the test phase of the maven lifecycle. Which to me implies that maven runs unit tests against the compiled classes and not the physical jar file (generated in the package phase). You'll therefore have to replace the contents of the projects /target/classes folder with the classes in the "older" jar.
When I run release:prepare on my Maven project, it fails when attempting the scm-tag phase.
My Maven project uses Bazaar for its SCM. My plugin versions are maven-release-plugin 2.0 and maven-scm-plugin 1.4
[INFO] EXECUTING: cmd.exe /X /C "bzr tag myproj-pathway-0.0.2"
[ERROR] Not a branch: "D:/proj/".
The problem of course, is that the actual working directory/branch is D:/proj/branch; the parent is just a normal directory.
I assume the problem is with tagging since the modified POM is successfully checked in. How do I configure things so that tagging actually works correctly?
I've been seeing odd behaviour from my Maven 2.2.1 installation whilst doing war installs.
Occasionally, I will update a class but the updated version is not packaged up in the artifact produced by mvn install.
So far, I have determined that an updated .class file is produced in the target directory, and that the class of the same name in the produced .war is not the same (different date modified, different size)
Running Maven from the command line with the -X flag produced debug output for the class like:
[DEBUG] *
WEB-INF/classes/mypackage/MyClass.class
is up to date.
I think I've also had the same problem before where the file that was cached(?) was an incomplete compile from Eclipse, causing 'Unresolved Compilation Problem' errors from the Maven build, but a working artifact from an Eclipse export.
How does Maven determine whether a
file 'is up to date' during the
install process?
Where are the files Maven is comparing to?
Can I force Maven to build a package from scratch?
Any other ideas would be appreciated!
So far, I have determined that an
updated .class file is produced in the
target directory, and that the class
of the same name in the produced .war
is not the same (different date
modified, different size)
Just to be sure, the classes should be built under target\classes, not target.
Can I force Maven to build a package from scratch?
You can force a full build by running
mvn clean install
This performs a clean (essentially removes the target directory) before running the install phase.
Also - check for copies of your classes outside of the Maven build directory. In this case as it is a webapp, check src/main/webapp/WEB-INF/classes
I'm sitting behind a firewall and therefore maven can't connect to central repositories (error message is given below).
However, I can connect to the internet via HTTP.
How can I install a maven plugin (e. g. archetype) in offline mode (i. e. download some file in a browser and then install the plugin by executing some commands) ?
Thanks in advance
Dmitri
P. S.: Here is the error message:
E:\>mvn archetype:generate -DarchetypeGroupId=com.vaadin
-DarchetypeArtifactId=vaadin-archetype-clean -DarchetypeVersion=LATEST -DgroupI
d=at.swdev -DartifactId=pcc -Dversion=1.0 -Dpackaging=war
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] org.apache.maven.plugins: checking for updates from central
[WARNING] repository metadata for: 'org.apache.maven.plugins' could not be retri
eved from repository: central due to an error: Error transferring file: Connecti
on refused: connect
[INFO] Repository 'central' will be blacklisted
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The plugin 'org.apache.maven.plugins:maven-archetype-plugin' does not exi
st or no valid version could be found
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Thu Jul 22 15:17:00 CEST 2010
[INFO] Final Memory: 1M/15M
[INFO] ------------------------------------------------------------------------
I'm sitting behind a firewall and therefore maven can't connect to central repositories (error message is given below). However, I can connect to the Internet via HTTP.
Maybe you should clarify a bit because Maven uses HTTP as well. If you connect through some kind of proxy, you CAN configure Maven to do so by declaring the proxy in your ~/.m2/settings.xml. See Configuring a proxy.
How can I install a maven plugin (e. g. archetype) in offline mode (i. e. download some file in a browser and then install the plugin by executing some commands)?
You can install any jar in your local repository using the install:install-file goal (see the Usage page). But this is only a small part of the story, you'll need to install dependencies of the plugin too. And then dependencies of dependencies. This will very quickly become a real nightmare and unmanageable task (that Maven precisely tries to solve). So either:
Configure Maven to access Internet if this is possible ~or~
Setup a corporate repository (like Nexus) on a dedicated machine, see with your admins how to allow it to access Internet) and configure your Maven client to use it ~or~
Copy a "pre-populated" local repository from an existing machine to your machine and run maven offline (with all the limitations this implies) ~or~
Don't use Maven
If you can not use proxy, then you should download all dependencies of plugin as Pascal said. Easiest way to do this.
Download all dependencies using a machine with normal/proxied http connection. Maven dependency plug-in has a goal which can help you. mvn dependency:go-offline
For example I use it to get maven dependencies of app-fuse tutorial.
svn co (http here ) appfuse-demos.googlecode.com/svn/trunk/helloworld
(check out source code)
mvn install (install and see that it works in normal machine)
mvn dependency:go-offline (it downloads everything. Help :tells Maven to resolve everything this project is dependent on (dependencies, plug-ins, reports) in preparation for going offline.)
after that in your local m2 repository (~/m2/repository) , you will find everything you need. Zip that folder. Get it inside your intranet. extract it to your local repository or
corporate repository (nexus, artifactory ..)
you should be able to use that plug-in now.
http://maven.apache.org/plugins/maven-dependency-plugin/
I guess your security firewall doesn't allow you to download from maven central repo.So, you can simply specify mirrors in the settings.xml file in the maven_home. if you have any repository for your company say like nexus, give the server url of that nexus in the mirrors section in your settings.xml.
Note that in case if you don't have any repo for your company you have to download all the dependencies offline and install using mvn install in the local repository in your build server.