We are using gradle to publish locally and remote (nexus) to a snapshot repository (using the 'maven-publish' plugin). When I make a local build, I would like to use the latest snapshot version either from my local repository or the remote one. Now when gradle finds one locally the remote one is not considered anymore.
Is there a way to configure this or should I use other plugins?
Unfortunately, Gradle doesn't (as of 1.10) support getting the latest snapshot across multiple repositories. In Maven, this works (only) because the local Maven repo is treated specially, and a snapshot found there won't terminate the search.
Related
I have Maven2 project. This project have 1 internal dependency which stored in internal (for our company) Sonatype Nexus. I setup the dependency version in pom.xml as parameter which I provide via Jenkins.
Sometimes I do not have proper dependency version in Nexus so my build can fail on donwload dependency step. I want to add ability to trigger special task (script) if dependency is not found to upload this dependency into Nexus and continue the build.
Can I do so?
I think about fake build for version exists always in Nexus which will check if given version is in Nexus, upload it and launch real build. But such way looks terrible.
Thanks In Advance!
You do NOT need to upload anything. You just need to access Nexus via the public group and the download from the Central repository, that is part of that group will happen automatically.
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.
I think there should be some difference, but can anyone tell me the details?
mvn:install copies your packaged Maven module to your local repository (by default, in ~/.m2/repository), to be accessed by other local Maven builds.
mvn:deploy uploads your packaged Maven module to another (usually remote) repository, to be accessed by other, not necessarily local, Maven builds.
See the documentation for the build lifecycle for more info.
The install phase is responsible for the installation of artifacts into local caching repositories. This basically applies to the Maven repository, but a well-known example is also the OSGi Bundle Repository supported by maven-bundle-plugin.
The deploy phase is responsible for the installation of artifacts into published repositories. This usually applies to remote repositories, but is could perfectly be a local repository exposed to the outside world.
As all Maven phases, you can do with them anything you want. You can shuffle plugin phases as you see fit, but the above semantics is the conventional one and you should stick to it in order to be consistent with the default phases of other plugins' goals.
mvn:deploy performs deployment to remote reposiory/environment, mvn:install installs all compiled packages to a local repository making them available to other builds performed on the local machine.
In one sentence: mvn:install compiles and installs your component in your local Maven repository, so that you can use it when other components used and developed locally depend on it. mvn:deploy deploys your (previously installed) component to a remote repository.
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.
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.