Last year I got virtual server for my server needs, configuration is not great, but things work without problem... Few months ago I installed Nexus Repository manager and after that I have daily problem with tomcat... I now restart machine every night, but still it seems that nexus is unavailable most of time.
I am working on OS project and we need to have repository manager (RM) available to host all our stuff and also all libraries our project needs...
I have currently 3 options (how to solve this problem):
Downgrading maven version to 1.6 (or at least some that is stable and doesn't need so much resources)
Using artifactory (their package seems to be the same size as nexus, but I don't know if it will be better - resource wise)
Using archiva (no idea how stable this is and how good it is)
I am thinking about going with option 3, I just don't know if this is right solution. I am sure some of you have your own RM running, what would you recommend? Do you have perhaps any other options? If I use option 1, which version would you recomend...
Thanks in advance,
Andy
By "downgrading Maven version to 1.6" I assume you're referring to the Java version, as if you're using such an old Nexus, then it doesn't shock me that you're having problems. Upgrade your Java to 1.7.x, as well as your Nexus to the latest one.
Archiva and Artifactory are always options, but I don't think the problem is in Nexus itself, but rather your setup (and you haven't mentioned anything about it).
What version of Java, Nexus, Tomcat are you using?
Also, by "OS project", I assume you mean "OSS" (open source) project. If so, you can use Sonatype's OSS hosting. I've described how to set up an OSS project (using Github, BuildHive and Maven Central) here. You can also just skip to using Maven Central directly, checking here. I think this would be a better option for you, if you're not familiar enough with managing your own repository manager.
I would suggest to run Nexus with the native jetty as supplied by the default download bundle instead of on tomcat. This will give you better performance and also better support.
Of course if you can get all libraries into the Central Repository via OSSRH it would be even easier since you could get by without maintaining a repository manager altogether.
Related
We run a Nexus 2.14 with a site repository. At the moment, we deploy the sites using DAV, which is at times quite a burden for the server because a lot of small files are transferred separately.
SCP would probably be a better alternative, but I found no information whether this is supported by Nexus and if so, what I need to do to use it.
The Sonatype support told that this is not possible.
I have Jenkins version 2.7.1 running on a Windows 7 machine. It is successfully pulling code from a subversion repository and running tests. I have the test jobs set up for the development branch of each project only.
We periodically make stable releases of the projects in jar files with version numbers. I would like to have Jenkins be the repository manager for those stable releases. These are made by hand - There is no Jenkins job making or testing stable releases. The projects do use Maven.
Each stable build is tagged in the subversion repository, so it could be made again on demand if needed.
I downloaded the Maven repository server hoping to make this fit the purpose. I read the documentation that's provided, but it's pretty terse. As I understand it and have it configured now, this appears to have a couple of issues:
If I go to jenkins-ip/plugin/repository/project, it has made directories there that expose the names of all of my projects, which seems undesirable. (Here jenkins-ip is the IP where I access Jenkins on my local network.)
On the other hand, there's nothing but empty directories under these projects, so they're currently useless.
These projects all correspond to the continuous testing of the development branch. There's no apparent way to get the stable builds into the hierarchy. (It doesn't seem efficient to create a job for each stable release...)
Is there anyway to get Jenkins (with this plugin or through another method) to be the repository manager just for the stable builds? I know that I can start a different repository manager like archiva, but it would be ideal to use Jenkins since it's already running and it seems to claim capability for this function now.
To use Maven repository server you have to build the project on Jenkins.
Then the plugin will expose all archived artifacts as maven repo.
Note you need to use a "Maven project" type for it to work (freestyle is not supported)
There are several plugins that will help you manage building from multiple tags, however not all of them work with "Maven project" type.
You could also try Jenkins pipeline (previously "Workflow") or the Job-DSL plugin.
A simplest solution would be to have a build parameter specify the tag name (then checkout e.g. ^/tags/projectname/${tagParam}), but you have to figure out how to trigger the job then.
We use Maven, Jenkins and Nexus to build and deploy our software. The problem is that it's difficult for support and all of our people to know if a version is still in the QA staging repository, Beta or Release.
What tools are people using to make visibility of this possible? One option is to create a custom webapp that uses the nexus REST api to make it visible but I would imagine this is a solved problem and I shouldn't have to do that.
Any help or pointers in the right direction would be appreciated.
we are using here nexus 1.9.2.4 and maven 2.2.1 and on one pc (and only that one) when we try to compile our code using maven, it get stuck on downloading jars.
for example it'll be stuck on:
Downloading: http://mainserver:8081/nexus/content/groups/public/org/codehaus/mojo/javascript/javascript-maven-plugin/1.0-alpha-1-SNAPSHOT/javascript-maven-plugin-1.0-alpha-1-20090530.211438-7.jar
17/54K
and won't continue at all. tried using maven 3.0.4, but with the same result.
the machine runs windows 7.
any advise will be appreciated
This appears to be a bug related to using Maven on Java 7 and 64bit Windows. I have been experiencing similar problems.
The maven bug report and some discussion can be found here:
http://jira.codehaus.org/browse/MNG-5162
Workaround documented here:
https://cwiki.apache.org/confluence/display/MAVEN/ConnectException
Add -Djava.net.preferIPv4Stack=true to MAVEN_OPTS
Maven really needs to have some kind of support for mirrors and failsafes for the qurkeyness of the internet. Really, not everyone is going to be able to have a peered connection with the Oracle and Apache repositories. Every internet connection is going to drop a packet here and there, the "get a new ISP" response from Maven fans wouldn't help even if it were an option.
I've been staring at a 400k download go nowhere for about 10 minutes. I've noticed it gets stuck on the same files every time I wipe my repo too (bad sector maybe?). Which is a complete pita since it doesn't seem I can specify mirrors for it (short of hacking a hosts file). If you're a Maven project leader, look to Aptitude for ideas on what Maven could be.
EDIT:
I found a solution to my Maven problem here.
https://jira.codehaus.org/browse/MNG-5162
Under Ubuntu 13.10 simply...
sudo gedit /etc/environment
Add
MAVEN_OPTS="-Djava.net.preferIPv4Stack=true"
Save
Close
Reload terminal.
We have to setup new build environments regularily, and the process seems not so simple. Today I have got a new build machine, and the first Maven build was so slow, that I wanted to clarify why the performance was so bad. But how to do that?
Our context is:
We use multiple build machines, each project gets its own.
Each build machine has a similar setup, so that projects can start immediately and don't have to configure a lot.
We have the following tools preconfigured:
Hudson (currently 2.1.1, but will change)
Artifactory 2.3.3.1
Sonar
Hudson, Artifactory and Sonar have their own Tomcat configured
Maven 2.2.1 and Maven 3.0.3 (with no user configuration, only the installation has a settings.xml)
Ant 1.7.1 and Ant 1.8.2 (not relevant here)
Subversion 1.6 client
All tools should work together, especially the repository chain should be:
Build machine Maven repository
Build machine Artifactory
Central company Artifactory (is working as mirror and cache for the world)
Maven central (and other repository)
So when the Maven build needs a dependency resolved, it will be first looked-up in the local Maven repo, from there in the local Artifactory repo, then in the central Artifactory repo and only then on the internet.
We normally have to use proxies to connect to the internet, we don't need it in our intranet.
The first build (Maven Hello World) was built in around 45 minutes. In that time, all bootstrapping was happening, but I would have thought by using our chain of repositories (where the central repository is well filled), the build would be much faster. So I think the focus of the debugging will be the network, the local build is not the problem. So configuration and interaction of Maven and Artifactory is under consideration.
How do you debug such an environment? I have access to the build machine (as sudo) and to the central repository, but I do not know how to start, what to prove, where to look. So what is your experience, what are the tips and tricks you would like to share?
Here are a few things I have done up to now. If you have additional advice, you are welcome!
I suspected the chain of repositories to be the source of evil, so I addressed that first. The reasons are:
The real build on the local machine (of a hello world program) may differ in milliseconds, but not minutes.
Network makes a difference, so attack that first.
The chain of repository is interesting, if something is not found locally. Here are the steps to ensure that that is the case:
For Maven, delete the contents of the local cache. If the local cache is filled, you don't know if a resource if found in the local cache or elsewhere. (Do that at least at the end, if everything else is working again.)
For Artifactory, find that cache as well, and clean it by deleting its contents. It is only a cache, so it will be filled a new.
If you use a clever browser for measuring the lookup, ensure that what you asked for is not in the cache of the browser.
Else use a tool like wget to ask for a resource.
Try to minimize the sources for failure. So try to divide the long distance of your lookup in smaller segments that you control.
Don't use Maven for doing the lookup, start first with the Artifactory repository (only), and later then with Maven.
This led to the following tests I wanted to do. Every time I ensured that the previous prerequisits were met:
Ask for https://<my-project-artifactory>/repo/<my-pom>. Expectation:
Local lookup will fail, so has to find the resource in a remote repository in the central company Artifactory.
Possible effects could come from proxy, artifactory lookup.
Result: Lookup for a simple POM needed ~ 30 seconds. That is too much.
Remove the proxy. With wget, there is an option --no-proxy which does just that. Expection:
Faster lookup.
Result: No change at all, so proxy was not the reason.
Ask for https://<my-project-artifactory>/libs-snapshots-company/<my-pom>. So change the virtual repository to a real remote repository. Expectation:
Artifactory knows where to do the lookup, so it will be much faster.
Result: POM was found immediately, so the 30 seconds are Artifactory doing lookup. But what could be the reason for that?
Removed in Artifactory all remote and virtual repositories (only left our companies ones and the cached Maven central). But use again https://<my-project-artifactory>/repo/<my-pom>. Expectation:
Artifactory will find the repository much faster.
Result: POM came in an instant, not measurable.
I was then courageous and just started the build (with empty cache locally). The build needed then 5 seconds (instead of 15 minutes the same morning).
So I think I have now better understood what can go wrong, a lot of questions are remaining. Please add your ideas as answers, you will get reputation for them!