I’m a big fan of Eclipse and its ‘compile as you write’ compiler. On the other hand I’m also a big fan of Maven and often run it from the command line because when you want to do a full build (including some non-standard plugins) the process is more repeatable from the command-line than clicking from any button in an IDE. You can also copy-paste the command to educate your colleagues about Maven’s command line tricks (–projects –also-make etc…).
Problem is: when you run Maven from the command-line while Eclipse is also pointing to the same sources, it triggers an Eclipse build at the same time and my experience says it’s bad.
The solution is to configure your Maven modules to be able to build to an alternative directory. For exemple ./target2/ instead of ./target/ . That way, your command-line builds will not trigger Eclipse re-builds anymore.
In the end your pom.xml (or parent pom.xml) should look like:
<!– This variable’s only goal is to make Maven command-line and Eclipse build in 2 different directories so that Eclipse will not refresh itself and re-compile. Use like this: mvn test -Dtest=myTestClass -pl dbclient -DbuildDirectory=target2 –>
And on the command-line just invoke Maven with the -DbuildDirectory=target2 variable. This way, Eclipse will build in target as usual but you will build in target2, not disturbing Eclipse.
Just make sure to look for the resulting artifacts in the “target2” folder, not in the usual “target” !
Recently I had to download dependencies from a Maven plugin (Mojo). But I encountered difficulties and want to tell you my conclusion. Here is what I tried:
Shrinkwrap resolver is a JBoss OSS library. For unknown reasons it was sometimes not downloading the latest artifacts from the repository but relied on the outdated ones in the local repo instead. I surely misconfigured something but could not find what…
Apache Archiva REST API
In theory, a simple call to the webservice should have returned my artifact. But (again) for unknown reasons, it would sometimes fail and return a zero byte file.
For exemple, this call fails:
but this one succeeds:
And I am sure the 2.1.0 version exists and is the latest…
mvn org.apache.maven.plugins:maven-dependency-plugin:3.1.1:get -Dartifact=com.company-sdk-boxes:default-boxes-bcd-doc:2.1.0:zip
=> OK but in previous version (2.X) we used to have parameter “dest” which is now deprecated. So we cannot point the download to a specific directory: it resolves to the local repo only.
mvn dependency:copy -Dartifact=com.company.sdk-boxes:default-boxes-bcd-doc:2.1.0:zip -DoutputDirectory=. -DuseBaseVersion=true
This is the way I should have tried first ! I don’t know why but I thought the dependency:copy would need a pom to download dependencies. In fact this is not true, you can use it on the command line.
And as you can use it on the command line, you can also use it from inside another Mojo (Maven plugin) by using the Mojo executor. Only caveat is that you do not get a handle on the file just downloaded but you know it’s filename in advance. It is of the form -.jar if you make sure to use the -DuseBaseVersion=true parameter to avoid the timestamp replacing the “-SNAPSHOT” suffix.
I’ve just published on Github a tutorial about separating the webservice (with WSDL) Maven project from the project containing the XSD. The goal is to enhance all projects overall testability.
The tutorial is available in the project wiki on Github: https://github.com/fmarot/xml-mapping-tutorial/wiki
The Maven projects are available on Github too: https://github.com/fmarot/xml-mapping-tutorial