I am trying to collect the information of all third party modules we have used inside our app, which include name, version, latest version, license and provider. I can collect all of those info using mvn plug-in for the maven projects, but just cannot find a plug-in to list the providers (homepage or vendor info inside manifest). Is there any plug-in available?
Also we had some Gradle projects, what option is best to generate report without modifying the existing build.gradle file(s)?
I'm afraid there is no direct analog to the tool you want. You can get some information via dependencies or dependenciesInsight tasks, but it won't provide, for example, licensing information.
The best way to generate a report about your build without modifying any build files, IMO, is Gradle Build Scans feature. BTW, they also support Maven!
Just append --scan to the invocation command and the report will be generated:
Starting with Gradle 4.3, you can enable build scans without any additional configuration in your build script. When using the command line option --scan to publish a build scan, the required build scan plugin is applied automatically. Before the end of the build, you are asked to accept the license agreement on the command line. The following console output demonstrates the behavior.
$ ./gradlew build --scan
BUILD SUCCESSFUL in 6s
Do you accept the Gradle Cloud Services license agreement (https://gradle.com/terms-of-service)? [yes, no]
yes
Gradle Cloud Services license agreement accepted.
Publishing build scan...
https://gradle.com/s/czajmbyg73t62
If you want a quick demo, here is a build scan report for one of my public projects: https://scans.gradle.com/s/6fmoybczbores, explore it as you wish. It has a "Dependencies" section, still it has no licensing.
The other approach could be using a third-party tool that monitors the dependencies for you. One well-known is Snyk, take a look, probably it will work for you. Probably one day GitHub will be able to track the dependencies too, but as of September 2019 it is able to track only Maven projects:
Related
We would like to start developing custom/internal SonarQube plugins (rules) in our organization but we can't get our hands on Apache Maven at the moment. All development tools must go through a rigorous certification process.
Ant being the current build tool of choice in our organization, is it possible to create a new SonarQube plugin (not being published to the marketplace) by replicating the same standard structure that is expected from SonarQube?
I've already read the following post from the SonarQube archives, but was wondering if that would still be possible to do with a little bit of elbow grease?
Concerning the answer from Simon Brandhof, I think that the plugin key, manifest generation and mandatory properties could easily be generated from well crafted Ant build script, as long as putting all required JARs in the classpath.
As far I know for developping new rules It is mandatory to create a new Sonarqube plugin and can be only build with the maven way.
see https://docs.sonarqube.org/display/DEV/Build+Plugin
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 have only little experience using maven with eclipse. One of the job descriptions which I received has "Workflow management using Maven" as a required skill. What does this mean ? What do they possibly expect?
I think they want you to correct them? :D
I'm not sure what they refer to. I would guess it relates to the developer workflow of creating and delivering software with eclipse (?) and maven.
So setting up a project from scratch is often done from an maven archetype (a project template if you like). A lot of open source frameworks offer archetypes to start with.
For existing projects you would check out the code from version control and import it into eclipse. the m2eclipse plugin is required to do that (but I think its quite common to have it)
Then there is building the software. Which is done through executing maven phases (which will then execute plugins). See maven-phases for more details. Maven phases have default plugins that execute (for example compile will run the compiler plugin).
So your workflow would look like this: you modify the files. compile them, test them, package them, deploy the artifacts into the maven repository. the maven install phase will store the artifacts in you local repository, the maven deploy phase will upload them into the company's repository.
From there the the files are installed. Yet you can use maven plugins to install the software into a application server. That depends on the traditions of the company.
I would not think of workflow as some strict step by step think like BPMN. Development is usually done with huge amounts of personal practices (are tests written in advance or while implementing, and so on).
Hope that will help :)
our application maven version is <version>my-version-SNAPSHOT</version>. We use the maven generated version number to identify builds in all communications (bug descriptions etc.). E.g. a bug was detected in my-version-20150908.142611-17.
However, we don't know how to easily link between these IDs and the Jenkins build IDs. The same version is called in Jenkins #54.
The lame workaround we found out is looking in the Jenkins console output, look for the line where it uploads into our nexus repository, and find out which maven build ID corresponds to #54... As for the other way around - which Jenkins ID corresponds to a maven build ID - we just take a guess based on timestamps :S
Any better ideas - technological or methodological?
You can use the Description Setter Plugin to parse the version number from the console output and set it as build description. The plugin's wiki page has an example that can easily be adapted to Maven.
If you are using Maven 3.2.1 or later, you can use the ${revision} variable as part of your version number to pass a desired version into Maven, e.g. use <version>1.0.0-${revision}</version> and run Maven with mvn verify -Drevision=${BUILD_NUMBER}. See MNG-5576 for details.
Now that Bazel (http://bazel.io/) has been opensourced, is there an incremental process by which I can gradually migrate (a large repository) from Maven to Bazel?
I work on Bazel. No, as far as we know there is no such process. I wish.
We have been running some migrations from other build systems to Bazel; the evidence isn't conclusive, but it's difficult to even envision how an incremental process would look like. There are some scenarios where we can envision one build system generating configuration files for another (like gyp), but then you still need to switch wholesale.
In the two years since Ulf responded, there's been a few efforts to assist with maven to bazel migration. In particular, the Bazel team is creating a tool to assist with this: https://github.com/bazelbuild/migration-tooling
The tool generates expansive WORKSPACE files from a set of pom files or maven coordinates. In the ideal case, you can pass the path to your maven project, and then it will generate a bzl file you can load into the WORKSPACE file.
More commentary on how to manage external dependencies can be found here: https://bazel.build/versions/master/docs/external.html
And another update (2018)...
There is a dedicated guide on migrating from Maven build tool to Bazel.
And on a general note, it’s best to have both build tools running in parallel until you have fully migrated your development team, CI system, and any other relevant integrations. You can run Maven and Bazel in the same repository.
https://docs.bazel.build/versions/master/migrate-maven.html
September 2019 update
Wix published a tool called Exodus to automatically migrate your Maven project to Bazel.
Additionally, rules_jvm_external has support for managing transitive Maven artifact dependencies.
May 2018 update
Here's another update using Jadep, a BUILD file generator for your Java projects.
There's a tutorial by the author who migrated google-java-format to Bazel: https://github.com/cgrushko/text/blob/master/migrating-gjf-to-bazel.md