Is there a way in Maven, Hudson, or Sonar to warn on the inclusion of certain out of date artifacts in a build.
For example, consider having a number of internal business jars. Some versions of these jars can go through an end-of-life phase. During this time, it would be nice if any builds that occurred would issue some sort warning and direct the user to some documentation about the issue.
To be clear, builds shouldn't fail. Also, we only want to apply this logic to a certain set of artifacts, not everything.
Using the maven dependency plugin you can run this
mvn versions:display-dependency-updates
This will display a list of all artifacts that have newer versions available in the repository. Just have the devs run that every so often and update accordingly.
You could try using the enforcer plugin to specify the dependencies which are no longer allowed.
Plugin has goals to either enforce the rules (thereby failing your build) or print a violation report.
Update
I use the dependencies report in Sonar to lookup cross project usage of obsolete libraries.
I know you're also using Sonar, but just in case here's an example:
Usage of log4j, version 1.2.9.
(This information is coming from the Maven POM of each project analysed by Sonar).
I think what you're really looking for, does not currently exist.... A plugin that works like the standard Maven enforcer plugin, but is configured from and raises violations in Sonar!
Why don't you post this as an idea on the Sonar JIRA?
Related
There are at least two ways of using the checkstyle in the NetBean maven project
(at the time of 2019-07-24):
using the NetBeans's plugin checkstyle-beans
v4.1.0, last Update: 2016-02-09, uses Checkstyle v6.15.
The last declared supported version is NetBeans v8.1
*although it works with v8.2
using the Maven's plugin maven-checkstyle-plugin
v3.1.0, last Update: 2019-05-12, uses Checkstyle v8.19
The last version of the github.com/checkstyle itself is v8.22
Questions:
Can I update them both to the last checkstyle?
Does they completely independent ?
the checkstyle-beans shows the marks beside the line numbers in the IDE
the maven-checkstyle-plugin can be used for the manual launch in the console, outside the IDE (mvn -e checkstyle:check).
Can it be configured and used inside the IDE ?
As a Netbeans user, you are stuck with Checkstyle-Beans as far as in-IDE support goes.
Maven and Checkstyle-Beans are completely independent of each other, but both depend on Checkstyle, of which they should use the same version.
This means you are also stuck with Checkstyle 6.15 (no upgrade unless Checkstyle-Beans gets a new version), which you must consequently use everywhere else also, or your Checkstyle configuration will not work (for example Checkstyle 6.15 config XMLs won't work with Checkstyle 8.22).
So, you have three options:
Use a different IDE, such as IntelliJ or Eclipse. Both have up-to-date Checkstyle support, so you can use the latest Checkstyle both in Maven and in the IDE.
Continue with Netbeans, and use Checkstyle 6.15. This is actually feasible imho. Checkstyle docs are versioned these days, so you can see the correct docs at https://checkstyle.sourceforge.io/version/6.15/. This will get you Checkstyle 6.15 support in Maven and in the IDE.
Continue with Netbeans, and use latest Checkstyle. Then you can only run it via Maven, but I suppose you can configure a button in NetBeans to make this easy.
Is there a way to fail a build in Jenkins if a certain jar is used in a Java Maven Project?
For example I know org.example:badartifact:1.0.1 has a security vulnerability. I told everyone about that, and they fixed their projects..., but maybe some third-party artifacts bring this with them as a transitive and nobody realizes that.
Or maybe someone down the line forgets this old bug...
So I would like to have a last check in Jenkins preferably, so that we don't end up with projects that have that special artifact included.
How do you handle situations like that, what tools do you use? (Whitelisting libs? Blacklisting libs?, etc)
Any suggestions are appreciated.
Possible Maven solution
You could have a company super POM (parent POM of all Maven projects within the company/department/team) and in that super POM configure the Maven Enforcer Plugin, its bannedDependencies rule to ban any library, version or even scope. I have personally used this option even for trivial mistakes (i.e. junit not in test scope would make the build fail).
This solution is a centralized one and as such easier to maintain, however requires all the projects to have the same parent POM and developers could at any time change the parent pom and as such skip this governance. On the other hand, a centralized parent POM is really useful for dependencies Management, common profiles, reporting and so on.
Note: you cannot configure it in the Maven settings of the Jenkins server via an active by default profile, for instance, in order to have it applied to all running Maven build, because Maven limits customization of builds in profiles provided by the settings (it's a design choice, to limit external impact and as such have an easier troubleshooting). I've tried it in the past and hit the wall.
Profiles in external files
Profiles specified in external files (i.e in settings.xml or profiles.xml) are not portable in the strictest sense. Anything that seems to stand a high chance of changing the result of the build is restricted to the inline profiles in the POM. Things like repository lists could simply be a proprietary repository of approved artifacts, and won't change the outcome of the build. Therefore, you will only be able to modify the and sections, plus an extra section
Possible Jenkins solution
If you want to have governance centralized in Jenkins directly, hence independently than Maven builds, I have applied these solutions in the past (and they perfectly work):
Jenkins Text Finder Plugin: you can make the build fail in case a regex or a matching text was found as part of the build output. In your case, you could have a Jenkins build step executing always mvn dependency:tree and as such have as part of the build output the list of dependencies (even transitive). A Text Finder rule matching your banned dependency will then match it and fail the build.
Fail The Build Jenkins Plugin: similar to the one above, but with a centralize management of configured Failure Causes. Again, failures are based on matching text, but no build configuration is required: it will be applied by default to all builds.
Here is one solution to do the job :)
With the Maven License plugin, you can scan the 3rd party dependencies for your Maven project and produce a THIRD_PARTY.txt report (in the target/generated-sources/license folder).
Maven command line:
mvn license:aggregate-add-third-party
Next, you can use the TextFinder plugin to search the "unsafe" dependencies in the THIRD_PARTY.txt file (ex: org.example:badartifact:1.0.1) and change the status of the build if needed.
Another solution is to use a 3rd party tool to do that.
I'm doing some investigation with this one: http://www.whitesourcesoftware.com/
This tool can provide a list of 3rd party dependencies with vulnerability issues.
I'm starting to fix a java project that has used maven and while I've got the project to build, at runtime it fails with missing dependencies. I've had a look and the errors are missing optional dependencies of included compile time dependencies. I can go through and add these but it seems to me that I can have everything building and running nicely only for some piece of code that I missed to use a missing dependency and the whole thing falls apart.
What I really want to know is whether there is an automated way to find optional dependencies that I have chosen to not include. I have used mvn dependency:tree but this only shows the dependencies I have (not sure of the scope it checks) and I have tried mvn dependency:analyze but this seems to show dependencies it thinks I don't use and those that have been pulled down indirectly. What I cannot see is how to see a list of optionals I don't include.
Currently my method of working around this is to read the poms and try to work it out from there, but I don't see this as particularly robust.
For reference, I am fairly new to maven style dependency management and on the face of it like it, but this optional thing is a bit of a stumbling block for me. I understand that optionals stop me pullin down dependencies I won't be using, but it hasn't clicked for me how I can workout what optionals are available and that I do need.
I am using Eclipse Juno, m2Eclipse (also have maven 3.0.5 cli), java 6/7.
Anyone got any ideas of how I can do this better, or what I am completely overlooking?
No the things are - somewhat - just this way. Maven does not do dependency management, it allows you to do dependency management by offering tools to use and analyze them. So the work still is on the developers side. People often mix that up.
This is mainly caused by the fact that projects often have different deployment targets. As a result sometimes they collect a bunch of jar files which are copied once into tomcat and a different set of files for weblogic. So there might be a readme in your project that states what to copy prior to deployment of the maven artifacts. Or it is implicit knowledge - then you're doomed.
dependency:analyze works on bytecode not on sources. therefore it does not see what maven knows.
Maybe mvn help:effective-pom gives a better basis to analyze the whole thing? Or you could try to modify the dependency plugin to show that information as well. Maven plugins are not so hard to work with.
I'm not aware of a plugin that displays all optional transitive dependencies. But since the pom.xml files of dependencies are downloaded into the local maven repo you could do a text search there.
A while ago there was a discussion on optional dependencies as well: Best strategy for dealing with optional dependencies - it might be helpful too.
I would like to run some validation checks against projects that jenkins builds. The validation checks would run against files from the project being built and report violations. I already have a core java application which can test the file types I require but, being a complete beginner with jenkins I'm unsure where to start with the jenkins integration! Any help is welcome!
You can use ant to call your validation code and fail the build if your validation checks fail. Otherwise you are writing your own Jenkins plugin for this tool you have to run your validation. Anything that fails the ant build also fails the Jenkins build.
I'd try to modify your existing validation application, or make a transformation step that makes it produce files that Jenkins Violations Plugin can scan
https://wiki.jenkins-ci.org/display/JENKINS/Violations
Hopefully you can pretend that your application is e.g. findbugs or one of the already supported checkers by just producing output in the same format.
Violations is frecuently used, as mentioned previously, to collect and present the findings of many other tools: checkstyle, pmd, cpd, findbugs and many others, most of which allow to create custom rules, although not always easily.
Maven plugins Jenkins can launch for specific verifications the output of which you can, of course, grep:
maven dependency plugin. The goals analyze, analyze-dep-mgt, analyze-duplicate are useful to check multiple situations with the project dependencies
maven verifier plugin. Verifies the existence or non-existence of files/directories and optionally checks file content against a regular expression
maven enforcer plugin. To check whether the pom.xml elements satisfy certain rules. How to create your own rules is well documented. And repositories of existing rules exist out there such as: enforcer rules, extra-enforcer rules...
What are the possibilities to enforce restrictions on the package dependencies in a Java build system? For example, the myapp.server.bl.Customer class should not be allowed to refer to the myapp.client.ui.customlayout package.
I'm interested in either Ant-based or IDE-specific solutions.
I'd like to get an error message in the build indicating that a (custom) package dependency rule has been violated and the build aborted. I also would like to maintain the dependencies in a list, preferably in a text file, outside of the Ant scripts or IDE project files.
(I don't know Maven but I've read it here it has better support for module dependency management)
I believe Checkstyle has a check for that.
It's called Import Control
You can configure Eclipse projects to specify Access Rules. Access rules can specify "Forbidden", "Discouraged", and "Accessible" levels all with wildcard rules. You can then configure violations of either Discouraged or Forbidden to be flagged as either warnings or errors during builds.
Kind of an old article on the idea (details may be out of date):
http://www.eclipsezone.com/eclipse/forums/t53736.html
If you're using Eclipse (or OSGi) plugins, then the "public" parts of the plugin/module are explicitly defined and this is part of the model.
ivy seems like a good solution for your problem (if you are using ant). Ivy is the offical dependency management component of Ant and thus integrates nicely with ant. It is capable of resolving dependencies, handle conflicts, create exclusions and so on.
It uses a simple xml structure to describe the dependencies and is easier to use than Maven, because it only tries to address dependency resolution problems.
From the Ivy homepage:
Ivy is a tool for managing (recording, tracking, resolving and reporting) project dependencies. It is characterized by the following:
flexibility and configurability - Ivy is essentially process agnostic and is not tied to any methodology or structure. Instead it provides the necessary flexibility and configurability to be adapted to a broad range of dependency management and build processes.
tight integration with Apache Ant - while available as a standalone tool, Ivy works particularly well with Apache Ant providing a number of powerful Ant tasks ranging from dependency resolution to dependency reporting and publication.
For the IDE specific solutions, IntelliJ IDEA has a dependency analysis tool that allows one to define invalid dependencies as well.
http://www.jetbrains.com/idea/webhelp2/dependency-validation-dialog.html
The dependency violation will be shown both when compiling and live, while editing the dependent class (as error/warning stripes in the right side error bar).
Even more automation can be obtained with JetBrains' TeamCity build server, that can run inspection builds and report the above configured checks.
For another IDE independent solution, AspectJ can be used to declare invalid dependencies (and integrate the step in the build process, in order to obtain warning/error info for the issues).
Eclipse has support for this via Build Path properties / jar properties. I think it may only work across jar / project boundaries.
Maybe Classsycle can be used:
http://classycle.sourceforge.net/ddf.html
You can use multiple modules in IDEA or Maven or multiple projects in Eclipse and Gradle. The concept is the same in all cases.
A trivial interpretation would be a module for myapp.server.bl and another for myapp.client.ui.customlayout with no compile time dependencies between either of them. Now any attempt to compile code or code-complete against the opposite module/project will fail as desired.
To audit how extensive the problem already is, a useful starting point for IntelliJ IDEA is Analyzing Dependencies:
http://www.jetbrains.com/idea/webhelp/analyzing-dependencies.html
From that article you can see how to run and act on dependency analysis for your project.