I have installed JFrog Artifactory OSS on my server to store all librairies which I have written.
I can create Maven repository but when I want to create a Cocoapods, a Nuget or a PHP Composer repository I can't do it (I can't select them on the list of repository type choice).
Do you know if it's a bug or if I need to upgrade to the Pro version ?
Sincerely,
KevSib
NuGet and PHP repository support requires the Pro version of Artifactory.
For more a comparison between the OSS/Pro/Enterprise version please take a look at the Artifactory feature matrix.
Related
I have a situation where my system has one maven installed (e.g version 3.7.1. I have some projects that needs that version so this version is my default and if I build a project using mvn the version 3.7.1 is used by default to build the project.
Now I have to work on a project where it needs maven version 3.8.1 and I am looking for a way to do it. I am planning to install the maven version 3.8.1 in same system and would like to call this maven while building the new project. Can anyone help me on how to add envionment variable for new maven and call it whenever necessary while building without removing the 3.7.1 version
Aside from having separate Maven installations on your system, you could also have a look at the Maven Wrapper.
The maven wrapper allows you to attach a small script to your code base, which downloads and runs a specific version of Maven. In this way there are no dependencies to any Maven installations on your system.
After placing the Maven Wrapper in your project, you would then simply run ./mvnw install instead of mvn install.
I am using SDKMAN to manage different versions of maven or java. SDKMAN is a tool for managing parallel versions of multiple Software Development Kits on most Unix based systems. It provides a convenient Command Line Interface (CLI) and API for installing, switching, removing and listing Candidates.
It is very convenient and this problem no longer exists for me.
I want to use perforce as SonarQube 5.3 scm provider, but it failed with this error message:
ERROR: SCM provider was set to "perforce" but no SCM provider found for this key.
Supported SCM providers are svn,git
I want to install perforce plugin in SonarQube update center, but it said:
Error while downloading plugin 'scmperforce' with version '1.4'.
No compatible plugin found.
And I can't find any available scm perforce plugins on the SonarQube website.
How to use perforce with SonarQube 5.3?
The current version of SonarQube is 6.4 and the current LTS is 5.6.6. Plugin versions only compatible with versions lower than those have been purged from the Update Center.
There is, however, a version of the Perforce plugin that's compatible with 5.6.6.
Recently Sonatype released new version 3.0 of the Nexus repository. On the first look, the new version has quite a bit new features, and most important for is support for npm modules.
However, I quickly realised that there is no way to migrate our current maven repository to a new version as the structure of the repository has been changed. The migration from the version 2 promised to be available in version 3.1, but I cannot find when it is going to happen. We need support for npm and I wonder if I'll start using 3.0 for npm only would it be possible to somehow merge my npm and maven repositories together once 3.1 released?
Nexus 2 does have support for npm, but npm in Nexus 3 has support for some features that nexus 2 doesn't. Go ahead and set up Nexus 3 for npm now, when 3.1 is out you'll be able to migrate your existing Nexus 2 repositories into the Nexus 3 instance.
Is there a way to update the maven distribution without re-downloading the newer version and fixing the new path in the environment path?
something like: mvn selfupdate (the macport style)
No, but the Maven install is only a very thin bootstrap anyway.....
Maven downloads most of it's functionality as plugins. This normally happens when you run your first build and stores them in a local repository under:
$HOME/.m2/repository
So the good news is that when you install the new version of Maven, it will re-use the plugins already downloaded (unless newer ones are required).
Finally if you have concerns about performance it's an excellent idea to install a Maven repository manager. Software like Nexus can proxy and cache external repositories like Maven Central and will significantly improve your build performance (and enable off-line builds). Nexus is very lightweight, I run it on my laptop.
I am getting this error in a Maven build (mvn clean install) on a Mac with Mountain Lion
org.tmatesoft.svn.core.SVNException: svn: The path 'XYZ' appears to be part of Subversion 1.7 (SVNKit 1.4) or greater
working copy rooted at '/Users/XYZ/workspace/XYZ'.
Please upgrade your Subversion (SVNKit) client to use this working copy.
I had SVN installed as part of the Apple Command Line tools package and that gets installed at /usr/bin. I have installed the latest SVN as well but that got installed at /usr/local/bin.
When the maven build runs, it does not pick up the latest SVN, it picks the older one and fails.
Has anyone faced this kind of problem before?
I think there are 2 options -
1) Somehow force maven to use the new installed SVN.
2) Upgrade the SVN installed as part of Apple' Command Line tools to the latest SVN. I have reinstalled Command Line tools with the latest version but it still sticks to the older version.
I dont control the pom.xml so modifying it is not a viable option.
Any pointers in resolving this would be much appreciated.
Thanks!
This means your svn client is version 1.7 but the working copy(your project workspace) was checkout with the older version.
It's simple by execute the following command at your project root directory, where the pom.xml is there.
svn upgrade
please note, the maven use the svn client which is in your OS path.
After upgrade you should configure your IDE to use the version 1.7 as well. In my case I use the Eclipes Juno sr1 with Svnkit.
Anyhow if you would not like to change the working copy or IDE configuration. There is an alternative by install the svn clinet 1.4/1.5/1.6 and set it active via OS path instead.
I hope this may help.
Regards,
Charlee Ch.