I want to upgrade my nexus repo from 2.10.0-02 to latest 3.x edition.
So I followed the documentation which states I should first upgrade it to latest 2.y edition (which is nexus-2.14.13-01).
I followed the steps as mentioned in the documentation, viz.
Stop old version nexus server.
Extract nexus-2.14.13-01.zip at same location as previous nexus, so 'sonatype-work' becomes the sibling directory.
Point soft links and env variables to new nexus.
Start new nexus server.
Change owner to nexus user. (as in previous version)
But in my new nexus-2.14.13-01 instance, I cannot see my personal artifacts, be it proxy or hosted.
Although I can still see all my artifacts in /sonatype-work/nexus/storage folder.
What am I missing? Please suggest
Thank you
The browse storage UI in Nexus Repo 2.x displays what is on disk. It's as simple as that. So if the artifacts are not visible it means the work directory is not set to the right location. Edit $installdir/conf/nexus.properties and set "nexus-work=/sonaytype-work/nexus".
Related
What is a good way for extension/plugins during sonar upgrade? I am upgrading sonar from 4.0 to 4.5.1 second time.In first time, I copied the old extension/plugins folder into new sonar version.It so happened that during first time, there was a C# plugins and during database upgrade step, we got the message of "Impossible to upgrade Database". On removing this plugin, the database upgrade didn't happen and we were taken directly to the login page. As a results projects were missing on sonar dashboard though the LDAP users got imported.So I would like to know what is the right way out of below ?
1. Copy the old plugins folder from sonar 4.0 (old) folder to sonar 4.5.1 (new) folder.
2. Don't copy the old plugin folder. Just download the new plugins which are required post sonar upgrade.
Don't do #2! It will screw up your rule profiles.
You started out correctly by copying the plugins folder. But you have to go a little farther.
You need to read the upgrade notes for each intervening version. They're all children of this general guide to upgrading. They should mention all plugin incompatibilities & you'll have to deal with those manually. You may be able to do some of the upgrades via the update center in the old version before you shut it down. The rest you have to handle by deleting/replacing the old plugin jars.
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.
I have a Sonatype Nexus repository on an older machine, and I have purchased a newer server which will become my new repository host. In the installation of Nexus on the older machine I have an extensive collection of artifacts, the vast majority of which are now obsolete and can be safely removed from Nexus.
I know it is possible for me to move all of the artifacts from the old installation into the new installation by simply copying the sonatype-work directory to the new box. My question is this: If I want to prune the artifacts in that directory down to only what I need right now (probably about 20% of the repository contents) what steps would I have to take other than deleting the unwanted artifacts? For example, would I need to force Nexus to rebuild indexes? Thanks for the help!
You could just install the new Nexus and proxy off the old one via one proxy repo in addition to Central and other repos. Then you run this for a while and only things not found in other public repositories you configure will be proxied from the old Nexus instance.
At a later stage you could run scheduled task on the old repo that removed old items.
When you are satisfied you got everything you need, you do one last backup and then take the old Nexus instance offline.
Of course the other option is to just not worry and migrate it all. In the end you really only have to migrate what you actually deployed (so probably releases and 3rd party repos).
The easiest option btw. is to just copy the whole sonatype-work folder over to the new machine and fire it up with a new Nexus install there and flick the switch.
everytime i start with a fresh new workspace, m2eclipse downloads nexus-maven-repository-index.gz from the maven central repository.
this is good.
but,
some times, i just want to start a new workspace, and not wait for it to download,
it tried copying the whole .metadata directory from an old workspace to the new one,
but the list of maven artifacts are still empty.
is there a way i can cache it?
or at least download the file once, and the copy/extract/repackage it so that m2eclipse thinks it has already downloaded it and allows me to search for maven artifacts.
or a short version of the question
where and in what format is the "nexus-maven-repository-index.gz" file stored in the workspace?
The index is stored in the plugin's metadata location, i.e.
[workspace root]/.metadata/.plugins/org.maven.ide.eclipse/nexus
There will be one folder for each remote repository index in use.
You can configure the plugin to not download the index at startup too. Got to Window->Preferences->Maven and uncheck Download repository indexes at startup, you'll have to remember to reactivate it to get any updates though
Update:
I just verified that copying the metadata works. M2Eclipse will still contact the repository to download the deltas (assuming the above option is checked), but that only takes a few moments as it is only downloading the deltas.
Depending on your situation, you may want to try running a managed repository such as artifactory or nexus.
Configure it as the one-true-source-of-everything in maven, that way the initial download should only be from a local location and hence fast.
There is similar problem in my company, due to the network/security restrictions, the index file can't be downloaded by m2eclipse.
I have tried to use apache, to direct maven.org to my localhost to provide the index.(it should work, you can try). But again, network restriction disables local pc level ds resolution.
Last solution is try to downlaod nexus-maven-repository-index.zip, extract everything inside this zip, except the timestamp file, and extract and replace everything into the corresponding index folder for central repository.
It works. :-D
I am trying to build an update site for my plugins built with maven. I have a site project with following entry;
<packaging>eclipse-update-site</packaging>
I get the site.zip in the end containing only site.xml in it even though within target/site I have all the folders i.e features/.jar, plugin/.jar, artefacts.jar, content.jar and site.xml.
Secondly I would like to upload the site.zip (with all the contents) on to the FTP site (delete the old version on remote machine and extract this new zip for DEV, for version releases I would like to keep the older releases)
Could you please point me to right direction as I am new to this whole thing.
Thanks
--
Sjunejo
packaging type eclipse-update-site is deprecated, use eclipse-repository instead which will create a repository zip by default.
For details see http://wiki.eclipse.org/Tycho/Reference_Card#Update_Site