I have Magnolia 5.4.9 release and I want to upgrade it to 5.4.18 from maven pom file. The problem is that in nexus repository there are pom files til the release 5.4.10. If I try to reach 5.4.11 or later, then I get this error:
Is there any solution to upgrade 5.4.11 and later?
'Maintenance releases for previous major versions of Magnolia are available to Magnolia On-Premises customers only (i.e. customers that have an active subscription to Magnolia On-Premises).' https://www.magnolia-cms.com/support/maintenance-policy.html, Unfortunate enough that's the policy.
In this case I see two alternatives:
Sending an email to info#magnolia-cms.com
or you want to upgrade to later release anyway, just giving it a shot in test env. or similar.
Should you an enterprise user: please login to Magnolia Nexus and get the version you wish. If your maven settings are accurate, you should have no problem fetching those dependencies as well. https://wiki.magnolia-cms.com/display/DEV/Maven+setup
Cheers,
Related
I'm using maven release plugin to deploy new versions of software.
When running
mvn release:prepare
mvn release:perform
Everything works as expected.
If I tell maven to release version 2.1, it publishes an artifact 2.1 as well as a 2.2-20210205.061032-1, which I guess is some kind of snapshot. I'm wondering if it´s possible to perform a release for a new snapshot version ONLY?
The use case being that I have made some changes I want to publish for testing, before commiting to a final release. Something like 2.2-SNAPSHOT, or something like 2.2-YYYYMMDD.HHmmSS-X.
When prompted by maven to enter the next version, if I enter 2.2-SNAPSHOT, it just repeats the question again.
Please advice on how to achieve this, or if I'm thinking about this the wrong way.
If you want to deploy a SNAPSHOT, just run
mvn clean deploy
The Maven Release Plugin is meant for release versions.
SNAPSHOTs are meant to be very fluid, to the level of a dependent project "immediately" picking up changes to the SNAPSHOT dependency, whatever "immediately" means: it could be directly in an IDE, or while doing rapid builds on a command line but also on a CI server. I agree with the answer of J Fabian Meier that you can deploy a SNAPSHOT using mvn deploy.
However, if you are delivering a pre-release version for testing to a different team, you probably want them to have something that is more stable than a SNAPSHOT. When testing it is often important that you can reason about what version (or constellation of versions) you are running, and this is not quite the case with SNAPSHOTs (you may push up a new version then by quasi-accident, users may or may not force-update their SNAPSHOTs, or Maven may not look for new SNAPSHOTs until tomorrow).
You may be better off with versions that are released (from Maven's perspective) using the Maven Release Plugin (and benefit from the safeguards it offers), but just using version "numbers" that indicate it is a pre-release: 2.2-rc, 2.2-beta (I'm sure SemVer has ideas of the exact pattern to use, and so does Maven).
I've seen Building and deploying native code using Maven - but can't get this (very similar) deployment working as I'd like..
I have a C++ project that builds with Maven, and the Maven CMake Plugin. This involves several Maven profiles, to select the correct settings for the various C++ compilers I use on the platforms I'm building on. (Windows 10, Ubuntu 16.04, Ubuntu 18.04, CentOS 7, Raspbian, macOS High Sierra). I use Jenkins to run this build on the various VMs/Raspberry Pi - yielding a .tar.gz or .zip via the Maven Assembly Plugin. The final result is six archive files, that vary in their classifier/type. They all have the same groupId/artifactId.
I wanted each of these jobs to deploy its archive to Sonatype's OSSRH Nexus system, using the nexus-staging-maven-plugin.
I had this plugin configured to not automatically close the repository, so that the multiple builds could run via Jenkins (sequentially), and deploy to the same repo. I would then review this in the web UI, then Release or Drop it appropriately.
This worked fine, when the project had a version number of 0.0.1-SNAPSHOT. However, when I decided to (manually) release this, by setting the version to 0.0.1, and run my Jenkins builds... the deployment behaviour was different to what I'd seen when it was a SNAPSHOT.
Each platform-specific deployment created its own staging repository in the OSSRH Snapshots repo.
After reading https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin, I have tried a variety of these settings, but nothing seems to work:
<skipStagingRepositoryClose>true</skipStagingRepositoryClose>
<skipStaging>true</skipStaging>
<autoReleaseAfterClose>false</autoReleaseAfterClose>
<stagingRepositoryId>${project.artifactId}-${project.version}-repo</stagingRepositoryId>
The nexus-staging:rc-open goal looks like it might help, allowing me to open a named staging repository (as I tried to do with stagingRepositoryId, above) - but it requires a staging profile id - I've used the rc-list-profiles goal to find mine - but when I give this to rc-open, it's reported as "missing or invalid".
It looks like this should be possible: https://github.com/sonatype/nexus-maven-plugins/blob/master/staging/maven-plugin/WORKFLOWS.md - this suggests that you can't create a new staging profile id; that they're allocated by Nexus.
Why is this mechanism different between SNAPSHOT and non-SNAPSHOT deployments?
Kind regards, Matt
I've updated https://stackoverflow.com/a/40954957/14731. Per point 6.6, SNAPSHOTs cannot be released atomically. There is no known workaround.
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".
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.