I would like to host a Maven repository for a framework we're working on and its dependencies. Can I just deploy my artifacts to my FTP host using mvn deploy, or should I manually deploy and/or setup some things before being able to deploy artifacts? I only have FTP access to server I want to host the Maven repo on.
The online repository I want to use is not hosted by myself. As I say, I only have FTP access, so if possible, I would like to use that FTP space as a Maven repository. The tools mentioned seem to work when you have full control over the host machine, or at least more than just FTP access since you need to configure the local directories where the repositories will be placed. Is this possible?
You might want to have a look at Nexus, a Maven repository manager. We've replaced our local Maven repository with a Nexus-based one and find it tremendously useful.
I've successfully used Archiva as my repository for several years ... see http://archiva.apache.org/. It's easy to administer and allows you to configure as many repositories as you need (SNAPSHOT, internal, external, etc).
According to the book "Better Builds with Maven", the most common type of repository is HTTP, this paragraph describes what I think you need:
This chapter will assume the repositories are running from http://localhost:8081/ and that artifacts are deployed to the repositories using the file system. However, it is possible to use a repository on another server with any combination of supported protocols including http, ftp, scp, sftp and more. For more information, refer to Chapter 3.
A Maven 2 repository is simply a specific directory structure, so once you get the transport and server specifications right for the repository and deployment portion of your POMs, it should be completely transparent to your users.
You can even use Dropbox. All that you need is a public address to access the files generated with mvn deploy, with any of the protocols in the accepted answer.
I guess there are more services that can work in the same way, but I'm not certain about the URL schemes that alternatives to Dropbox may use.
https://maven.apache.org/wagon/wagon-providers/wagon-ftp/ will tell you that you can use ftp to read from an existing repository, but not to create a new one. I don't think that it is impossible in principle, but no one has cared to write all the fiddly code to do the directory management via ftp.
Related
Using Spring Integration file:outbound-channel-adapter, is there a way to specify what user account to use when writing the file. We need to write files from one domain to another. We would like to be able to write them just using file shares, but to do this, we need to be able to log in to the remote box with an account in the remote domain.
We can get around this with FTP, but would like to use file writing.
Thanks
I assume you are talking about windows domains/shares.
There are SMB adapters in the Spring Integration Extensions repository.
It includes a sample configuration file.
You can build it from github or there's a snapshot in the spring snapshot repo.
I'm trying to convince the higher-ups at my work place to migrate to Apache Ivy. I've managed to get a few sandbox projects working using Ivy to power the build, and now I have a greenlight to put together a migration proposal.
We all agree on one thing: we don't want to trust JARs that are located in public directories! I know, I know, a bit paranoid, yes. But we'd like to have a setup where we pull a JAR from a trusted source (either downloading it from the open source project itself, or most likely, gulp, a public repo), and use it for some time before we "certify" it (give it our blessing as a safe artifact to use).
Then we want to have a common repository for all JARs used by our many projects.
My original thinking was to place this repository up in version control (we have an SVN server). But I wasn't sure what best practices dictate. It might make more sense to put our JARs on a file server and FTP to them in the Ivy script.
Either way, SVN (HTTPS) or FTP, all of our servers are authenticated. So, a small number of questions:
Where should we be publishing all of our "certified" JARs (everything from `log4j` to any homegrown JARs we produce)? What do best practices dictate?
The "ivyrep" resolver-type does not take username or passwd atrributes. If our "JAR server" (FTP, SVN, etc.) is authenticated, how do I configure the Ivy scripts to login?
I must echo Brian's recommendation to use a repository manager like Nexus. It's a lot less work in the long run. You'll also discover that the professional version of Nexus enables you to create approval processes around repositories which you plan to use in your build. See the procurement suite functionality.
If, on the other hand, you are determined to build your own repository, then ivy has the tools for the job. You need to become very familiar with the ivy settings file and how it declares and uses resolvers.
If repository is accessible via HTTPS the the url resolver should be able to access it. The resolver will assume that each version of an artifact is in a different directory and you'll need to specify the URL pattern that ivy will need to use when accessing the repository:
<url name="two-patterns-example">
<ivy pattern="http://ivyrep.mycompany.com/[module]/[revision]/ivy-[revision].xml" />
<artifact pattern="http://ivyrep.mycompany.com/[module]/[revision]/[artifact]-[revision].[ext]" />
</url>
The pattern is fully flexible to how you store the artifacts.
Authentication is also handled in the settings file using the credentials tag.
Finally, the FTP protocol is also supported. It's hard to find in the doco, but it's supported by the vfs resolver.
I think that's enough information on an option I don't recommend :-) Having said that I once created an FTP based repository for managing releases to clients. It's useful to have a tool this powerful :-)
Why not use something like Sonatype's Nexus. I've seen it used for Maven, and I believe it'll work for Ivy.
You can set it up to download from remote repositories into (say) a 'test' repository. You can then evaluate those .jars, and if they're good, upload them into an 'approved' repository for general consumption. There's some authentication surrounding this, but you'd have to evaluate that in greater depth. Certainly you can restrict the uploading into repositories via a username/password pair.
Is there any simple way,which is provided by maven itself, to open my local repo as a remote one for other users?(How cool it would be;) )
Or should I install an ftp server or apache to do it?
This is not straightforward. What you are looking to do is to set up a mirror of the repositories to be used by other users. You will be better of setting up one of the repository managers to do this.
I think this was supposed to be a simple task, but I've been unable to accomplish it.
I've set an archiva repository as this:
2 Internal Maven1 repos (old projects)
1 Internal Maven2 repo
7 Remote repos (central, java.net, jboss.org, etc.)
For each internal repo I've created a proxy connection with each remote repo.
I've added a new mirror to my settings.xml file as explained in the archiva documentation:
<mirror>
<id>archiva.default</id>
<url>http://repo.mycompany.com:8080/archiva/repository/internal/</url>
<mirrorOf>*</mirrorOf>
</mirror>
When I try building a simple project with one dependency from some of the remote repositories, no artifacts are downloaded. Why?!?
Thanks for any help.
Archiva doesn't assign repositories any special roles. You make requests to specific managed repository from Maven (so from your settings, internal), and it will serve what is in there, or proxy it from remote repositories that have been connected by a proxy connector. By default, that is just Central - adding a new remote repository has no effect until it is connected to a managed repository by a proxy connector.
What you probably want to do is add a proxy connector on the internal repo to the remote repositories in question. Consider setting the whitelist too so that it is more effecient.
You may also want to set up a repository group that spans all the managed repositories (both maven 1 and maven 2) for use from a single URL.
I had exactly the same problem with Archiva 2, for me the solution was to give the "Global Repository Observer" role to the Guest user.
So I'm not sure what the best way to accomplish this is, but basically I have a laptop that I use at work for Maven projects. It works fine when I'm at work, but as soon as I walk out of the door of their corporate proxy and maven server, I often have to do alot of hand-fudging of the settings.xml file when I'm at home if I'm not VPN'ed in:
We have a corporate-installed Maven Repository proxy server to store some of our own artifacts and handle being the middle-man for our commonly used artifacts.
We have an http proxy that we use for connecting to the outside world.
Both configurations have been handled by my settings.xml file for setting a single Nexus group and maven proxies. If I'm not connected to the VPN while away from the office, I have to muck around with the settings.xml each time I'm not on it, then switch it back when I am on it.
What solutions have anyone else found to handle this? I've been trying profiles to manage the proxy, but I can't seem to get it to work correctly, and it's starting to look pretty ugly. Are there some settings configurations that can detect when I'm not behind the proxy at work and not use the corporate proxy server or Maven server?
While I can think of some profile based solution to handle the proxy (basically, reading the <active> value from a property defined in a profile), this wouldn't be fully automated (the profile activation do not support network based stuff) unless you can find a file that is present or not depending on your location (in which case, you could use an existing/missing file trigger but this is kinda hacky). Anyway, this would solve only one part of the problem because mirrors can't be declared in profiles (see MNG-3525).
So, instead of trying to control this with a profile, my suggestion would be to use two settings.xml and to pass your settings-home.xml file with the -s command line option when you're at home.
Another option would be to automate the changes in your settings.xml with a script (Groovy would be a good choice as someone reported in MNG-3525).
I found a use environment variables to set nonProxyHosts together with proxy and noproxy shell aliases to be the most convenient solution when switching between networks with proxy and without it.
In settings.xml, configure proxy with
<host>proxy.corporation.int</host>
<port>8080</port>
<nonProxyHosts>${env.MAVEN_NONPROXY}</nonProxyHosts>
Then in ~/.profile set
export MAVEN_NONPROXY_PROXY='*.corporation.int|local.net|some.host.com'
export MAVEN_NONPROXY_NOPROXY='*'
alias proxy="export MAVEN_NONPROXY=\"$MAVEN_NONPROXY_PROXY\" && export all_proxy=http://proxy.corporation.int:8080"
alias noproxy="export MAVEN_NONPROXY=\"$MAVEN_NONPROXY_NOPROXY\" && unset all_proxy"
To do the switch when roaming, you would just execute from a shell:
[me#linuxbox me]$ proxy
or
[me#linuxbox me]$ noproxy
Obviously, both aliases proxy and noproxy can include much more changes than just setup of MAVEN_NOPROXY and all_proxy.
I was frustrated by the same problem: having to manually edit settings.xml when roaming between networks. So much in fact, that I wrote a Maven plugin that enables automatic discovery of proxy settings. The current implementation uses the proxy-vole library written by Bernd Rosstauscher to detect proxy settings based on OS configuration, browser, and environment settings.
I've just released the source code of the plugin on Github, under an Apache 2.0 license: https://github.com/volkertb/autoproxy-maven-plugin
You're welcome to give it a try and to see if it meets your needs. Any feedback or contributions are welcome!
(Note: you don't necessarily have to add the plugin to your project's POM. You can invoke it from the command line as well, after you've installed it. See the README on the site for more details.)
You can set MAVEN_OPTS when you need to activate a proxy:
export MAVEN_OPTS="-Dhttp.proxyHost=my-proxy-server -Dhttp.proxyPort=80 -Dhttp.nonProxyHosts=*.my.org -Dhttps.proxyHost=my-proxy-server -Dhttps.proxyPort=80 -Dhttps.nonProxyHosts=*.my.org"