Make Maven Proxy/Server settings configurable based on location? - maven-2

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"

Related

Weblogic run configuration in IntelliJ idea - disable basic authentication

I need to disable basic auth on weblogic server, which can be done by adding <enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials> into config.xml in a weblogic domain.
I'm deploying a web service to weblogic directly from IntelliJ Idea and every time I start deploy, the config.xml is replaced by a new one, so I cannot change config manually. I guess I need to pass some extra arguments in IntelliJ's run configuration. Does anyone has any experiences with this?
It was my mistake. I tried to modify config.xml and forgot my server is still running. According to this page I think it's pretty obvious why this happens. So, it has nothing to do with IntelliJ Idea.
Caution: Do not edit configuration files for a domain that is
currently running. Because Oracle WebLogic Server rewrites the files
periodically, your changes will be lost. Depending on your platform,
you also could cause Oracle WebLogic Server failures.

How to run app from root url (localhost:port/) instead of (localhost:port/path/index.html)

This is a problem that I have when I run/debug the app from Webstorm.
The run/debug configuration dialog doesn't give us much to work with, we can just specify the path of the index.html file there.
I wanna be able to set up a configuration similar to what yeoman's angular generator gives us out of the box.
WebStorm built-in web server serves the project from 'http://localhost:<built-in server port>/<project root>'. If you like to change the default web path on built-in web server, you have to re-configure the server by editing your system hosts file accordingly - see http://youtrack.jetbrains.com/issue/WEB-8988#comment=27-577559. But, as it's mentioned in this comment, there are currently some issues with serving dart apps on server configured this way.
Please follow WEB-14047 for updates

Apache Archiva 2.1.1 Upgrade: Proxy does not work

we try to upgrade from archvia 1.3.6 to 2.1.1 but suddenly the remote repositories (including proxy connectors) stopped working. The remote repository view shows error marks in the column "Remote check" but no error message is shown.
Is there a possibility to find out what is going on?
We are using a proxy, we tried with proxy activated, deactivated. I even installed archiva locally on my machine with a fresh database, but still no success.
(how does this remote check even work when the proxy is activated/deactivated in the proxy connectors?)
Eclipse (with newest m2e) says Missing artifact junit:junit:jar:3.8.9. It goes so fast, that i don't think archiva is trying to reach the central-Repository.
The logs on archiva-side are empty.
Does anybody have some hints or the same problem? I think i will try it at home tonight, to see if it is a network issue.
Thanks in advance for any tips!
Update
It really seems that the proxy connector does not work since the internal Repository is empty. http://localhost:8080/archiva/repository/internal/ only shows .indexer
Update 2
The proxy configuration seems bugged in Archiva 2.1.1. I can see the same behaviour as here: Mailing List
A JIRA task for this would be nice.
Does anybody know a workaround to set the proxy for a proxy connector? Or is there a possibility to set a global proxy via a settings file?
Update 3
Rellay seems like a bug in archiva. I sent a mail to the mailing lists. Hopefully this is getting fixed soon because this is a blocker for every user with a proxy.
I won't delete this question for documentation if someone has the same problem. The issue can be found in JIRA here
I also had this problem and the simple solution was to change the proxy protocol from "http" to "https".
I also had the same problem. On first glance the solution given by Christian Quast seemed to work, but it didn't solve the problem. I eventually used a work around by using JVM proxy settings:
-Dhttp.proxyHost=[your_proxy_address]
-Dhttp.proxyPort=[your_proxy_port]
-Dhttp.proxyUser=[your_proxy_user_name]
-Dhttp.proxyPassword=[your_proxy_user_password]
-Dhttp.nonProxyHosts=localhost|127.0.0.1|::0|[any_other_hosts_not_to_use_proxy]
Update
I know it may sound weird but, using the settings above, the error/warning icon on "Remote Check" may still appear. If you add the "network proxy" (mine is using https protocol) to your remote repository (the error/warning icon is still there) but editing the remote repository again and removing it's "network proxy" will show the OK/sun icon.
In my case <networkProxy> under conf\settings.xml gets updated correctly including the port information (probably because my port is not a default 8080) but remote repository connection is still failing.
Also, changing proxy protocol to https did not help.
I know the proxy is right because I use the same for maven .m2\settings.xml
Fortunately I am only evaluating open source repo management tools. Started with Archiva as it is by Apache and we use Maven in our project. Would have moved ahead if this critical issue had a fix or work around. Guess I will have to take a shot at Nexus.
Exactly same problem here. I can't vote on your BUG report because I have no jira account.
As far as I figured out there seems to be a problem with the configuration file ~/.m2/archiva.xml. The Proxy is set without port information.
Hopefully this bug will be fixed as soon as possible.
Extending João Ferreira's reply, to access repositories with https URLs (such as Maven Central), you will also need:
-Dhttps.proxyHost=[your_proxy_host]
-Dhttps.proxyPort=[your_proxy_port]

Apache Ivy: Where do I put all these JARs?

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.

Should I use an FTP server as a maven host?

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.