I'm in the process of deploying Nexus OSS as internal company repository.
One of the main requirements is that once a jar has been downloaded by Nexus (for example, when using is as a proxy of Maven Central) it will never change.
I know that Maven Central has that policy, but I'm using other repositories which are not under my control, and I have to validate that requirement on my side.
Does a Release repository policy ensures that once a jar is downloaded into that respository, it will never change?
The requirement exists to ensure we can go back to a version of our product created 1.5 years ago, and make sure the repository artifacts used by the product are the same when building it now.
Indeed, a release repository should strictly forbid content modification after a release, which is what Maven Central is doing:
2.2.4. The Central Maven Repository
(...) Here are some
of the properties of release
repositories such as the Central Maven
repository:
...
Release Stability
Once published to the Central Maven
repository, an artifact and the
metadata describing that artifact
never change. This property of release
repositories guarantees that projects
which depend on releases will be
repeatable and stable over time. While
new software artifacts are being
published to central every day, once
an artifact is assigned a release
number on Central, there is a strict
policy against modifying the contents
of a software artifact after a
release.
That being said, whether a Maven client will (re)download an artifact or not does not really depend on the repository and its policy, this is part of Maven DNA and it just won't happen (unless you delete the given artifact from your local repository of course). Quoting Brett Porter in [MNG-2528] - updatePolicy "always" does not work for repositories with "releases", at least not for transitive dependencies:
Releases in Maven are, by definition, unchanging. The always flag is to check for new releases (like it looks for new snapshots), not modifications to the existing one.
In other words, if you don't delete the content of your Nexus repository, Nexus will never re-download a released artifact again and you will thus be able to rebuild the version of your product created two years ago, using the exact same libraries.
Related
I get what internal libraries are. But what is the purpose of a snapshot repository in archiva?
Libraries - private releases
Snapshots - private builds?
I have archiva set up and working with LDAP, but I am wondering why I need a snapshot repository. What purpose does this solve? Why is this used in development?
Also, lets say I update a library in the internal repo. Does this automatically update in the project POM files which use Maven, or I must update those poms to use the new JAR version?
Usually before releasing a maven project, the version is -SNAPSHOT.
So with such repositories you can share fresh SNAPHOT of your project for other people in your team to test or with a ci server.
Snapshots is maven idea to give version number as -SNAPSHOT , its under development it can be change any time.
Internal repository is the release repository with fixed version number. You can modify the SNAPSHOT, but That artifact never changes after it is released.
When we use internal, if dependency does not found inside it, then it will download it from central repository of maven. where as in snapshot it does not.
We are using SVN as a Maven Repositary. We knew that it isn't advisable to have SVN backed maven repository, but still we have to go with it due to limitation within our organization. SVN backed repository used currently is partially implemented.We have developers working from two different geographical location. Problem we face now is whenever a developer adds a artifact to maven repo(svn repository) all other developers have to update the local svn view manually to get the newly added artifact before we do mvn clean package.
IS there a way to automatically download the artifact from svn maven repository to local repo if the artifact doesn't exists locally?
SVN is hosted with a webserver so maven repositary is accessed using HTTPS protocol only. We use maven 2.2 version.
I tried with wagon plugin which would deploy the build output(jar\war) to scm directly. We are not interested in deploying the build outputs. We need a solution to download artifacts automatically from svn maven repo if it isn't exists locally?
You make no mention of how your SVN repository exposes it's artifacts to the development teams. If it truly a Maven repository (conforming to the standard Maven repository layout) then you could just specify it's URL in the "repositories" section of your POM. Updating the local repo would then no longer be necessary.
I suspect that what you have checked into subversion is not a Maven repository layout? You'd lose one of the key benefits of using subversion if each new version of an artifact was being checked in as a new file....
You are describing the functionality offered by any Maven repository manager, for example: Nexus.
I understand your reluctance to embrace a new repository technology, but SCM systems like subversion are primarily designed for tracking changes to textual files.
In conclusion, if you truly wish to keep subversion in the loop I'd suggest one of two options:
Use subversion to control the contents of the local repository. (3rd party dependencies and the artifacts generated by the developers)
Use a repository manager like Nexus. Let Nexus manage cached content from external repositories, but commit the contents of locally hosted repositories into Subversion.
New to Maven.
Ok so I used Maven to package up my project, but one of the files had some test information in it. I would like to change that file but I'm at a standstill as keeping the same version number of the project.
I don't know what to do! Are these my options and what's the best way to do this?
Change the file and do a new build of the project which would increment the build by one.
Example: Build is at 2.0, it would move to 2.0.1 or 2.1
Remove the project from Maven and do a rebuild of the last project but with the new changes.
This is what I want to do but don't know how to remove the project from Maven and reset everything to do a rebuild
Open to suggestions???
Thanks
What exactly do you mean by "remove a project from Maven"? You mean from a public Maven repository?
You should probably bump up the version, as most projects do, when there's an "oops" moment like that. The release notes would ideally state why there's been a new version. Ideally a public notice as well.
Otherwise, you risk people getting the wrong version, or something that they have the fixed version, or whatever. For example, I use the Maven offline option (i.e., -o) pretty regularly so I don't grab the latest snapshots.
I used Maven to package up my project, but one of the files had some test information in it. I would like to change that file but I'm at a standstill as keeping the same version number of the project.
Maven never re-downloads released artifacts with a fixed version (as opposed to a SNAPSHOT version) once they have been downloaded (unless you delete an artifact from your local repository of course but you obviously can't rely on that). This is the only way to guarantee reproducibility (if I rebuild later, I get the same behavior). And in the same spirit, you actually can't re-release an artifact with a fixed version. This is the only way to guarantee consistency (everybody gets the same stuff).
So you'll have to change the version if you want to re-release your project.
Note that if your project is under active development, you should use a SNAPSHOT version. Here is what the Maven: Definitive guide writes about them:
3.3.1.2. SNAPSHOT Versions
Maven versions can contain a string
literal to signify that a project is
currently under active development. If
a version contains the string
“SNAPSHOT,” then Maven will expand
this token to a date and time value
converted to UTC (Coordinated
Universal Time) when you install or
release this component. For example,
if your project has a version of
“1.0-SNAPSHOT” and you deploy this
project’s artifacts to a Maven
repository, Maven would expand this
version to “1.0-20080207-230803-1” if
you were to deploy a release at 11:08
PM on February 7th, 2008 UTC. In other
words, when you deploy a snapshot, you
are not making a release of a software
component; you are releasing a
snapshot of a component at a specific
time.
Why would you use this? SNAPSHOT
versions are used for projects under
active development. If your project
depends on a software component that
is under active development, you can
depend on a SNAPSHOT release, and
Maven will periodically attempt to
download the latest snapshot from a
repository when you run a build.
Similarly, if the next release of your
system is going to have a version
"1.4", your project would have a
version "1.4-SNAPSHOT" until it was
formally released.
As a default setting, Maven will not
check for SNAPSHOT releases on remote
repositories. To depend on SNAPSHOT
releases, users must explicitly enable
the ability to download snapshots
using a repository or pluginRepository
element in the POM.
When releasing a project, you should
resolve all dependencies on SNAPSHOT
versions to dependencies on released
versions. If a project depends on a
SNAPSHOT, it is not stable as the
dependencies may change over time.
Artifacts published to non-snapshot
Maven repositories such as
http://repo1.maven.org/maven2 cannot
depend on SNAPSHOT versions, as
Maven's Super POM has snapshot's
disabled from the Central repository.
SNAPSHOT versions are for development
only.
I have a stable opensource library and was wondering how (and if) I can publish my lib to maven official repositories so people can include it in their pom.xml files and get the dependency downloaded automatically.
The process to get your library in the central repostiory is documented in the Guide to uploading artifacts to the Central Repository. In short, the new process is to get your project hosted by one of the approved Forges that will be synced with central, the Maven folks don't rsync personal repository anymore. In your case, your best bet would be to use the Sonatype Forge (open to any OSS Project). Check the given link (and also this document).
If you want reliable access for everyone out there, you need to stick with central. Due to the tendency of people at dev.java.net to break rules about the immutability of released artifacts, some people don't trust it. Further, it can be Very Slow.
To get your project into central, you need have your code in some public repo that they can sync from.
Central repository
A bit less bureaucratic dev.java.net Maven2 repository - allows completely automatic deployment.
This led on from the question about asking if Apache Maven and IBM Rational ClearCase integrated well. Thought I should write up what I found out - will require various edits, but I shall eventually get round to adding it all I hope.
Environment
ClearCase - Version 7.0.1.2 of ClearCase.
Maven - All of them, from the Maven website.
Hudson - Version 1.307 downloaded straight from the Hudson website
Questions
Does Maven run from a VOB?
I installed all the versions of Maven2 into a VOB 'stacked', i.e. I added Version 2.0 - labelled it, locked the label - then added 2.0.1 on top.
To prevent there being extraneous files, I used the -rnname flag in clearfsimport.
This way, I could simply use a label to specify the version of Maven I wanted access to in my configuration spec, but still keep the same path for the maven executable - /maven/bin/mvn.
Once all the versions were installed, I had no problem running Maven from there via a Dynamic View. Repositories are downloaded from an internal installation of Nexus to the users home directory as normal - and this saves any problems with checking in and out.
A benefit of keeping the tool in source control is that you can set company-wide settings (such as pointing to a internal repository) - then run that single instance of Maven from the VOB on any platform, which retains the settings you originally set!
In Maven projects, I only kept the src directory and the pom.xml in source control, as everything else can be auto-generated afterwards.
Does Hudson work with ClearCase?
I had no problem setting up Hudson to run with ClearCase Dynamic Views. All it took was a symlink from the working directory for Hudson to the root of the view (in this case /view/xxx). The ClearCase plugin successfully ran ct lshistory to find if there had been any changes in the integration branch that developers merge into.
I did write a small script to set-up the initial environment for a job - just the config.xml and dynamic view symlink - so that the correct view was listed in the job and the initial settings were correct. Any enhancements by the users afterwards were then changes to the default template, rather than them setting it up themselves.
In the overall settings of Hudson, I used the $CLEARCASE_VIEW environment variable to set the path to the Maven executable. That way, the version of Maven depended on the version set in the configuration specification - rather than the one they selected within Hudson.
This saves extra administration on both the part of me (the admin) and my users.
What Internal Repository Manager did you use?
I set up Sonatype Nexus to be the Internal Repository Manager - primarily because I read in the Sonatype blog that Hudson was going to get more integrated with Nexus, and we may as well be prepared for new enhancements in the future. I also believed, when I got it set up and tried it, that it was more prepared for a large commercial environment because you could tune the groups within the repository manager to be more flexible - useful for a great number of projects.
I have some Maven repositories outside of ClearCase, for some third-parties libraries referential.
But I have never used Maven with ClearCase since they follow a different logic (Maven needs signed names for files, like myfile-1.2.jar, whereas ClearCase can store only myfile.jar, and record the fact it is version labeled 1.2)
That may have changed with the Maven2 ClearCase plugin reported by romaintaz, but there is still some bugs in this new product, as shown by this thread, when one runs it a second time without unco'ing the pom file. Maven is getting through the checkout fine but is not able to whatever the next step is.
INFO Checking out file: /opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml
INFO ERROR BUILD FAILURE
INFO INFO Unable to enable editing on the POM
Provider message:
The cleartool command failed.
Command output:
cleartool: Error: Element "/opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml" is already checked out to view "my_lf_ss".
I am not using this SCM, but there is a Maven2 plugin called SCM that handles Clearcase.
I had a team building with Maven 2 and using Clearcase as the version control system. We used Archiva as the repository for built artifacts so the development team did not need to use the SCM plugin.
However, the continuous integration server was Continuum and that was relying on the SCM information in the POM. We had problems with the Clearcase SCM grabbing snapshot views using out branching strategy. One of my developers had to tweak the Clearcase SCM code to get it to work with our branches. We both moved on before we got round to contributing his fix.