We are upgrading our nexus artifact repository from 2.x to 3.x version. During this process, after the migration is complete, there is a timestamp missing for the artifacts. Any solution regarding this will be helpful.
This has nothing to do with your upgrade. Tree view (browse) in Nexus Repository Manager 3 does not show last modified for folders. I have never heard this requested but if this is important to you, suggest you file a ticket in issues.sonatype.com in the NEXUS project and it can be evaluated by the team.
Related
I'm using a 4.0.2 version of artifactory.
I'd like to know if it's possible a direct migration from 4.0.2 to actual 7 release or some intermediate steps are needed.
Could someone provide documentation about this topic ?
Tks
Tullio
The Quick answer is No.
Upgrading Artifactory from 4.x version to 7.x will require incremental upgrades on the way.
In order to find the best solution, based on your current state of the application, please refer to the guides below:
Upgrading from Artifactory 4.x: https://www.jfrog.com/confluence/display/RTF4X/Upgrading+Artifactory#UpgradingArtifactory-Upgradingfromv3.xorv4.xtotheLatestVersion
Upgrading from Artifactory 5.x: https://www.jfrog.com/confluence/display/RTF5X/Upgrading+Artifactory
Upgrading from Artifactory 6.x & 7.x: https://www.jfrog.com/confluence/display/JFROG/Upgrading+Artifactory#UpgradingArtifactory
Nexus 2.x had a REST API to download artifacts like below but no longer works for Nexus 3.x
wget "http://local:8081/service/local/artifact/maven/redirect?g=com.mycompany&a=my-app&v=LATEST" --content-disposition
Has the API changed to something else for on Nexus 3.0.0-03?
Currently this does not exist in Nexus 3. It is on our Roadmap.
Edit: Since Nexus 3.3 API functionality has been added. See https://help.sonatype.com/repomanager3/rest-and-integration-api for more information.
At this time, the REST API has been released as beta. You can get more information and give us feedback by going to this link: http://blog.sonatype.com/nexus-repository-new-beta-rest-api-for-content
just for this case, I created a PHP script that returns HTTP redirect to the location of the artifact.
feel free to use
https://github.com/maozza/nexus3-redirector
The URL for downloading a Maven asset directly with Nexus3 looks roughly like this:
https://nexus.example.local/service/rest/v1/search/assets/download?sort=version&repository=snapshots&maven.groupId=com.example.group&maven.artifactId=my-artifact&maven.baseVersion=1.0.0-SNAPSHOT&maven.extension=jar
(Tested with Nexus v3.28)
For more options and other repository formats, check out the Swagger interface that's available in the administration area of Nexus.
So I updated to swift 3.0 and now my projects with realm 1.0.2 all give me an error.
RealmSwift compiled with older version of Swift language (2.0) than previous files (3.0)
I also tried to build a net new project and still get the build error, so I know it is not a conversion issue on the Swift side.
I found several Swift 3.0 beta users and tried to run the script to update my version to 3.0 and several other options. The last few posts appeared to use Cocoa Pods - which I don't currently use. Is that the supported fix path?
Any help or direction would be greatly appreciated.
I haven't tried it yet, but here is what should work.
Essentially, the compiler gives you a description of what went wrong. The framework was compiled with Swift 2.0, while your project or other files were compiled with Swift version 3.0 (which means you made the switch after upgrading to the new version of Xcode.
To fix this, you need to use the Realm framework compiled with a Swift 3.0 compiler. Since the Realm team doesn't yet provide a precompiled version compiled with Swift 3.0, you have to do so yourself. To do that, go to their Github repository, and follow the instructions in the README under "Building Realm":
Prerequisites:
Building Realm requires Xcode 7.3.
Building Realm documentation requires jazzy
Once you have all the necessary prerequisites, building
Realm.framework just takes a single command: sh build.sh build.
You'll need an internet connection the first time you build Realm to
download the core binary.
This should generate the Realm framework with the current compiler version, which you then just have to use to replace your current Realm framework with. After that, everything should compile as it used to.
As stated before, I don't know if this actually works, as I haven't tried it yet. I don't exactly know if Swift 3.0 is supported by Realm yet or if there are any other issues you could run into. So please let me know how this works out!
On the Sonatype.com website I can read the following
Nexus is a repository manager. It allows you to proxy, collect, and
manage your dependencies so that you are not constantly juggling a
collection of JARs. It makes it easy to distribute your software.
Internally, you configure your build to publish artifacts to Nexus and
they then become available to other developers. You get the benefits
of having your own ‘central’, and there is no easier way to
collaborate.
The part about "constantly juggling a collection of JAR" I find intriguing.
I my experience, this is exactly what the Nexus process looks like.
As an example. My build is failing with message
[ERROR] Failed to execute goal on project myproject: Could not resolve dependencies for project myproject:jar:1.0.0-SNAPSHOT: Could not find artifact net.sf.saxon:saxon-dom:jar:9.0 in nexus (https://mynexus:8443/nexus/content/groups/public/)
So supposedly the Nexus repo at https://mynexus:8443/nexus/content/groups/public/ does not contain this artifact.
Using the Nexus web interface I can however search and find this particular artifact. It is located in the Jboss Maven2 repo.
What I can also do is navigate the index of the Public Repositories and find this particular artifact saxon-dom version 9.0 manually by expanding the tree navigator. It is in the folder net\sf\saxon.
So my conclusion is that Nexus is exactly not doing what it is claiming to be doing. It is not helping me manage dependencies - I have to resolve those manually.
What results is exactly like constantly juggling collections of jars. I have to manually download those and put them on the class path in order to perform a build.
As a Repository Manager it does not look very useful.
As it turns out, I needed to wrap my brain around the way that Nexus deals with missing dependencies.
This issue I think that artifact saxon-dom was once part of the repo but removed at some point. See https://repository.jboss.org/nexus/content/groups/public/net/sf/saxon/saxon-dom/
So there still is some metadata but not the jar and the pom.
When I search for the artifact Nexus finds it based on this metadata. In search results I can see the jar and pom.
Now I mistakenly thought that the artifacts are found and in the repo. This is not the case because if we try to download the jar you see message similar to below.
So Nexus caches the 404, the fact that it was unable to find the artifact. But it is completely unclear in the UI that the result is a cached 404.
I am using Apache Karaf 2.3.0, and deploying my bundles as Activator bundles. At some place ver rarely I face a problem where my karaf does not start up the bundles. But I see that when i start the container on such boxes with the network(on my Linux box) brought down, it starts up. I am just a bit confused as to what is the dependency that Karaf is having on the network, that is stopping it from resoving all the bundles. From my application specific bundle code, I am not specifically using the network.
What is the dependency of Karaf on the network?
Karaf deploys bundles as maven artifacts, sometimes it will try to figure out to use the latest from the repository. I think there has been a fix for this behavior already. You should use the latest 2.3.9 instead of 2.3.0. There has been a lot of improvements regarding this topic.
EDIT - Question Answers:
1) Karaf sometimes tries to load the artifacts from the local maven repository and after that from the system folder. This is a regression that has been fixed.
2) Yes this issue has been fixed on all current versions.
3) I would always go for version 3.0.2 since this is in line with future enhancements. 2.4. was introduced to have OSGi 5 capabilities with supporting the "Older" feature set, especially the command syntax which has been changed with 3.0
4) yes and has been made default with 3.0.x and 2.3.x
Got it running. It was indeed maven i believe. resolv.conf file on my linux box had ip entries in it which probably made maven to look outside, but was not getting a proper response. Removed the mvn urls from the /etc/ file and restarted the karaf and it started.
But i am yet confused as to how this works on the other boxes... thanks Achim