I have a project which has multiple sub projects (modules). More specifically this is an Eclipse project and has multiple features.
The issue is a feature might not need any changes for a release. For that reason I don't bump up the version number, but another feature in the same project might have changes. Since it is considered bad practise to re-deploy same versions I disabled that option in Nexus.
Now the actual problem occurs when I deploy. So deploying anything that has a new version number works fine, however when deploying old one I was sort of expecting maven to give warning that it already exits in repository and then skip it but turns out Nexus responds:
Return code is: 400, ReasonPhrase:Bad Request.
which then causes maven to fail the entire deployment process. The full error is:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on project xyz: Failed to deploy artifacts: Could not transfer artifact xyz:target:2.5.8.0 from/to nexus (http://host/nexus/content/repositories/releases): Failed to transfer file: http://host/nexus/content/repositories/releases/x/targets/xyz/2.5.8.0/xyz-2.5.8.0.target. Return code is: 400, ReasonPhrase:Bad Request. -> [Help 1]
build 11-Sep-2015 07:09:57 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on project abc: Failed to deploy artifacts: Could not transfer artifact foo:abc:jar:2.5.8.0 from/to nexus (http://host/nexus/content/repositories/releases): Failed to transfer file: http://host/nexus/content/repositories/releases/bar/abc/2.5.8.0/abc.ocl-2.5.8.0.jar. Return code is: 400, ReasonPhrase:Bad Request. -> [Help 1]
The question is, how can I handle this failure/exception? All I want is if it is already deployed then skip/ignore deployment of that artifact.
See Maven: The Complete Reference, 6.1. Maven Command Line Options, 6.1.8. Dealing with Failure or mvn --help:
-fae,--fail-at-end Only fail the build afterwards;
allow all non-impacted builds to
continue
It is generally accepted best practice in Maven to use the same version across multi-module projects. I would just switch to that scheme and deploy each module even if it didnt really change internally.
If you dont want to do that, it would be better to break your project up into multiple projects that are built and released separately.
The only hacky workaround you can otherwise do is to set the skip property for the Maven deploy plugin for projects that have already been deployed. You will however have to manually manage that and therefore produce additional overhead and churn on your codebase. See more at https://maven.apache.org/plugins/maven-deploy-plugin/faq.html
Related
I am trying to build Apache CXF locally. It does not work behind a maven proxy (e.g. JFrog Artifactory), because CXF's transitives dependencies contain a dependency with an invalid pom.xml file:
[ERROR] Failed to execute goal on project cxf-rt-transports-jms: Could not resolve dependencies for project org.apache.cxf:cxf-rt-transports-jms:bundle:3.4.0-SNAPSHOT: Failed to collect dependencies at org.apache.activemq:activemq-pool:jar:5.15.9 -> org.apache.activemq:activemq-jms-pool:jar:5.15.9 -> org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec:jar:1.0.1: Failed to read artifact descriptor for org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec:jar:1.0.1: Could not transfer artifact org.apache.geronimo.specs:specs:pom:1.1 from/to nexus-central (https://myrepo.local/maven-central/): Failed to transfer file https://myrepo.local/maven-central/org/apache/geronimo/specs/specs/1.1/specs-1.1.pom with status code 409 -> [Help 1]
Artifactory will deliver a 409 if it cannot parse the XML file. In this case, the artifact is apache.geronimo.specs:specs:pom:1.1. If you take a look at the XML file, you'll find it is invalid indeed: https://repo1.maven.org/maven2/org/apache/geronimo/specs/specs/1.1/specs-1.1.pom
After line 89 (closing </developers>), there is an extra `.
I opened an issue at apache to fix their build: https://issues.apache.org/jira/browse/CXF-8101
In the mean time, I'd like to work with CXF to create a patch an contribute.
Things I tried:
Install the dependency manually => failed because mvn still looks for updates
No proxy => not an option for me :(
Add some excludes locally on the parent/pom.xml => didn't help, I will never be able to catch them all (transitive dependencies…).
Forcing the offending artifacts' version to 1.2. Did not help either, because some projects wil still rely on a specific version.
That said, what are my options?
Thanks in advance,
Ben
You can try:
Download org/apache/geronimo/specs/specs/1.1/specs-1.1.pom into your local .m2 path and fix the error.[You need to be sure all dependencies are available in your local repository]
Try to build with maven command: -o (offline)
If -o doesn't help, try with -nsu,--no-snapshot-updates (Suppress SNAPSHOT updates)
Hope it helps you.
I have cloned the git repository from https://github.com/viatra/org.eclipse.viatra.examples
and imported the project incquery-demo-generic (located in /query/headless-maven) as a Maven Project in Eclipse. Unfortunately I get the following error when I open the project's pom.xml:
Furthermore everytime when I click on "Run As" -> "Maven install" or "Maven build..." I get the following error message in the console:
Failed to execute goal on project incquery-demo-generic: Could not resolve dependencies for project hu.bme.mit.incquery:incquery-demo-generic:jar:0.0.1-SNAPSHOT: Failed to collect dependencies at org.eclipse.incquery:runtime:jar:0.8.0-SNAPSHOT: Failed to read artifact descriptor for org.eclipse.incquery:runtime:jar:0.8.0-SNAPSHOT: Failure to find org.eclipse.incquery:org.eclipse.incquery.parent:pom:0.8.0-SNAPSHOT in https://repo.eclipse.org/content/repositories/emf-incquery-snapshots/ was cached in the local repository, resolution will not be reattempted until the update interval of incquery-snapshot has elapsed or updates are forced -> [Help 1]
Blockquote
In the Maven Dependencies Folder I can find some, but not all necessary jar files.
I have tried "Project clean", "Maven update", "Maven build... (Goal: clean package)" and to delete the .m2 repository and to re-build the maven project, but nothing helps.
I also tried to download some dependencies as .jar files and add them to the build-path, but they contain nothing but pom.xml and properties-files themself, thus I keep getting "cannot be resolved to a type" errors in relevant parts of the Java src-code.
Can somebody successfully run this project in her/his eclipse?
I am not an expert on Maven Projects so please tell me what to do in "layman words".
Thanks & kind regards,
MCRaven
The projects in the VIATRA examples repository (I notice it as one of the committers of the VIATRA project) are somewhat unusual: they are Eclipse plug-in projects that have Maven build informations added via Maven Tycho.
One more thing here: the 0.8.0 version of EMF-IncQuery bundles was released in 2014, thus it makes sense that the corresponding snapshot versions are removed. This means to me that this example was not updated for a long time. This is somewhat by design - some examples are not updated for each released version, but they are not are still available for references. If you are explicitly interested in this example, please contact us on VIATRA project forums or Bugzilla and we will provide example-specific support there.
Inside Eclipse we usually not rely on Maven (and our experience is that Tycho-based projects often does not work with M2E correctly). You could try to update Maven dependencies for the org.eclipse.incquery projects to 0.8.0, but I am still unsure whether it will work or not.
On the other hand, I'd rather suggest to install the old EMF-IncQuery version into your Eclipse instance and then simply rely on the Java Development Tools and the Plugin Development Environment to compile the project, and simply ignore any errors in the Maven descriptors for now.
In our company, we've created a Maven plugin using maven-plugin-plugin v3.5, that normally contains 20kb.
The issue begun two days ago, because repo.jenkins-ci.org proxy is not working properly. So, our clients builds were affected because it wasn't possible to download the dependencies of our plugins, failing builds due:
Failed to collect dependencies at our-project:jar:1.6.2 -> our-project:jar:1.6.2 -> com.devfactory.utqg:utqg-github:jar:1.6.2 -> org.kohsuke:github-api:jar:1.77 -> com.infradna.tool:bridge-method-annotation:jar:1.14 -> org.jenkins-ci:annotation-indexer:jar:1.4: Failed to read artifact descriptor for org.jenkins-ci:annotation-indexer:jar:1.4: Could not transfer artifact org.jenkins-ci:jenkins:pom:1.26 from/to repo.jenkins-ci.org (http://repo.jenkins-ci.org/public/): Failed to transfer file: http://repo.jenkins-ci.org/public/org/jenkins-ci/jenkins/1.26/jenkins-1.26.pom. Return code is: 502 , ReasonPhrase:Bad Gateway. -> [Help 1]
So, our approach to that problem was focused in creating a Fat Maven Plugin (not a Fat Jar!). But, using Maven Shade plugin is not suitable for copying the artifacts, because plugin execution fails due the jar signature.
Does anybody have generated a fat Maven plugin? If yes, how?
The issue begun two days ago, because repo.jenkins-ci.org proxy is not
working properly. So, our clients builds were affected because it wasn't possible to download the dependencies of our plugins,
I recommend to run your own Maven Repository Manager to avoid these kind of issues: https://maven.apache.org/repository-management.html
Configure the single group in your settings.xml (mirror): http://books.sonatype.com/nexus-book/2.8/reference/maven-sect-single-group.html
Don't manage repositories in your POMs, but only as proxies in your Maven Repository Manager.
We have the next project structure:
parentPom.xml
java projects
streambase projects
streambaseParentPom.xml
project1
project2 (has dependency of project1)
So we have a parentPom with inherits to streambaseParentPom and last one inherit to all streambase projects.
So, we make attemp to have in parentPom a properti called cerebro.version which define the version for parent.
We're getting issues when we have project1 as dependency of other projects, we're getting next error message:
[ERROR] Failed to execute goal on project eFX-SB7-Pricing: Could not resolve dependencies for project com.santander.fx:eFX-SB7-Pricing:jar:3.14.10.0.4-SNAPSHOT:
Failed to collect dependencies at com.santander.fx:eFX-SB7-Common:jar:3.14.10.0.4-SNAPSHOT:
Failed to read artifact descriptor for com.santander.fx:eFX-SB7-Common:jar:3.14.10.0.4-SNAPSHOT:
Could not transfer artifact com.santander.fx:eFX-SB7-Parent:pom:${cerebro.version} from/to eFX-External-Repository (http://lnx-efxbuild2.ants.ad.anplc.co.uk:8081/artifactory/ext-release-local):
Illegal character in path at index 109: http://lnx-efxbuild2.ants.ad.anplc.co.uk:8081/artifactory/ext-release-local/com/santander/fx/eFX-SB7-Parent/${cerebro.version}/eFX-SB7-Parent-${cerebro.version}.pom -> [Help 1]
Thanks in advance.
I am afraid it doesn't work like that. It is a bad idea to parameterize the <version> value since even if you managed to deploy it to your remote repo, any project using that artifact later on wouldn't have a clue what ${cerebro.version} should resolve to.
Remember, Maven works hard to keep your builds reproducible. If the build is dependent on some variable that was known at deploy time, but unknown for dependents, your build will no longer be reproducible.
I'm attempting to start a fresh project that hopes to use GWT 1.7.1, the Google Plugin for Eclipse, and Maven 2. I inferred that the best way to do this would be to setup the project using the Mojo gwt-maven-plugin's archetype from this question.
All was going well until I attempted a build. The archetype adds a generateAsync goal, and Maven is reporting that it doesn't know what that goal's default phase should be.
11/30/09 9:09:53 AM EST: Build errors for your-artifact-name-here; org.apache.maven.lifecycle.LifecycleExecutionException: Failed to construct build plan for: gwt-maven-archetype-project
Id: com.crowehorwath:licensing-forms-gwt:war:0.0.1-SNAPSHOT
task-segment: [process-test-resources]. Reason: Failed to load plugin descriptor for: org.codehaus.mojo:gwt-maven-plugin:1.1-SNAPSHOT:generateAsync. Cannot discover it's default phase, specified in its plugin descriptor.
Any ideas? Hopefully I'm missing something simple.
Try version 1.1 of the gwt-maven-plugin instead of 1.1-SNAPSHOT.
Try running from the command line using Maven if you have not done so already.
The following jira might help as well: http://jira.codehaus.org/browse/MGWT-85?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel.