I was able to build Maven projects from command line with no issue for as long as I can remember.. But this morning, I am getting some error like it's trying to use the company HTTP proxy to fetch dependencies and it requires authentication.
We have internal Nexus repositories, so I reallyt don't get why all of a sudden, it tries to go outside.
I checked my M2_HOM/conf/settings.xml, and no proxy is defined there. I checked my env variables, and I don't see anything declaring a proxy either.
Where can it possibly get configured then ?
Thanks
OK, after couple of hours of struggle, I found the problem.
2 weeks back, I needed to install locally a Logstash plugin that wasn't available internally. This required me to fiddle here and there with my config, to allow Logstash to actually go through the proxy and fetch the required dependency - and it involved Maven, as I used the ugly workaround given here : https://github.com/elastic/logstash/issues/2851
As explained in the link, I defined the proxy for logstash plugin in $HOME/.m2/settings.xml .. and forgot to remove it after ;-/
I found this by running the build in debug mode (-X option) and this file was referenced at the beginning.
Related
Relevant setup information: gradle 4+, relatively new installation of Artifactory (Pro 6+), artifactory gradle plugin version 4+
When attempting to run the build command on a local development environment in both Eclipse Photon and IntelliJ (late 2017 version), I run into dozens and dozens of 403 errors when making a HEAD request for dependencies. But, if I login to Artifactory through a web browser as the user that gradle is using and go to the exact same URL, it has no problem reaching the resource that gradle failed to reach. The problem occurs with every user on Artifactory, even one with admin privileges. The jars I'm looking for are part of a virtual repository with dependencies both internal to the artifactory installation and external. Finally, the build used to work just fine a month ago, and nothing I can think of has changed to permissions.
tl;dr only when logging in from gradle and using Artifactory plugin, a virtual Artifactory repo returns 403 errors on nearly every dependency for every user
This question: Docker pull from artifactory fails with credentials issue seemed close, but is using docker+jenkins (I'm not) and has no answers.
When I finally dug into the system logs, I found many lines like this one: "Rejected artifact download request: User XYZ is not permitted to deploy 'SOME JAR' into 'SOME CACHE JAR'"
It appears that users must have DEPLOY permissions in order to download an artifact that will be cached (behavior of virtuals/remotes.) This may also explain why the build used to work - the cached jars wouldn't have needed updates a month ago when I'd just added the remote and downloaded everything.
Adding deploy permissions to my user for the relevant repositories fixed the issue.
I installed sonar-3.7.2 without issue. I have it working properly with oracle. I can analyze maven-3 projects from a client machine on the same network as the sonarqube server.
The docs says it supports maven-3.x and maven-2.2.x. We are in the process of upgrading projects to maven-3 but many of our projects still use maven-2.0.9. I was hoping that the 2.2.x condition was merely due to what people were testing with and not a real limitation but some newly downloaded poms in my artifactory contain the property maven.min.version set to 2.2.1.
I need a version that will work with maven-2.0.9.
I saw a log from one of my coworkers also trying out sonar and it showed maven-2.0.9 was being used successfully. He is using defaults. I am setting up for production.
The error that I get (cleaned up of course):
Caused by: org.sonar.api.utils.HttpDownloader$HttpException: Fail to download [http://myhost:myport/batch_bootstrap/properties?project=mygroupid:myartifactid]. Response code: 400
I have tried sonar 3.7.2, 3.6.3 and 3.5.1 and get the same error in each case. In each case
analyzing a maven-3 project works (to prove everything else is ok)
I have tried adding the webcontext /sonar instead of just /.
I have tried setting the Server base url in the sonarqube server even though I have not tested anything yet related to sending emails.
I saw something about corruption in the local .m2 on another thread. Removing it did not help either.
Any and all suggestions appreciated.
Best Regards, Gord Cody
I think the documentation is quite clear : http://docs.codehaus.org/display/SONAR/Installing+and+Configuring+Maven
SonarQube supports only Maven 2.2.x and 3.x
But my question is : What's the problem to upgrade from maven 2.0.9 to 2.2.x?
I'm trying to get the netty-codec-hhtp going in my maven project. I have a completely standard Sonatype Nexus set up to proxy requests to Maven Central.
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-codec-http</artifactId>
<version>4.0.9.Final</version>
</dependency>
This fails when building using maven. If I search for it manually in Nexus I find it, but if I go to download the jar it tells me:
404 - Not Found
Automatic routing filter rejected remote request for path /io/netty/netty-codec-http/4.0.9.Final/netty-codec-http-4.0.9.Final.jar from M2Repository(id=central)
What does this even mean, why am I getting it, and maybe more importantly, how do I fix it?
I am using Nexus 2.5.0-04 with Maven 3.0.4
Downloading other artifacts seems to work just fine.
UPDATE: This turned out to be an issue with CDN configuration that should now be resolved. The steps below for forcing and/or disabling remote discovery are left for reference.
It means that Automatic Routing for Central is active, and that the discovered rules does not contain io.jetty as allowed prefix.
This should not happen, as the default configuration should update the rules on daily basis (as seen on screenshot below, showing the default Automatic Routing configuration for Central).
The remedy is to either force the update of rules (I did check, prefix /io is among rules Central publishes), or disable remote discovery completely.
Try steps as shown below on screenshot:
From Repository Management with Nexus - 6.4. Managing Routing:
Routing can be considered the internal activities Nexus perform in order to determine, where to look for a specific component in a Maven repository. The routing information has an impact on the performance of component retrieval as well as determining the availability of components.
(...) Automatic Routing is handled by Nexus on a per repository basis.(...)The Routing information consists of the top two levels of the directory structure of the repository and is stored in a prefixes.txt file. It allows Nexus to automatically route only component requests with the corresponding groupId values to a repository to avoid unnecessary index or even remote repository access.
Since Maven central repo contains that artifact I assume that the automatic routing rules forbids remote download for that artifact. The error message you posted suggests it also.
You can read how to add a routing rule under 6.4.2. Manual Routing Configuration. If my assumption is correct, this situation shoud be resolved by adding an inclusive rule type with ^/io/netty/.* route for central repo.
I faced the same issue when configuring a bridge between 2 Nexus.
In the first:
I added 2 proxy repo, targeting 2 public repo groups in the second,
then aggregate those 2 proxy repos in a new group,
that I finally added to the repo list of the first Nexus public repo group
Using the first Nexus, each time I requested a dependency only present in the 2nd, I encountered the Automatic routing filter rejected remote request for path... exception.
As mentionned by Tamas, this issue comes from the Routing >> Discovery feature that was enabled in my 2 proxy repos, that were targeting remote Nexus repository groups.
Once disabled, the issue was solved.
The exact explanation of this need is in some way explained in the official Sonatype documentation for Repository Management with Nexus, in chapter 6.4.1 on Automatic Routing:
The Routing tab for a proxy repository displayed in Figure 6.18,
“Automatic Routing for a Proxy Repository” contains the Discovery
section. It displays the Status and a more detailed Message about the
prefix file access. The Last run field displays the date and time of
the last execution of the prefix file discovery. Such an execution can
be triggered by pressing the Update now button. Otherwise, the Update
Interval allows you to trigger a new discovery every one, two, three,
six, nine or twelve hours or as a daily or weekly execution.
[...]
For a proxy repository, the prefix file is either downloaded from the
remote repository or a generation is attempted by scraping the remote
repository. This generation is not attempted for remote Nexus
repository groups, since they are too dynamic in nature and should not
be proxied directly. Scraping of hosted or proxy repositories as well
as Subversion-based repositories is supported.
Regards,
Thomas
I have an instance of Artifactory installed locally. Within the instance, I am able to create references to other remote repositories.
Now, I have another instance of Artifactory, which exposes its own repository: .../remoteArtifactory/repo
I am trying to point to this repo in the first instance of Artifactory.
But in doing so, I have:
Connection failed with exception: Circular redirect to
".../remoteArtifactory/repo"
What am I doing wrong here?
I had exactly the same problem as you, and fixed it by completely ignoring that error message and saving the repository. To reiterate:
Ensure you have the correct path to the remote repository, eg: http://host:8080/artifactory/libs-release-local/
Click Test, and you'll get the Connection failed with exception: Circular redirect to - Ignore this!
Click Save
Note: different versions of Artifactory have slightly different paths/URLs. This caused me a little grief.
Remote Repository Settings
I guess it's worth mentioning that I needed to specify the local proxy server (TdmsProxy).
Also, to confirm that you've got the correct path to the remote instance, check that you can receive a POM via the browser (or wget) from it, eg:
http://your-remote-repo:8080/artifactory/libs-releases-local/com/company/area/project/version/project-version.pom
Once, you've received the POM, just use the first part of the URL, eg:
http://your-remote-repo:8080/artifactory/libs-releases-local/
(I realise you've probably checked your path at least 10 times, but this bit me!)
Rather than having teamcity log onto the gitolite server several tens of thousands of times each day - and also sitting around waiting for the poll to happen (or starting it manually).
It would be nice if it was possible to set it up gitolite hooks that inform TeamCity that the repository has changed.
Is such a configuration possible with TeamCity and gitolite?
I know Jenkins has a github plugin that works nicely - I use that setup for some Minecraft CI I am running privately.
One way would be to gitolite (through a VREF hook) to call TeamCity through its REST API, in order to launch a build through web request.
You just need to make web request to the following URL:
http://YOURSERVER/httpAuth/action.html?add2Queue=btId
, where btId is build type Id – unique identifier for each build configuration.
To get it, you can just look for it in browser address bar, when clicking on build configuration, or use TeamCity REST API for details.
The OP Morten Nilsen didn't need a VREF:
add a file "post-receive" to .gitolite/hooks/common and
run gitolite setup --hooks-only