In Maven 1.x the repositories were simple - there wasn't a difference between a local repository and a remote repository. The layouts were the same and there wasn't additional information in one that wasn't contained in the other. The only variant was where the repository was located.
In Maven 2.x that all changed. With the addition of transitive dependencies everything got a little more complicated. I will attempt to explain...
A remote repository, and local for that matter, contain a few more files. The obligatory jars are still there, as are deployed poms. The additional files come in the way of metadata and their checksums.
Each artifact has at it's root level (i.e. not by version) a maven-metadata.xml file (on the server) or multiple maven-${serverId}-metadata.xml files that contain all the releases of the artifact, as well as the latest and released versions and it's deployed timestamp (on the remote) or it's downloaded timestamp (on the local).
These files are used for a couple of things. The first is to allow maven to check for updates based on time. If you have repositories in your settings.xml or POM that allow updates (daily for example) Maven will check these timestamps and compare local versus remote to determine if a download is required. The second use is that of when a dependency is declared without a version. Maven will first check the local repository and it's metadata to determine what the latest version of the artifact is and download if necessary.
This poses a small problem when trying to create an enterprise remote repository that doesn't allow access to the internet at large. These metadata files need to be mantained by hand (or by an automated process) outside of the realm of Maven's dependency management.
Why can't you copy a local repository to the remote? You can, but it won't work for these dynamic version checks. The problem is that the metadata files are renamed to that of the server id from where a particular version was downloaded. There can be several, depending on the artifact, so you can't just rename the file back to what Maven is expecting to find.
I'm checking into a couple of options. The first I've implemented as a stopgap - a basic wget script that can download the artifact's complete directory structure. It works, but it's clunky and doesn't automatically handle transtitive dependency downloads. The second tool I'm going to testdrive is Archiva
Check back to see the results...
Technorati Tags: maven, build management
In Maven 2.x that all changed. With the addition of transitive dependencies everything got a little more complicated. I will attempt to explain...
A remote repository, and local for that matter, contain a few more files. The obligatory jars are still there, as are deployed poms. The additional files come in the way of metadata and their checksums.
Each artifact has at it's root level (i.e. not by version) a maven-metadata.xml file (on the server) or multiple maven-${serverId}-metadata.xml files that contain all the releases of the artifact, as well as the latest and released versions and it's deployed timestamp (on the remote) or it's downloaded timestamp (on the local).
These files are used for a couple of things. The first is to allow maven to check for updates based on time. If you have repositories in your settings.xml or POM that allow updates (daily for example) Maven will check these timestamps and compare local versus remote to determine if a download is required. The second use is that of when a dependency is declared without a version. Maven will first check the local repository and it's metadata to determine what the latest version of the artifact is and download if necessary.
This poses a small problem when trying to create an enterprise remote repository that doesn't allow access to the internet at large. These metadata files need to be mantained by hand (or by an automated process) outside of the realm of Maven's dependency management.
Why can't you copy a local repository to the remote? You can, but it won't work for these dynamic version checks. The problem is that the metadata files are renamed to that of the server id from where a particular version was downloaded. There can be several, depending on the artifact, so you can't just rename the file back to what Maven is expecting to find.
I'm checking into a couple of options. The first I've implemented as a stopgap - a basic wget script that can download the artifact's complete directory structure. It works, but it's clunky and doesn't automatically handle transtitive dependency downloads. The second tool I'm going to testdrive is Archiva
Check back to see the results...
Technorati Tags: maven, build management
No comments:
Post a Comment