Maven locks maven-metadata-local.xml-s and never updates snapshots

[Martin Todorov <ca...@gmail.com>]

Hi,

I am writing to you concerning
MNG-4142<http://jira.codehaus.org/browse/MNG-4142>.
The title of the bug is misleading - it should be "Maven locks
maven-metadata-local.xml-s and never updates snapshots". This Maven bug has
been around for quite a while and is preventing us from being able to use a
distributed build system properly. We use Hudson, and although there is the
possibility to run each build with a private repository, this is not a
reasonable solution, if you have a large number of builds (due to the amount
of space you will need for each node).

We have been hitting this a lot lately. We have Hudson running with 7-8
nodes (using different operating systems and Maven 2.2.1).

The problem can be described as follows:
- You build a SNAPSHOT module and install it locally. You work on it for a
few days and commit your code.
- In the meantime, there are other changes to the module. However, your
maven-metadata-local.xml contains a line that tells Maven not to update
snapshots (even with -U, it will not do so). You end up using older
snapshots locally and the only solution is to remove the artifact's local
metadata file (or edit it manually).

When it comes down to regular dependencies, I have written a small plugin
that works around the issues of locked maven-metadata-local.xml files
containing localCopy set to true. (Check
this<https://build-force.googlecode.com/svn/trunk/dependencies-cleaner>for
more info). However, when it comes down to parents, the situation is
much more trickier as the projects get loaded and interpolated long before
the actual build phases start.

I would like to ask why is the proposed patch not being accepted/reviewed? I
have confirmed that this bug exists also under Maven 3.0. The proposed patch
(by David Rousselie) is also applicable to Maven 3, if you copy the five
lines of changes<http://jira.codehaus.org/secure/attachment/43860/MNG-4142.patch>to
the DefaultRepositoryMetadataManager.java class.

Will there be another 2.2.x release in which this could be included? If not,
could this bug and patch be reviewed for 3.1?

Writing workaround plugins is not a good idea, and so is using a modified
Maven in your company. Therefore, I would like to request that this issue be
fixed in the next version of Maven, as it's quite critical.

Thanks in advance and looking forward to your replies,
Regards,

Martin Todorov

Re: Maven locks maven-metadata-local.xml-s and never updates snapshots

[Jason van Zyl <ja...@maven.org>]

Sonatype is still working on packaging and documentation but we have just helped a very large customer with this issue. We had to work fast, so it is in a distribution of Maven built by Sonatype and you can try it here if you like:

http://www.sonatype.com/~jvanzyl/maven/

Some differences between stock Maven and that build:

- concurrent access local Maven repository implementation (for exactly the reason of use on a build server)
- Async HTTP Connector for Aether
  - Resumable downloads
  - All known proxy/SSL/NTML issues resolved
- dynamic extension support
  - Eventing API extension for trapping all behavior in Maven (again for the use in a build server)

Soon to be delivered:
- layered local repository implementation (

Use at your own risk, but a client with a massively parallel build report success with the concurrent local repository implementation. So it should work for you. All elements of that build above will be open source and available in the form of a Git repository in 1-2 weeks. We just have to move a lot faster then the process at Apache allows for. We didn't apply your patch as we believe what we have done is the right way to solve the problem.

On Nov 25, 2010, at 6:00 AM, Martin Todorov wrote:

> Hi,
> 
> I am writing to you concerning
> MNG-4142<http://jira.codehaus.org/browse/MNG-4142>.
> The title of the bug is misleading - it should be "Maven locks
> maven-metadata-local.xml-s and never updates snapshots". This Maven bug has
> been around for quite a while and is preventing us from being able to use a
> distributed build system properly. We use Hudson, and although there is the
> possibility to run each build with a private repository, this is not a
> reasonable solution, if you have a large number of builds (due to the amount
> of space you will need for each node).
> 
> We have been hitting this a lot lately. We have Hudson running with 7-8
> nodes (using different operating systems and Maven 2.2.1).
> 
> The problem can be described as follows:
> - You build a SNAPSHOT module and install it locally. You work on it for a
> few days and commit your code.
> - In the meantime, there are other changes to the module. However, your
> maven-metadata-local.xml contains a line that tells Maven not to update
> snapshots (even with -U, it will not do so). You end up using older
> snapshots locally and the only solution is to remove the artifact's local
> metadata file (or edit it manually).
> 
> When it comes down to regular dependencies, I have written a small plugin
> that works around the issues of locked maven-metadata-local.xml files
> containing localCopy set to true. (Check
> this<https://build-force.googlecode.com/svn/trunk/dependencies-cleaner>for
> more info). However, when it comes down to parents, the situation is
> much more trickier as the projects get loaded and interpolated long before
> the actual build phases start.
> 
> I would like to ask why is the proposed patch not being accepted/reviewed? I
> have confirmed that this bug exists also under Maven 3.0. The proposed patch
> (by David Rousselie) is also applicable to Maven 3, if you copy the five
> lines of changes<http://jira.codehaus.org/secure/attachment/43860/MNG-4142.patch>to
> the DefaultRepositoryMetadataManager.java class.
> 
> Will there be another 2.2.x release in which this could be included? If not,
> could this bug and patch be reviewed for 3.1?
> 
> Writing workaround plugins is not a good idea, and so is using a modified
> Maven in your company. Therefore, I would like to request that this issue be
> fixed in the next version of Maven, as it's quite critical.
> 
> Thanks in advance and looking forward to your replies,
> Regards,
> 
> Martin Todorov

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

the course of true love never did run smooth ...

 -- Shakespeare