As a consultant, I have multiple clients that I'm doing work for. Each client utilizes their own internal Maven repository that is also set up to mirror Central and other external repositories. I need to configure my maven installation on my laptop so that when I'm doing work for one client, it utilizes their internal repository for everything.
I had thought I would be able to utilize profiles to handle this, but mirror settings cannot be changed per-profile.
Does anybody have suggestions on how to approach this maven configuration?
Note: A similar question is here: How do I configure maven to access maven central if nexus server is down?, but that question deals with switching between Central coming from a mirror or not. What I need is for Central (and others) to come from one mirror or a different one based on some property/setting/variable etc.
Create two shell aliases:
alias build_at_home="mvn -s $HOME/.m2/home_settings.xml"
alias build_at_work="mvn -s $HOME/.m2/work_settings.xml"
The "-s" option is handy for explicitly stating which environment settings file to use.
We use this mechanism on our shared build server to ensure each project build is isolated.
Obviously on windows you could create a set of batch files.
I have a very similar requirement in my project too. I created two separate settings.xml files, named them as settings_one.xml and settings_two.xml and saved them in the MAVEN_HOME. Depending on which file I need, I have a small script (a bat file on windows) which overwrites the existing settings.xml with one of the two settings files.
del C:\Users\<username>\.m2\settings.xml
copy C:\Users\<username>\.m2\settings_one.xml C:\Users\tadigotl\.m2\settings.xml
The simplest solution i can suggest is to install git and commit you .m2/settings.xml (of course ignore the repository itself via .gitignore) into git and make appropriate branches for the customers. Change the settings will be done by:
git checkout CUSTOMER_BRANCH
and furthermore any change is tracked by a SCM.
Related
We are developing offline due to limited internet resources and would like to run once every several months a whole grab of an external repository (e.g repo1.maven.org/maven2 - Disk space isn't an issue).
Today I'm using a simple POM that contains a lot of common dependencies that we are using, I've set my local maven to use a mirror to proxy thru a local nexus repository to cache locally and this is how I'm grabbing for offline use - but that isn't very effective.
I'm now looking for a command line tool that allow me to run searches on maven repositories so that I can write a script that grab them all to my local nexus installation and would like to hear if there is any or if there is another way to achieve that.
Thanks
Not a whole solution (yet) but I'm using httrack to grab the whole content of repo1.maven.org/maven2 - That is already better than nothing :)
In general, there is a goal in Maven dependency plugin called "go-offline"
So it allows to grab all the project dependencies and to store them in local .m2 repo.
You can find more information here.
If you want to run Maven and tell it to behave like the network does not exist you can run it with "-o" option (offline mode). So that if there is no dependency installed locally, Maven won't even try to go to network and bring it - but will fail the build.
On the opposite, if you want to force Maven to check and bring new versions (otherwise they already should be in your repo), you can use "-U" option.
I'm not really sure I've got the point about general search-and-download use case. Usually people install Nexus or Artifactory once in a network so that each dependency will be downloaded only once. In local development machines people usually just work with filesystem and don't maintain tools like this.
Now if you want to copy the whole repository from internet (for copying it later to some other network or something) you can just use crawlers like Apache Nutch for example or craft your own script that will recursively download all the files.
In the infrastructure I've inherited, the guys use jenkins and maven to construct jars and config files.
So, jenkins checks out some code, then maven builds something. Jenkins post build task then copies files from mavens target directory and copies them to a "build share" (eeks), for example
Source
**/target/*.jar
Destination
releases/env_name/project/lib
Source
**/target/classes/some-service.xml
Destination
releases/env_name/project/conf
I dare say this is not ideal.
In the new provisioning project, the jars from the build, are deployed into Nexus. In turn, I then use the maven rpm plugin to build RPMs using GAVs to identify which jars are packaged. I haven't captured the config files.
Could I publish the config files to Nexus? Yes they're small, but still artifacts. They would also have a maven snapshot or release coordinate, which could fit in with my releases. I have not tried, but I imagine I can add a section to my existing RPM build pom so that the desired plain text files are uploaded to Nexus when I run mvn deploy.
Some of the files require modification post deployment to suit an environment - this adds further head ache to this.
The poms that define the RPMs will also grow significantly in length. Not a problem per se, if I can ascertain this is the right way.
The question: How have others managed jars and config files deployment in a multi-environment set up?
Since you are asking how others have done it, I will say how I do, which may or may not be appropriate in your situation.
The binaries (.jar or whatnot) are build by Jenkins from the source code in SVN.
The SVN source code has configuration files, but most of the time, those are configured for DEV or Local environments. I let them have it there so that developers' local builds can be simple, but really as far as I am concerned they don't exist.
The SVN also has a separate location (not accessible by DEV, only by Release Managers and Systems teams), and this location contains configuration files for all environments (including DEV environment, when deployed from the CI server)
Since we have a lot of environment specific settings, it makes sense to keep separate copies of each environment.
If a new configuration parameter is added, it is merged from DEV config files all the way to PROD, just like other source code changes are merged, with the exception that only RM or Systems team can do it.
The deployment process (in our case a shell script, but could be anything) takes care of pulling the correct configuration files from SVN and pushing them, along with binaries, to the remote server. Once server is deployed, the "in-jar" configuration is wholly replaced by the configuration files that came from SVN.
I organize the configuration file by ENV, then by TYPE, for example: QA/WEB, QA/API and then PROD/WEB, PROD/API. So I don't have to maintain configuration files for each remote machine.
However there are times when configuration is specific to the remote machine, such as an IP address of the machine. In these cases, the SVN configuration file contains a token, like [local_ip]. When the deployment script pushes this file to remote server, it then knows to replace the token with real IP of the remote machine
I face a problem, common I guess.
I have a project which is store in github.
I need it to run for: production, testing and different developers.
The project uses maven profiles to set some parameters.
The project has also a spring profile: currently only DEV which initialize a DB.
The project uses external software with specfic configuration files.
I need to have the project in production but being able to serve development versions.
The question: can I use git ignore locally within developers to distribute the code and still store the files in github?
Or would you have a different solution?
The actual question is:
Can I use git ignore locally for some configuration files and still have the files on the main repository? Updated by only the production users?
One way is to store:
one different configuration file per environment
one template file
one script able to detect the current environment the git repo is cloned in, and generate the actual configuration file (which isn't versioned) used for that local environment.
That generation can be automated on checkout, with a smudge script declared as a content filter driver.
The way we have solved this is with a configuration script that pulls the server-appropriate credential file for local, staging, or production from a separate repository.
After each server pulls the appropriate file, we rename it for consistency across the different environments, and then we have our settings file which is tracked by git include the credentials file.
This question already has answers here:
Maven Mirror - how to bypass if mirror host is not available?
(3 answers)
Closed 8 years ago.
At my job we use a nexus server that requires credentials. it is also only available through our network (or VPN). I was provided with a maven settings.xml for this purpose.
I also want to have a more conventional configuration for some side projects of mine, because using the same configuration is very inconvenient, but Im not sure of how to switch configurations without replacing the whole settings.xml every time.
The settings is basically taken from this example but with a entry for credentials. How can I turn off this config and connect to the central maven repo when I'm at home?
well, you seem not to be the first one facing the problem. I've found some discussion on this here: http://maven.40175.n5.nabble.com/Conveniently-switch-between-settings-td126255.html
However I don't think there is fully flexible/automatic solution the one would expect.
As a summary of the discussion, I see 2 options:
switch the settings.xml based on your environment or
use the -s switch for mvn command to specify the alternate settings.xml file
My experience is that, switching settings.xml based on environment (the 1.st option) does the job for me.
All you need is define 2 profiles in your settings XML - one should use the intranet-only repositories, the other - open internet repositories (e.g. Bintray's JCenter).
Then define one of the profiles active by default, and trigger the usage of the other with -p (and disabling the auto-activated with !)
Here's the full profiles reference for you.
There is a project that uses CVSNT/WinCVS for Version Control. This is the central repository. Locally checked out folders contain hidden sub-folder called "CVS".
I tried to install CVSNT server locally and use second instance of WinCVS to manage(version control) local temporary changes before committing to the central repository.
But that is not working because when checking out from the second(local) repository it still uses "CVS" sub-folder name for its working files.
Anybody knows if it is possible to configure CVSNT server and/or Client to use different name for this sub-folder? And if yes, how?
So far I'm using TortoiseSVN. It creates folders too, but they called ".svn" so there is no interference. It is integrated in Windows shell, which I don't like.
A sandbox is tied to a given repository (which is regitered in one of the files in the hidden CVS folders). You can't use the same sandbox to commit locally and remote (are you tring to mimic a DVCS? Use one of them if you need them). You can't change the folder name (but changing the CVS source files...), but beware WInCVS use them as well because they contains informations about the files status.
You have two options:
The CVS way: create your own development branch, commit to that, merge with the main branch when your code is ready. Of course the CVS server has to be reachable all the time.
The DIY way: create two sandbox, one from the local repository, one from the remote one, move files between them as you need. This is a more error prone way, IMHO.
Of course you can try to use two different VCS, but you will end up with a lot of headaches then. Better to use Git, Mercurial or the like that do what you need without any special configuration.