I have a build environment with Maven3.0.4, Nexus 2.2 and Jenkins 1.508. To support an active and dynamic development environment, all artifacts in my solution use snapshot version and maven tries to get latest snapshot on every build.
The build is not that smooth as expected. Main problem is sometimes build fails due to unresolvable dependencies, and the solution is just re-run the job.
I am suspicious that it is caused by bottleneck in Nexus server in peak load, which causes Maven unable to retrieving pom files during build. But I have no idea about how to diagnose and fix the issue. Anyone has a good idea?
This question has been answered. Please refer to Does Maven build "thread safe" for snapshot projects?.
B.R.
Related
We are using Maven as build manager and Nexus as our artifact repository.
From time to time we are having this dependency problem and Maven is not able to find the artifact in Nexus by a slight difference in the snapshot version number. In this case, the difference seems to be 1 second.
Currently, a build is failing, maven is looking for
SOME_ARTIFACT-0.0.1-20181217.115318-337.jar
but on the Nexus we have
SOME_ARTIFACT-0.0.1-20181217.115317-337.jar
This is not happening all the time, but from time to time I see this problem, and in order to solve this I need to redeploy SOME_ARTIFACT before building the application that depends on SOME_ARTIFACT.
Do you have any idea why this is happening? I know I can use release versions and totally avoid this snapshot issue but this SOME_ARTIFACT is under constant update and development, so I don't wanna keep releasing, plus, what I want is to figure out the reason behind this problem not to basically avoid it.
Maven version: 3.5.0
NEXUS version: OSS 3.12.1-01
Any help is appreciated.
Thanks!
Thanks for providing the Maven version. Likely you are being impacted by https://issues.apache.org/jira/browse/MNG-6240. Update Maven (or downgrade to 3.3.9) and that should help.
I've spent years trying to deploy libraries that use native code to Maven Central. I've run into the following problems:
There weren't any good plugins for building native code using Maven. native-maven-plugin was a very rigid build system that, among other things, made it difficult to debug the resulting binaries. You'd have to manually synchronize the native-maven-plugin build system with the native IDE you use for debugging.
Maven did not replace variables in deployed pom.xml files: MNG-2971, MNG-4223. This meant that libraries had to declare platform-specific dependencies once per Maven profile (as opposed to declaring the dependency once and setting a different classifier per profile); otherwise, anyone who depended on your library had to re-define those same properties in their project file in order to resolve transitive dependencies. See Maven: Using inherited property in dependency classifier causes build failure.
Jenkins had abysmal support for running similar logic across different platforms (e.g. "shell" vs "batch" tasks, and coordinating a build across multiple machines)
Running Windows, Linux and Mac in virtual machines was way too slow and fragile. Even if you got it working, attempting to configure the VMs as Jenkins slaves was a lesson in frustration (you'd get frequent intermittent build errors).
Maven Central requires a main jar for artifacts that are platform-specific: OSSRH-975
Sonatype OSS Repository Hosting and maven-release-plugin assumed that it would be possible to release a project in an atomic manner from a single machine but I need to build the OS-specific bits on separate machines.
I'm going to use this Stackoverflow question to document how I've managed to overcome these limitations.
Here is how I overcame the aforementioned problems:
I used CMake for building native code. The beauty of this system is that it generates project files for your favorite (native) IDE. You use the same project files to compile and debug the code. You no longer need to synchronize the two systems manually.
Maven didn't support CMake, so I built my own plugin: https://github.com/cmake-maven-project/cmake-maven-project
I manually hard-coded platform-specific dependencies into each Maven profile, instead of defining the dependency once with a different classifier per profile. This was more work, but it doesn't look like they will be fixing this bug in Maven anytime soon.
I plan to investigate http://www.mojohaus.org/flatten-maven-plugin/ and https://github.com/mjiderhamn/promote-maven-plugin as alternatives in the near future.
Jenkins pipeline does a good job of orchestrating a build across multiple machines.
Running Jenkins slaves on virtual machines is still very error-prone but I've managed to workaround most of the problems. I've uploaded my VMWare configuration steps and Jenkins job configuration to help others get started.
I now create an empty JAR file for platform-specific artifacts in order to suppress the Sonatype error. This was actually recommended by Sonatype's support staff.
It turns out that maven-release-plugin delegates to other plugins under the hood. Instead of invoking it, I do the following:
Use mvn versions:set to change the version number from SNAPSHOT to a release and back.
Tag and commit the release myself.
Use nexus-staging:rc-open, nexus-staging:deploy -DstagingProfileId=${stagingProfileId} -DstagingRepositoryId=${stagingRepositoryId}, and nexus-staging:rc-close to upload artifacts from different platforms into the same repository. This is called a Staging Workflow (referenced below).
Upon review, release the repository to Maven Central.
Important: do not enable <autoReleaseAfterClose> in the nexus-staging plugin because it closes the staging repository after each deploy instead of waiting for all deploys to complete.
Per https://issues.sonatype.org/browse/NEXUS-18753 it isn't possible to release SNAPSHOT artifacts atomically (there is no workaround). When releasing SNAPSHOTs, you need to skip rc-open, rc-close and invoke nexus-staging:deploy without -DstagingProfileId=${stagingProfileId} -DstagingRepositoryId=${stagingRepositoryId}. Each artifact will be uploaded into a separate repository.
See my Requirements API for a real-life example that works.
Other quirks to watch out for:
skipNexusStagingDeployMojo must be false in last reactor module (otherwise no artifacts will be deployed): https://issues.sonatype.org/browse/NEXUS-12365. The best workaround is to use Maven profiles to omit whatever modules you want when deploying (don't use skipNexusStagingDeployMojo at all)
skipLocalStaging prevents deploying multiple artifacts into the same repository: https://issues.sonatype.org/browse/NEXUS-12351
I get the below error while executing the default lifecycle 'clean install' from my maven project.
java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
My code uses the flexmojos-maven-plugin. As per the jira thread https://issues.apache.org/jira/browse/MNG-5958 this issue has been resolved, but nowhere could I find how.
As per the solution I would have to update Lifecycle.java. Updating Lifecycle.java would mean updating maven-core.jar.
Will I have to go the extent of updating a standard jar which could impact many other files which are using this jar.
I am using maven 3.3.9 and java 8.
The problem is that the Maven guys changed quite a lot internally again with Maven 3.3.9 so currently you will have to use an older Maven version. I also doubt that I will be able to spare the time to address this in the future as Flexmojos has become more and more a beast to maintain. Therefore I am currently working on a completely new maven plugin which I am developing as part of the Apache flex project. For now I would suggest to use Maven 3.3.3 ... should work nicely with that.
I want to have Sonar analysis being performed on twice on the same Maven project at the same time, but different versions.
i.e. GAV details
<groupId>com.test.exm</groupId>
<artifactId>exm001</artifactId>
<version>1.5.0-SNAPSHOT</version>
AND
<groupId>com.test.exm</groupId>
<artifactId>exm001</artifactId>
<version>1.4.0-SNAPSHOT</version>
This gives the error though...
Caused by: org.sonar.api.utils.SonarException: The project is already
being analysed. at
org.sonar.batch.scan.ProjectLock.start(ProjectLock.java:55)
Please don't ask why I have snapshot 1.4.0 and 1.5.0 at the same time.
Its a legacy build thing going on in the background.
I would have thought the semaphore lock used would include the version number, not just the artifact and groupID.
I've found this defect...
https://jira.codehaus.org/browse/SONAR-2761
I could turn off sonar for the legacy stuff, but I'd sooner see if there is a fix I could make to allow Sonar to do the analysis.
In order to achieve this, you can use the sonar.branch property on the legacy version of your project.
I am trying to write my pom.xml for a multimodal flex application. I have been using this resource as an example:
http://www.sonatype.com/books/mvnref-book/reference/flex-dev-sect-creating-with-archetype.html
I am using M2E v1.01 but I am faced with a number of 'Plugin execution not covered by lifecycle configuration" errors. As far as I can see - there are no m2E connectors available to resolve this and I have tried all the Maven advice I can find - to include:
Clean
Update dependencies
Update project configuration
The problem only occurs if the project is declared as swc or swf package. My next move to ask Eclipse to 'permanently mark goal as ignored' - which seems a little brash.
Any advice would be appreciated.
Thanks in advance.
With STS 2.8.0, we have upgraded m2eclipse to be version 1.0. However, this can cause a bit of trouble with existing projects. I wrote a blog on this a couple of months ago.
http://blog.springsource.org/2011/10/18/upgrading-maven-integration-for-springsource-tool-suite-2-8-0/
Essentially, the new architecture for m2eclipse requires that each maven plugin you use must be mapped to one Eclipse plugin to handle the plugin's execution inside of Eclipse. This obviously causes problems since not every maven plugin author has the knowledge or time to create also create and maintain an Eclipse plugin.
By marking the plugin as ignored, you are saying that the plugin should never be executed inside of Eclipse (implying that whenever you need it to be executed, you will do so from the command line). Once marked as ignored, you can then change it to execute, which means that it should always be executed whenever the associated lifecycle is performed in Eclipse. This may cause performance problems, and so only do it if you know the risks.
If all this is too much for you, then STS provides a downgrade option to revert to an older version of m2eclipse. Go to the Dashboard extensions page. Unfortunately, you will have to manually revert all changes to your .project and .classpath files (we provide an auto-upgrade mechanism, but not a downgrade mechanism...presumably everything is in version control).
Any questions or problems should be sent to the STS forums:
http://forum.springsource.org/forumdisplay.php?32-SpringSource-Tool-Suite
You can check this alpha connector "Flex Maven Integration for Flash Builder" on the eclipse marketplace: http://marketplace.eclipse.org/node/648556.