I need to implement something similar to:
http://repo.example.com/distros/centos/5.7/ -> http://vault.centos.org/5.7/
http://repo.example.com/distros/centos/7.0/ -> http://mirror.centos.org/centos/7/
http://repo.example.com/distros/internal/ (a local Artifactory repository)
I discovered that at least with version 4.1 it seems impossible to map repositories to sub-directories.
Is this true or there is a workaround for doing this?
You cannot use the repository key for achieving this. The repository key is used as a unique identifier for the repository and should not be used for manipulating the request path.
If I understand your requirement correctly, there are 2 possible options I can think of:
Change the value of "YUM Metadata Folder Depth" to 1 so Yum metadata will be kept in one level from the root of the repository. This will allow to manage multiple sets of Yum metadata in one repository under different paths.
Use an HTTP proxy such as NginX in front of Artifactory and map the required paths to multiple Yum repositories in Artifactory
It seems that's a limitation of the product so I ended up having to raise this bug: https://www.jfrog.com/jira/browse/RTFACT-8683
Related
I want to some changes in jitsi and install from my own repository.
Actually after some changes, i want to install it in many servers with each servers have unique domain.
You can change the front-end with two options :
Option 1 (recommended)
Follow the manual installation documentation and replace «jitsi-meet» component which is in /srv/jitsi-meet
This directory must contain your version of jitsi-meet (you must build the project, follow this step but clone your repository instead official repository)
Option 2 (not recommended)
Follow the quick installation then replace the /usr/share/jitsi-meet
This is the same step but in another directory
Be careful, this option is faster but each update on jisti-meet package (apt) can break your installation and override the /usr/share/jitsi-meet directory
I would like to know the specs for the maven repository structure.
I know I could use archiva or nexus to create a repository. I am not interested in those information.
I have tried searching apache's maven website and google with the phrase
"maven artifact repository structure specs", and I mostly get the development directory structure expected on the maven client.
I would like someone to explain the structure here or point me to a comprehensive single document (i.e. one that does not explain the directory structure by making me follow a never ending trail of links) that explains for example,
How to create a simple maven repository using a static file system directory, deployed to apache http server.
or how to create a directory structure on googlecode that would appear as a maven repository.
Here is the specification (long overdue for documenting in Maven itself):
https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final
That said, I wouldn't refer to that for creating the repository in the way you've described. The best thing to do is to use mvn deploy:deploy-file with appropriate parameters to upload the files that you want to, as it can write appropriate metadata and structure for you. This can be done to a filesystem location and synced to the location you want to.
Another alternative is to run a repository manager, like Archiva, and upload using the web interface until you are happy, then sync the directory structure to the location that you want to.
I'm trying setup the Versioning bundle in RavenDB: http://ravendb.net/bundles/versioning
The installation instructions are pretty straight forward:
Simply place the Raven.Bundles.Versioning.dll in the Plugins
directory.
I've tried this do this by creating a "Plugins" directory under the Server directory (the Server directory contains the Raven.Server.exe), and dropping Raven.Client.Versioning.dll into that Plugins directory.
However, when I run RavenDB after that (either from the command line or as a service), it doesn't give me any indication that it has recognized the plugin, and when I save/edit new documents no versioning is being applied.
I've tried running with the default plugin directory settings (which supposedly automatically looks in the Plugins directory), and I've tried manually adding the PluginsDirectory setting to Raven.Server.exe.config, to no avail.
Has anyone been able to get plugins working, specifically the versioning bundle? Do you hae to do anything special?
Mike,
It is supposed to just work. Take a look at the statistics, you should see the versioning trigger registered there.
It is important to ensure that:
You are using the same version of the dlls
You restarts RavenDB after copying the directory
You don't reference another Raven/PluginsDirectory in the configuration
It is probably better to follow this up in the mailing list.
For Raven v2, you'll also add the bundle name to the the Raven/ActiveBundles property on a database document. The names should be semicolon-delimited.
For example, I have a database called MidwestAnimalRescue. To enable the Periodic Backup bundle and the Versioning bundle, my document will look like this:
I am interested in obtaining all JAR files contained in the public repository http://repo1.maven.org/maven2/
Is there a way to do so apart from writing a POM file containing all items in the Dependency section?
Essentially I want to create a local mirror
You could use something like - http://www.gnu.org/software/wget/ to mirror the entire repository but it is going to be huge.
I would recommend you use a local repository manager like:
http://nexus.sonatype.org/
http://archiva.apache.org
Use a repo manager like Nexus. Trying to mirror everything will get you banned.
http://maven.apache.org/settings.html As per documentation the user specific settings can be either copied to the .m2 folder or under the maven installation. If a developer changes a machine or gets a new user id, such properties have to be copied manually to these newer machines.
Would it be possible to store user specific setting information in the repository itself (say SVN) and somehow have the mvn scripts load it on startup.
If the content of the settings.xml is not that user specific (e.g. for mirrors), you could store the whole Maven install in SVN with a customized conf/settings.xml and have the developers grab it from SVN to "install" it on a new machine as described in this previous answer.
If the content of the settings.xml is really user specific (e.g. it contains secret things like passwords), then it must be located in ~/.m2 and you will have to somehow make it available at the new location. If a developer logs on another machine, you could use "Roaming user profile". If a developer gets another id, then you'll really have to duplicate it. The technical solution may depend on the level of confidentiality required.
And if you have several developers sharing a userid but still need different settings.xml, then you'll have to pass it to Maven using the -s option. One could imagine storing these custom settings.xml in the project in that case (assuming it doesn't contain sensitive information). For example:
mvn -s settings-user1.xml <goal>
Nope, the whole point of having user settings is to store them outside the maven projects. There's nothing stopping you from creating your own svn repository and storing your configuration files there, though. You could write some shell scripts to bootstrap a new workstation from that repository, but it really depends how often you do this to make it worthwhile.
I would suggest that you setup your own repository such as Archiva, Nexus or Artifactory. Which will get your dependencies/plugins , then you can use mirror to specify explicitly just one repository to be used(the one you setup on your network). So whenever developer changes machine or dependencies are needed for multiple developers the internal mirror can be used as repo, your dependencies/plugins will download in no time to your local repository/ies