<p>In Maven, dependencies are usually set up like this:</p>

<pre class="lang-xml prettyprint-override"><code>&lt;dependency&gt;
  &lt;groupId&gt;wonderful-inc&lt;/groupId&gt;
  &lt;artifactId&gt;dream-library&lt;/artifactId&gt;
  &lt;version&gt;1.2.3&lt;/version&gt;
&lt;/dependency&gt;
</code></pre>

<p>Now, if you are working with libraries that have frequent releases, constantly updating the &lt;version&gt; tag can be somewhat annoying. Is there any way to tell Maven to always use the latest available version (from the repository)? </p>

[{'answer_id': 30590, 'author': 'Martin Klinke', 'author_id': 1793, 'author_profile': 'https://Stackoverflow.com/users/1793', 'pm_score': 4, 'selected': False, 'text': "<p>Are you possibly depending on development versions that obviously change a lot during development? </p>\n\n<p>Instead of incrementing the version of development releases, you could just use a snapshot version that you overwrite when necessary, which means you wouldn't have to change the version tag on every minor change. Something like 1.0-SNAPSHOT...</p>\n\n<p>But maybe you are trying to achieve something else ;)</p>\n"}, {'answer_id': 30628, 'author': 'Martin Klinke', 'author_id': 1793, 'author_profile': 'https://Stackoverflow.com/users/1793', 'pm_score': 7, 'selected': False, 'text': '<p>Please take a look at <a href="https://cwiki.apache.org/confluence/display/MAVENOLD/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges" rel="noreferrer">this page</a> (section "Dependency Version Ranges"). What you might want to do is something like </p>\n\n<pre class="lang-xml prettyprint-override"><code>&lt;version&gt;[1.2.3,)&lt;/version&gt;\n</code></pre>\n\n<p>These version ranges are implemented in Maven2.</p>\n'}, {'answer_id': 1172371, 'author': 'Rich Seller', 'author_id': 123582, 'author_profile': 'https://Stackoverflow.com/users/123582', 'pm_score': 11, 'selected': True, 'text': '<p><em><strong>NOTE:</strong></em></p>\n<p><em>The mentioned <code>LATEST</code> and <code>RELEASE</code> metaversions <a href="https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution" rel="noreferrer">have been dropped <strong>for plugin dependencies</strong> in Maven 3 &quot;for the sake of reproducible builds&quot;</a>, over 6 years ago.\n(They still work perfectly fine for regular dependencies.)\nFor plugin dependencies please refer to this <strong><a href="https://stackoverflow.com/a/1172805/363573">Maven 3 compliant solution</a></strong></em>.</p>\n<hr />\n<p>If you  always want to use the newest version, Maven has two keywords you can use as an alternative to version ranges. You should use these options with care as you are no longer in control of the plugins/dependencies you are using.</p>\n<blockquote>\n<p>When you depend on a plugin or a dependency, you can use the a version value of LATEST or RELEASE. LATEST refers to the latest released or snapshot version of a particular artifact, the most recently deployed artifact in a particular repository. RELEASE refers to the last non-snapshot release in the repository. In general, it is not a best practice to design software which depends on a non-specific version of an artifact. If you are developing software, you might want to use RELEASE or LATEST as a convenience so that you don\'t have to update version numbers when a new release of a third-party library is released. When you release software, you should always make sure that your project depends on specific versions to reduce the chances of your build or your project being affected by a software release not under your control. Use LATEST and RELEASE with caution, if at all.</p>\n</blockquote>\n<p>See the <a href="http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-pom-syntax.html#pom-relationships-sect-latest-release" rel="noreferrer">POM Syntax section of the Maven book</a> for more details. Or see this doc on <a href="http://www.mojohaus.org/versions-maven-plugin/examples/resolve-ranges.html" rel="noreferrer">Dependency Version Ranges</a>, where:</p>\n<ul>\n<li>A square bracket ( <code>[</code> &amp; <code>]</code> ) means &quot;closed&quot; (inclusive).</li>\n<li>A parenthesis ( <code>(</code> &amp; <code>)</code> ) means &quot;open&quot; (exclusive).</li>\n</ul>\n<p>Here\'s an example illustrating the various options. In the Maven repository, com.foo:my-foo has the following metadata:</p>\n<pre class="lang-xml prettyprint-override"><code>&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;&lt;metadata&gt;\n  &lt;groupId&gt;com.foo&lt;/groupId&gt;\n  &lt;artifactId&gt;my-foo&lt;/artifactId&gt;\n  &lt;version&gt;2.0.0&lt;/version&gt;\n  &lt;versioning&gt;\n    &lt;release&gt;1.1.1&lt;/release&gt;\n    &lt;versions&gt;\n      &lt;version&gt;1.0&lt;/version&gt;\n      &lt;version&gt;1.0.1&lt;/version&gt;\n      &lt;version&gt;1.1&lt;/version&gt;\n      &lt;version&gt;1.1.1&lt;/version&gt;\n      &lt;version&gt;2.0.0&lt;/version&gt;\n    &lt;/versions&gt;\n    &lt;lastUpdated&gt;20090722140000&lt;/lastUpdated&gt;\n  &lt;/versioning&gt;\n&lt;/metadata&gt;\n</code></pre>\n<p>If a dependency on that artifact is required, you have the following options (other <a href="https://cwiki.apache.org/confluence/display/MAVENOLD/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges" rel="noreferrer">version ranges</a> can be specified of course, just showing the relevant ones here):</p>\n<p>Declare an exact version (will always resolve to 1.0.1):</p>\n<pre class="lang-xml prettyprint-override"><code>&lt;version&gt;[1.0.1]&lt;/version&gt;\n</code></pre>\n<p>Declare an explicit version (will always resolve to 1.0.1 unless a collision occurs, when Maven will select a matching version):</p>\n<pre class="lang-xml prettyprint-override"><code>&lt;version&gt;1.0.1&lt;/version&gt;\n</code></pre>\n<p>Declare a version range for all 1.x (will currently resolve to 1.1.1):</p>\n<pre class="lang-xml prettyprint-override"><code>&lt;version&gt;[1.0.0,2.0.0)&lt;/version&gt;\n</code></pre>\n<p>Declare an open-ended version range (will resolve to 2.0.0):</p>\n<pre class="lang-xml prettyprint-override"><code>&lt;version&gt;[1.0.0,)&lt;/version&gt;\n</code></pre>\n<p>Declare the version as LATEST (will resolve to 2.0.0) (removed from maven 3.x)</p>\n<pre class="lang-xml prettyprint-override"><code>&lt;version&gt;LATEST&lt;/version&gt;\n</code></pre>\n<p>Declare the version as RELEASE (will resolve to 1.1.1) (removed from maven 3.x):</p>\n<pre class="lang-xml prettyprint-override"><code>&lt;version&gt;RELEASE&lt;/version&gt;\n</code></pre>\n<p>Note that by default your own deployments will update the &quot;latest&quot; entry in the Maven metadata, but to update the &quot;release&quot; entry, you need to activate the &quot;release-profile&quot; from the <a href="http://maven.apache.org/guides/introduction/introduction-to-the-pom.html" rel="noreferrer">Maven super POM</a>. You can do this with either &quot;-Prelease-profile&quot; or &quot;-DperformRelease=true&quot;</p>\n<hr />\n<p>It\'s worth emphasising that any approach that allows Maven to pick the dependency versions (LATEST, RELEASE, and version ranges) can leave you open to build time issues, as later versions can have different behaviour (for example the dependency plugin has previously switched a default value from true to false, with confusing results).</p>\n<p>It is therefore generally a good idea to define exact versions in releases. As <a href="https://stackoverflow.com/questions/30571/how-do-i-tell-maven-to-use-the-latest-version-of-a-dependency/1172805#1172805">Tim\'s answer</a> points out, the <a href="http://www.mojohaus.org/versions-maven-plugin/" rel="noreferrer">maven-versions-plugin</a> is a handy tool for updating dependency versions, particularly the <a href="http://www.mojohaus.org/versions-maven-plugin/use-latest-versions-mojo.html" rel="noreferrer">versions:use-latest-versions</a> and <a href="http://www.mojohaus.org/versions-maven-plugin/use-latest-releases-mojo.html" rel="noreferrer">versions:use-latest-releases</a> goals.</p>\n'}, {'answer_id': 1172805, 'author': 'Tim', 'author_id': 53444, 'author_profile': 'https://Stackoverflow.com/users/53444', 'pm_score': 9, 'selected': False, 'text': '<p>Now I know this topic is old, but reading the question and the OP supplied answer it seems the <a href="http://www.mojohaus.org/versions-maven-plugin/" rel="noreferrer">Maven Versions Plugin</a> might have actually been a better answer to his question:</p>\n\n<p>In particular the following goals could be of use:</p>\n\n<ul>\n<li><strong>versions:use-latest-versions</strong> searches the pom for all versions\nwhich have been a newer version and\nreplaces them with the latest\nversion.</li>\n<li><strong>versions:use-latest-releases</strong> searches the pom for all non-SNAPSHOT\nversions which have been a newer\nrelease and replaces them with the\nlatest release version.</li>\n<li><strong>versions:update-properties</strong> updates properties defined in a\nproject so that they correspond to\nthe latest available version of\nspecific dependencies. This can be\nuseful if a suite of dependencies\nmust all be locked to one version.</li>\n</ul>\n\n<p>The following other goals are also provided:</p>\n\n<ul>\n<li><strong>versions:display-dependency-updates</strong> scans a project\'s dependencies and\nproduces a report of those\ndependencies which have newer\nversions available.</li>\n<li><strong>versions:display-plugin-updates</strong> scans a project\'s plugins and\nproduces a report of those plugins\nwhich have newer versions available.</li>\n<li><strong>versions:update-parent</strong> updates the parent section of a project so\nthat it references the newest\navailable version. For example, if\nyou use a corporate root POM, this\ngoal can be helpful if you need to\nensure you are using the latest\nversion of the corporate root POM.</li>\n<li><strong>versions:update-child-modules</strong> updates the parent section of the\nchild modules of a project so the\nversion matches the version of the\ncurrent project. For example, if you\nhave an aggregator pom that is also\nthe parent for the projects that it\naggregates and the children and\nparent versions get out of sync, this\nmojo can help fix the versions of the\nchild modules. (Note you may need to\ninvoke Maven with the -N option in\norder to run this goal if your\nproject is broken so badly that it\ncannot build because of the version\nmis-match).</li>\n<li><strong>versions:lock-snapshots</strong> searches the pom for all -SNAPSHOT\nversions and replaces them with the\ncurrent timestamp version of that\n-SNAPSHOT, e.g. -20090327.172306-4</li>\n<li><strong>versions:unlock-snapshots</strong> searches the pom for all timestamp\nlocked snapshot versions and replaces\nthem with -SNAPSHOT.</li>\n<li><strong>versions:resolve-ranges</strong> finds dependencies using version ranges and\nresolves the range to the specific\nversion being used.</li>\n<li><strong>versions:use-releases</strong> searches the pom for all -SNAPSHOT versions\nwhich have been released and replaces\nthem with the corresponding release\nversion.</li>\n<li><strong>versions:use-next-releases</strong> searches the pom for all non-SNAPSHOT\nversions which have been a newer\nrelease and replaces them with the\nnext release version.</li>\n<li><strong>versions:use-next-versions</strong> searches the pom for all versions\nwhich have been a newer version and\nreplaces them with the next version.</li>\n<li><strong>versions:commit</strong> removes the pom.xml.versionsBackup files. Forms\none half of the built-in "Poor Man\'s\nSCM".</li>\n<li><strong>versions:revert</strong> restores the pom.xml files from the\npom.xml.versionsBackup files. Forms\none half of the built-in "Poor Man\'s\nSCM".</li>\n</ul>\n\n<p>Just thought I\'d include it for any future reference.</p>\n'}, {'answer_id': 8795380, 'author': 'Adam Gent', 'author_id': 318174, 'author_profile': 'https://Stackoverflow.com/users/318174', 'pm_score': 7, 'selected': False, 'text': '<p>Unlike others I think there are many reasons why you might <em>always want the latest</em> version. Particularly if you are doing continuous deployment (we sometimes have like 5 releases in a day) and don\'t want to do a multi-module project.</p>\n\n<p>What I do is make Hudson/Jenkins do the following for every build:</p>\n\n<pre class="lang-none prettyprint-override"><code>mvn clean versions:use-latest-versions scm:checkin deploy -Dmessage="update versions" -DperformRelease=true\n</code></pre>\n\n<p>That is I use the versions plugin and scm plugin to update the dependencies and then check it in to source control. Yes I let my CI do SCM checkins (which you have to do anyway for the maven release plugin).</p>\n\n<p>You\'ll want to setup the versions plugin to only update what you want:</p>\n\n<pre class="lang-xml prettyprint-override"><code>&lt;plugin&gt;\n    &lt;groupId&gt;org.codehaus.mojo&lt;/groupId&gt;\n    &lt;artifactId&gt;versions-maven-plugin&lt;/artifactId&gt;\n    &lt;version&gt;1.2&lt;/version&gt;\n    &lt;configuration&gt;\n        &lt;includesList&gt;com.snaphop&lt;/includesList&gt;\n        &lt;generateBackupPoms&gt;false&lt;/generateBackupPoms&gt;\n        &lt;allowSnapshots&gt;true&lt;/allowSnapshots&gt;\n    &lt;/configuration&gt;\n&lt;/plugin&gt;\n</code></pre>\n\n<p>I use the release plugin to do the release which takes care of -SNAPSHOT and validates that there is a release version of -SNAPSHOT (which is important).</p>\n\n<p>If you do what I do you will get the latest version for all snapshot builds and the latest release version for release builds. Your builds will also be reproducible.</p>\n\n<p><strong>Update</strong></p>\n\n<p>I noticed some comments asking some specifics of this workflow. I will say we don\'t use this method anymore and the big reason why is the maven versions plugin is buggy and in general is inherently flawed.</p>\n\n<p>It is flawed because to run the versions plugin to adjust versions all the existing versions need to exist for the pom to run correctly. That is the versions plugin cannot update to the latest version of anything if it can\'t find the version referenced in the pom. This is actually rather annoying as we often cleanup old versions for disk space reasons.</p>\n\n<p>Really you need a separate tool from maven to adjust the versions (so you don\'t depend on the pom file to run correctly). I have written such a tool in the the lowly language that is Bash. The script will update the versions like the version plugin and check the pom back into source control. It also runs like 100x faster than the mvn versions plugin. Unfortunately it isn\'t written in a manner for public usage but if people are interested I could make it so and put it in a gist or github.</p>\n\n<p>Going back to workflow as some comments asked about that this is what we do:</p>\n\n<ol>\n<li>We have 20 or so projects in their own repositories with their own jenkins jobs</li>\n<li>When we release the maven release plugin is used. The workflow of that is covered in the plugin\'s documentation. The maven release plugin sort of sucks (and I\'m being kind) but it does work. One day we plan on replacing this method with something more optimal.</li>\n<li>When one of the projects gets released jenkins then runs a special job we will call the update all versions job (how jenkins knows its a release is a complicated manner in part because the maven jenkins release plugin is pretty crappy as well).</li>\n<li>The update all versions job knows about all the 20 projects. It is actually an aggregator pom to be specific with all the projects in the modules section in dependency order. Jenkins runs our magic groovy/bash foo that will pull all the projects update the versions to the latest and then checkin the poms (again done in dependency order based on the modules section). </li>\n<li>For each project if the pom has changed (because of a version change in some dependency) it is checked in and then we immediately ping jenkins to run the corresponding job for that project (this is to preserve build dependency order otherwise you are at the mercy of the SCM Poll scheduler). </li>\n</ol>\n\n<p>At this point I\'m of the opinion it is a good thing to have the release and auto version a separate tool from your general build anyway.</p>\n\n<p>Now you might think maven sort of sucks because of the problems listed above but this actually would be fairly difficult with a build tool that does not have a declarative easy to parse <strong>extendable</strong> syntax (aka XML).</p>\n\n<p>In fact we add custom XML attributes through namespaces to help hint bash/groovy scripts (e.g. don\'t update this version). </p>\n'}, {'answer_id': 29435600, 'author': 'bclarance', 'author_id': 1263023, 'author_profile': 'https://Stackoverflow.com/users/1263023', 'pm_score': 3, 'selected': False, 'text': '<p>By the time this question was posed there were some kinks with version ranges in maven, but these have been resolved in newer versions of maven.\nThis article captures very well how version ranges work and best practices to better understand how maven understands versions: <a href="https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855" rel="nofollow noreferrer">https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855</a></p>\n'}, {'answer_id': 31077439, 'author': 'Junchen Liu', 'author_id': 719278, 'author_profile': 'https://Stackoverflow.com/users/719278', 'pm_score': 3, 'selected': False, 'text': '<p>The truth is even in 3.x it still works, surprisingly the projects builds and deploys. But the  LATEST/RELEASE keyword causing problems in m2e and eclipse all over the place, ALSO projects depends on the dependency which deployed through the  LATEST/RELEASE fail to recognize the version. </p>\n\n<p>It will also causing problem if you are try to define the version as property, and reference it else where.</p>\n\n<p>So the conclusion is use the <a href="http://www.mojohaus.org/versions-maven-plugin/" rel="noreferrer">versions-maven-plugin</a> if you can.</p>\n'}, {'answer_id': 31568725, 'author': 'mkobit', 'author_id': 627727, 'author_profile': 'https://Stackoverflow.com/users/627727', 'pm_score': 5, 'selected': False, 'text': '<p>The dependencies syntax is located at the <a href="https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification">Dependency Version Requirement Specification</a> documentation. Here it is is for completeness:</p>\n\n<blockquote>\n  <p>Dependencies\' <code>version</code> element define version requirements, used to compute effective dependency version. Version requirements have the following syntax:</p>\n  \n  <ul>\n  <li><code>1.0</code>: "Soft" requirement on 1.0 (just a recommendation, if it matches all other ranges for the dependency)</li>\n  <li><code>[1.0]</code>: "Hard" requirement on 1.0</li>\n  <li><code>(,1.0]</code>: x &lt;= 1.0</li>\n  <li><code>[1.2,1.3]</code>: 1.2 &lt;= x &lt;= 1.3</li>\n  <li><code>[1.0,2.0)</code>: 1.0 &lt;= x &lt; 2.0</li>\n  <li><code>[1.5,)</code>: x >= 1.5</li>\n  <li><code>(,1.0],[1.2,)</code>: x &lt;= 1.0 or x >= 1.2; multiple sets are comma-separated</li>\n  <li><code>(,1.1),(1.1,)</code>: this excludes 1.1 (for example if it is known not to\n  work in combination with this library)</li>\n  </ul>\n</blockquote>\n\n<p>In your case, you could do something like <code>&lt;version&gt;[1.2.3,)&lt;/version&gt;</code></p>\n'}, {'answer_id': 31782879, 'author': 'trung', 'author_id': 497300, 'author_profile': 'https://Stackoverflow.com/users/497300', 'pm_score': 3, 'selected': False, 'text': "<p>Who ever is using LATEST, please make sure you have -U otherwise the latest snapshot won't be pulled.</p>\n\n<pre><code>mvn -U dependency:copy -Dartifact=com.foo:my-foo:LATEST\n// pull the latest snapshot for my-foo from all repositories\n</code></pre>\n"}, {'answer_id': 43852216, 'author': 'Markon', 'author_id': 126125, 'author_profile': 'https://Stackoverflow.com/users/126125', 'pm_score': 3, 'selected': False, 'text': '<p>Sometimes you don\'t want to use version ranges, because it seems that they are "slow" to resolve your dependencies, especially when there is continuous delivery in place and there are tons of versions - mainly during heavy development.</p>\n\n<p>One workaround would be to use the <a href="http://www.mojohaus.org/versions-maven-plugin/" rel="noreferrer">versions-maven-plugin</a>. For example, you can declare a property:</p>\n\n<pre><code>&lt;properties&gt;\n    &lt;myname.version&gt;1.1.1&lt;/myname.version&gt;\n&lt;/properties&gt;\n</code></pre>\n\n<p>and add the versions-maven-plugin to your pom file:</p>\n\n<pre><code>&lt;build&gt;\n    &lt;plugins&gt;\n        &lt;plugin&gt;\n            &lt;groupId&gt;org.codehaus.mojo&lt;/groupId&gt;\n            &lt;artifactId&gt;versions-maven-plugin&lt;/artifactId&gt;\n            &lt;version&gt;2.3&lt;/version&gt;\n            &lt;configuration&gt;\n                &lt;properties&gt;\n                    &lt;property&gt;\n                        &lt;name&gt;myname.version&lt;/name&gt;\n                        &lt;dependencies&gt;\n                            &lt;dependency&gt;\n                                &lt;groupId&gt;group-id&lt;/groupId&gt;\n                                &lt;artifactId&gt;artifact-id&lt;/artifactId&gt;\n                                &lt;version&gt;latest&lt;/version&gt;\n                            &lt;/dependency&gt;\n                        &lt;/dependencies&gt;\n                    &lt;/property&gt;\n                &lt;/properties&gt;\n            &lt;/configuration&gt;\n        &lt;/plugin&gt;\n    &lt;/plugins&gt;\n&lt;/build&gt;\n</code></pre>\n\n<p>Then, in order to update the dependency, you have to execute the goals:</p>\n\n<pre><code>mvn versions:update-properties validate\n</code></pre>\n\n<p>If there is a version newer than 1.1.1, it will tell you:</p>\n\n<pre><code>[INFO] Updated ${myname.version} from 1.1.1 to 1.3.2\n</code></pre>\n'}, {'answer_id': 49895638, 'author': 'Arayan Singh', 'author_id': 9339242, 'author_profile': 'https://Stackoverflow.com/users/9339242', 'pm_score': 3, 'selected': False, 'text': '<p>If you want Maven should use the latest version of a dependency, then you can use <a href="http://www.mojohaus.org/versions-maven-plugin/" rel="noreferrer">Versions Maven Plugin</a> and how to use this plugin, Tim has already given a good answer, follow his <a href="https://stackoverflow.com/a/1172805/9339242">answer</a>.</p>\n\n<p>But as a developer, I will not recommend this type of practices. WHY?</p>\n\n<p>answer to why is already given by <a href="https://stackoverflow.com/users/70604/pascal-thivent">Pascal Thivent</a> in the comment of the question</p>\n\n<blockquote>\n  <p>I really don\'t recommend this practice (nor using version ranges) for\n  the sake of build reproducibility. A build that starts to suddenly\n  fail for an unknown reason is way more annoying than updating manually\n  a version number.</p>\n</blockquote>\n\n<p>I will recommend this type of practice: </p>\n\n<pre><code>&lt;properties&gt;\n    &lt;spring.version&gt;3.1.2.RELEASE&lt;/spring.version&gt;\n&lt;/properties&gt;\n\n&lt;dependencies&gt;\n\n    &lt;dependency&gt;\n        &lt;groupId&gt;org.springframework&lt;/groupId&gt;\n        &lt;artifactId&gt;spring-core&lt;/artifactId&gt;\n        &lt;version&gt;${spring.version}&lt;/version&gt;\n    &lt;/dependency&gt;\n\n    &lt;dependency&gt;\n        &lt;groupId&gt;org.springframework&lt;/groupId&gt;\n        &lt;artifactId&gt;spring-context&lt;/artifactId&gt;\n        &lt;version&gt;${spring.version}&lt;/version&gt;\n    &lt;/dependency&gt;\n\n&lt;/dependencies&gt;\n</code></pre>\n\n<p>it is easy to maintain and easy to debug. You can update your POM in no time.</p>\n'}, {'answer_id': 52685301, 'author': 'yilin  ', 'author_id': 5673607, 'author_profile': 'https://Stackoverflow.com/users/5673607', 'pm_score': 2, 'selected': False, 'text': '<p>MY solution in maven 3.5.4 ,use nexus, in eclipse:</p>\n\n<pre><code>&lt;dependency&gt;\n    &lt;groupId&gt;yilin.sheng&lt;/groupId&gt;\n    &lt;artifactId&gt;webspherecore&lt;/artifactId&gt;\n    &lt;version&gt;LATEST&lt;/version&gt; \n&lt;/dependency&gt;\n</code></pre>\n\n<p>then in eclipse: <code>atl + F5</code>, and choose the <code>force update of snapshots/release</code></p>\n\n<p>it works for me.</p>\n'}]
['https://Stackoverflow.com/questions/30571', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/1709/']