Maven allows developers to have their artifacts depend on ancient artifacts as old as 10 years (e.g. commons-el:commons-el:1.0 released in 2005, or jetty:javax.servlet:5.1.11 released in 2007). It seems a common practice in the java ecosystem to depend on specific old-versioned artifacts because their updates often break API silently.
Are those old artifacts patched if a security flaw is found? Who is going to take care of this?
If I pull in, say the newest release of spark org.apache.spark:spark-core_2.11:2.0.0, after maven downloading 3GiB of its dependencies, I can see a couple of them even older than 2005. If the resulting spark is executed, will those outdated dependencies expose patential security flaws?
Note: this is neither about security of java itself, nor security of maven, but artifacts delivered by maven.
Maven's central repository requirements do not speak to transitive dependency security issues.
The responsibility for updating transitive dependencies is reliant on the owner of the dependency. The owner/maintainer of the dependency would need to implement any fixes to issues caused in their codebase when updating their dependencies(the ones with the security flaws).
As a user of dependencies in your application that may have insecure transitive dependencies, you have a few options:
Update to the latest version of the dependency, the dependency owner may have already implemented a fix.
Exclude insecure transitive dependencies. Use at your own risk, as this may have unintended effects. Often this does work, as the insecure dependency may not actually be used by the dependency you needed.
Fork the dependency codebase, update the insecure transitive dependency, fix any issues, and submit a pull request.
Also, if you want a detailed report on the security of dependencies in your java application, you can check out the OWASP Dependency Checker, which checks your project's dependencies(including transitive) against the NIST NVD database.
If security flaws are discovered in a particular package, the expectation is that a new patched version is published by the authors. To your point the older vulnerable version remains in Maven Central and at first glance this would appear to be a very bad thing.
It leads to the following obvious questions:
Why doesn't someone patch these vulnerable versions?
Why doesn't someone remove these vulnerable versions?
Let's explore the consequences....
If someone is changing a library version that I'm using, how certain am I that the code remains functionally the same? This is why patches are handled as new versions. It's a lot less work for the author.
So if old vulnerable versions are not being patched, surely they should be deleted? Well... If users don't want to be use the latest patched version of a library, for fear it would break their code, they would certainly be just as unhappy if someone removed the library version they did depend on..... Damned if you do, and damned if you don't....
So in conclusion it's a case of user beware. We all need to manage our dependencies and adapt to changes in the various underlying APIs. If we ignore change, we run the risk of exposure to a vulnerability without an option to upgrade. Welcome to software development :-)
I'm a student with quite some experience in Java but totally new to Maven.
I was trying to implement a RESTful service provider and client with jersey-server and jersey-client. Both also depends on jersey-json, to make use of automatic conversion between POJO and JSON. Both of them also depend on a service model I implemented myself, where the POJO definition resides.
However, the code doesn't work for me. I spent quite a few hours looking for solutions everywhere on the Internet. It turns out the reason of the failure is that I accidentally specified version of jersey-server and jersey-client as 1.14, but jersey-json as 1.9.1.
The server doesn't work at the beginning, but at some point suddenly starts working. (I have no idea how this happened.) The client never worked until I change jersey-json version to 1.14.
Why do I need to have the same version for these different dependencies?
Because one depends on the other or otherwise has a compatibility issue. This is what dependency management is all about. Run mvn dependency:tree to see exactly how these libraries relate to each other.
In this case, it seems Jersey libraries are all released together as a "bundle" - and you need to use the versions from those bundles together. See: http://jersey.java.net/nonav/documentation/latest/chapter_deps.html
Note that this is an attribute of the Jersey libraries, not Maven.
Often different jars from the same distribution are tested together and given the same version number.
If you try to mix different versions it might work, or it might not, as its not a combination which was intended or tested.
We are developing webapps with Eclipse + Tomcat plugin. We recently started a new app which will run on Facebook and StudiVZ (FB competitor in Germany). Since the functionality of the app will be 95% the same we split the code into separate Eclipse projects (app-core, app-facebook, app-vz). The -core project is source-linked into the -facebook and -vz projects in Eclipse. We are also using Hudson for CI and made ant scripts that import the code from the -core project before building. So basically we tried to inherit on a project level.
The described method has some flaws:
Versioning is complicated
The -core project does not run standalone, which makes automatic testing partly impossible
We need to modify some models where the -core projects classes depend on
Other problems that make me think this is not the best solution
Does anyone have suggestions for a better solution?
There are a wealth of build tools available for Java that address dependency management and versioning specifically. Many of these integrate with Hudson and Eclipse.
I'd suggest looking at Maven and how it does dependency management as a good starting point. Even if you don't use Maven itself, many of the solutions out there build on Maven's dependency management mechanism. Something like Apache Ivy allows you to use maven dependency management, but still use your own custom Ant scripts; whereas something like Gradle is wholesale replacement.
You should be able to split your project into 3 or more parts and then establish dependencies via Java Build Path. You need to clean up the dependencies between the projects. If you need to configure your core components depending on whether it is a -facebook or a -vz project, you might need to separate configuration, maybe even use Spring or similar dependency injection framework.
When trying to introduce reuse into web-based Java projects, usually the problems arise in the UI code. Not many frameworks were built with this approach in mind.
I don't use/hate Eclipse[1], but can point to how we deal with a similar problem.
We use Maven with IntelliJ. In particular, both of these support modules which have defined internal dependencies. In your case it could be -fb and -vz modules depending on core, or you can split core into smaller parts (such as DAO, business logic, etc.).
When compiling, deliverables of "upper" modules would be used to build "lower" modules.
Let's go over points/flaws you have raised:
versioning is no longer a problem as everything sits under the same root of Subversion/GIT/VCS of your choice
Why is that a problem? Certainly this shouldn't be an issue for unit tests as how I understand TDD, these should not require complex environments. For automated tests, you would have to test the core API (as this is the interface between core and everything else, right?) hence this shouldn't require any fronted stuff?
you need to explain your other points to tell why you don't like it
It is against Geneva convention to ask a developer to use anything other than IDE of his/her choice.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
What are the main benefits of using maven compared to let's say ant ?
It seems to be more of a annoyance than a helpful tool.
I use maven 2, with plain Eclipse Java EE (no m2eclipse), and tomcat.
Supporters of maven believe that
Maven lets you get your package dependencies easily
Maven forces you to have a standard directory structure
In my experience
Figuring out package dependencies is really not that hard. You rarely do it anyway. Probably once during project setup and few more during upgrades. With maven you'll end up fixing mismatched dependencies, badly written poms, and doing package exclusions anyway.
Slow FIX-COMPILE-DEPLOY-DEBUG cycle, which kills productivity. This is my main gripe. You make a change, the you have to wait for maven build to kick in and wait for it to deploy. No hot deployment whatsoever.
Or am I just doing it wrong ? Please point me to the right direction, I'm all ears.
Figuring out package dependencies is really not that hard. You rarely do it anyway. Probably once during project setup and few more during upgrades. With maven you'll end up fixing mismatched dependencies, badly written poms, and doing package exclusions anyway.
Not that hard... for toy projects. But the projects I work on have many, really many, of them, and I'm very glad to get them transitively, to have a standardized naming scheme for them. Managing all this manually by hand would be a nightmare.
And yes, sometimes you have to work on the convergence of dependencies. But think about it twice, this is not inherent to Maven, this is inherent to any system using dependencies (and I am talking about Java dependencies in general here).
So with Ant, you have to do the same work except that you have to do everything manually: grabbing some version of project A and its dependencies, grabbing some version of project B and its dependencies, figuring out yourself what exact versions they use, checking that they don't overlap, checking that they are not incompatible, etc. Welcome to hell.
On the other hand, Maven supports dependency management and will retrieve them transitively for me and gives me the tooling I need to manage the complexity inherent to dependency management: I can analyze a dependency tree, control the versions used in transitive dependencies, exclude some of them if required, control the converge across modules, etc. There is no magic. But at least you have support.
And don't forget that dependency management is only a small part of what Maven offers, there is much more (not even mentioning the other tools that integrates nicely with Maven, e.g. Sonar).
Slow FIX-COMPILE-DEPLOY-DEBUG cycle, which kills productivity. This is my main gripe. You make a change, the you have to wait for maven build to kick in and wait for it to deploy. No hot deployment whatsoever.
First, why do you use Maven like this? I don't. I use my IDE to write tests, code until they pass, refactor, deploy, hot deploy and run a local Maven build when I'm done, before to commit, to make sure I will not break the continuous build.
Second, I'm not sure using Ant would make things much better. And to my experience, modular Maven builds using binary dependencies gives me faster build time than typical monolithic Ant builds. Anyway, have a look at Maven Shell for a ready to (re)use Maven environment (which is awesome by the way).
So at end, and I'm sorry to say so, it's not really Maven that is killing your productivity, it's you misusing your tools. And if you're not happy with it, well, what can I say, don't use it. Personally, I'm using Maven since 2003 and I never looked back.
Maven can be considered as complete project development tool not just build tool like Ant.
You should use Eclipse IDE with maven plugin to fix all your problems.
Here are few advantages of Maven, quoted from the Benefits of using Maven page:
Henning
quick project setup, no complicated build.xml files, just a POM and go
all developers in a project use the same jar dependencies due to
centralized POM.
getting a number of reports and metrics for a project "for free"
reduce the size of source distributions, because jars can be
pulled from a central location
Emmanuel Venisse
a lot of goals are available so it isn't necessary to develop some
specific build process part contrary
to ANT we can reuse existing ANT tasks
in build process with antrun plugin
Jesse Mcconnell
Promotes modular design of code. by making it simple to manage mulitple
projects it allows the design to be
laid out into muliple logical parts,
weaving these parts together through
the use of dependency tracking in pom
files.
Enforces modular design of code. it is easy to pay lipservice to modular
code, but when the code is in seperate
compiling projects it is impossible to
cross pollinate references between
modules of code unless you
specifically allow for it in your
dependency management... there is no
'I'll just do this now and fix it
later' implementations.
Dependency Management is clearly declared. with the dependency
management mechanism you have to try
to screw up your jar
versioning...there is none of the
classic problem of 'which version of
this vendor jar is this?' And setting
it up on an existing project rips the
top off of the existing mess if it
exists when you are forced to make
'unknown' versions in your repository
to get things up and running...that or
lie to yourself that you know the
actual version of ABC.jar.
strong typed life cycle there is a strong defined lifecycle that a
software system goes thru from the
initiation of a build to the end...
and the users are allowed to mix and
match their system to the lifecycle
instead of cobble together their own
lifecycle.. this has the additional
benefit of allowing people to move
from one project to another and speak
using the same vocabulary in terms of
software building
Vincent Massol
Greater momentum: Ant is now legacy and not moving fast ahead. Maven is
forging ahead fast and there's a
potential of having lots of high-value
tools around Maven (CI, Dashboard
project, IDE integration, etc).
Figuring out dependencies for small projects is not hard. But once you start dealing with a dependency tree with hundreds of dependencies, things can easily get out of hand. (I'm speaking from experience here ...)
The other point is that if you use an IDE with incremental compilation and Maven support (like Eclipse + m2eclipse), then you should be able to set up edit/compile/hot deploy and test.
I personally don't do this because I've come to distrust this mode of development due to bad experiences in the past (pre Maven). Perhaps someone can comment on whether this actually works with Eclipse + m2eclipse.
Maven is one of the tools where you need to actually decide up front that you like it and want to use it, since you will spend quite some time learning it, and having made said decision once and for all will allow you to skip all kinds of doubt while learning (because you like it and want to use it)!
The strong conventions help in many places - like Hudson that can do wonders with Maven projects - but it may be hard to see initially.
edit: As of 2016 Maven is the only Java build tool where all three major IDEs can use the sources out of the box. In other words, using maven makes your build IDE-agnostic. This allows for e.g. using Netbeans profiling even if you normally work In eclipse
Maven advantages over ant are quite a few. I try to summarize them here.
Convention over Configuration
Maven uses a distinctive approach for the project layout and startup, that makes easy to just jump in a project. Usually it only takes the checkount and the maven command to get the artifacts of the project.
Project Modularization
Project conventions suggest (or better, force) the developer to modularize the project. Instead of a monolithic project you are often forced to divide your project in smaller sub components, which make it easier debug and manage the overall project structure
Dependency Management and Project Lifecycle
Overall, with a good SCM configuration and an internal repository, the dependency management is quite easy, and you are again forced to think in terms of Project Lifecycle - component versions, release management and so on. A little more complex than the ant something, but again, an improvement in quality of the project.
What is wrong with maven?
Maven is not easy. The build cycle (what gets done and when) is not so clear within the POM. Also, some issue arise with the quality of components and missing dependencies in public repositories.
The best approach (to me) is to have an internal repository for caching (and keeping) dependencies around, and to apply to release management of components. For projects bigger than the sample projects in a book, you will thank maven before or after
Maven can provide benefits for your build process by employing standard conventions and practices to accelerate your development cycle while at the same time helping you achieve a higher rate of success. For a more detailed look at how Maven can help you with your development process please refer to The Benefits of Using Maven.
Maven is a powerful project management tool that is based on POM (project object model). It is used for projects build, dependency and documentation.
It simplifies the build process like ANT. But it is too much advanced than ANT.
Maven helps to manage-
Builds,Documentation,Reporing,SCMs,Releases,Distribution.
- maven repository is a directory of packaged JAR file with pom.xml file. Maven searches for dependencies in the repositories.
I've never come across point 2? Can you explain why you think this affects deployment in any way. If anything maven allows you to structure your projects in a modularised way that actually allows hot fixes for bugs in a particular tier, and allows independent development of an API from the remainder of the project for example.
It is possible that you are trying to cram everything into a single module, in which case the problem isn't really maven at all, but the way you are using it.
This should have been a comment, but it wasn't fitting in a comment length, so I posted it as an answer.
All the benefits mentioned in other answers are achievable by simpler means than using maven. If, for-example, you are new to a project, you'll anyway spend more time creating project architecture, joining components, coding than downloading jars and copying them to lib folder. If you are experienced in your domain, then you already know how to start off the project with what libraries. I don't see any benefit of using maven, especially when it poses a lot of problems while automatically doing the "dependency management".
I only have intermediate level knowledge of maven, but I tell you, I have done large projects(like ERPs) without using maven.
We have multiple maven projects depending on on our own common libraries.
When we upgrade a library it would be useful to quickly find out which projects have a dependency on the library (and might need to use the new version)
Obviously I can manually look in all the pom files or write a script to do it but this is less than ideal.
Are there any tools that provide this functionality. e.g. a hudson plugin, Nexus, artifactory etc?
EDIT:
Some clarifications:
I don't want to upgrade all projects at once. The regression testing and release effort makes this impractical and often unnecessary (even with automated testing and releasing). I just want a report showing me what may projects may need to have the library upgraded...
Many answers focus around the project itself flagging what version is used. Ideally the solution would work so that for a given library I can ask what uses this. This looks like what the Nexus issue below is talking about.
Hudson does something similar with automated downstream maven builds. I may look into extending this with a hudson plugin.
I know that albeit being a good tool for managing poms and jars, Artifactory has no such feature you're asking :(
You might want to check this StackOverflow question: Look for new versions of dependencies
Alternatively you might want to check Versions Maven Plugin. Among other things, it allows you to scan trough project's dependencies and produce a report of those dependencies which have newer versions available.
A quite usual practice is to declare all the versions in dependencyManagement of the parent module and reference dependencies without versions everywhere else. In this case you'll only need to update only one POM.
I solved this issue by using dependency version ranges to fetch the newest versions automatically.
<dependency>
<groupId>foo.xyzzy</groupId>
<artifactId>bar</artifactId>
<version>[1.0.0,2.0.0)</version>
</dependency>
It might make sense to use a version range such as [1.0,) to include the newest version after 1.0.
The trick to make this work is to have dev and prod profiles that include and exclude the snapshot repos for your commons and to use hudson to automatically build projects when a dependency is re-built.
Not exactly what you're asking for but the Dependency Convergence report might be helpful. Here are some examples.
Update: I'm aware that I'm not exactly answering the question with my suggestion but doing it the other way (finding all projects that reference a given artifact) would require gathering all POMs of all projects and I'm not aware of a solution currently offering such a referenced by feature (a corporate repository would be the perfect candidate to implement this though).
My search is over: http://www.sonarsource.org/sonar-2-1-in-screenshots/
Sonar now provides this.