I use Gradle on Android Studio 1.1, I can use the "maven-publish" Plugin. With this one, I can publish to repositories.
Can I use the google cloud storage to host a maven repository?
Or I have to create a Bitbucket/Github to make this?
Thanks
You can have a Google Cloud Storage Bucket act as a remote maven repository to host your artifacts and dependencies only if you do not require the need to have those artifacts and dependencies updated more than once per second. While there is no limit on the number of objects that you can create in a Google Cloud Storage bucket, and there is no limit to writes across multiple objects, there is an Update limit on each object of once per second; so rapid writes to a single object won’t scale.
That being said, you can configure a Google Cloud Storage Bucket as a Website and use it as your remote repository.
By default, Maven will download from the central repository. To override this, you need to specify your GCS Bucket in your pom.xml as shown in Using Mirrors for Repositories.
To upload your artifacts to your bucket you must authenticate with a username and password in your ~/.m2/settings.xml file. The username and password need to be retrieved from the Google Cloud Console:
In the menu on the left select Storage → Settings > > Interoperability.
If no keys are listed under Interoperable storage access keys, select "Create a new key".
Use the Access Key as username, and Secret as the password
You should setup a private Maven repository using https://github.com/renaudcerrato/appengine-maven-repository.
Make a separate App Engine project yourcompanyname-maven.appspot.com.
Setup the username / password configuration and you're all set.
Related
in Google cloud Artifact Registry I ve created registry setup using maven type and remote functionality that supposed to mirror central.
It just doesn't work. My local test project is not able to fetch anything from such registry - I assume it should populate gcp registry cache from maven central and propagate any artifacts to my local .m2 directory.
In GCP web console remote type is marked as private preview - which is not really explained what it really means. I can definitely access this config, so I assume it should work :/
any ideas?
This is already mentioned in the public document that, GCP remote Artifact Registry is not Generally available for all customers.
Feature availability: This feature is only available to users who signed up for Artifact Registry private preview. For more information, contact your Google representative.
And the term Private Preview means features are ready for testing by customers and have limited support. But, they are not complete yet.
Have a look at this document for details about launching stages
I have access to a private Nexus Repository and would like to speed up my CI builds and thought that I could use the private repository to store and access my build cache. Is this a possibility or a dead end?
It works like a breeze.
Just create a "Raw" repository and give a user write permission for it.
This user then is used to fill the cache and you can use another user or anonymous access to read from the cache.
I just tried it minutes ago.
Any web server that supports PUT for storing files and GET for retrieving the same files should be fine with the default HttpBuildCache implementation.
You can even provide an own client-side implementation to use any remote service you want as build cache.
No.
Gradle's remote build cache is one of the selling points of Gradle Enterprise. So it's not something you can just "plugin" to another piece of software like Nexus.
There is however a Docker image that is designed to work with Gradle Enterprise. Maybe you could make use of that somehow.
But again, the remote build cache is a selling point of Gradle enterprise and as a result is designed to work with Gradle enterprise.
https://gradle.com/build-cache/
We are looking into setting up a local maven repository server at our institute. We have several teams that are completely independent and therefore should not have write access to each others artifacts.
Ideally we would like a similar permission concept as e.g. Gitlab, where every user can create a project (or in this case repository) and give permissions to it, but not have write access to any other repositories.
I tried out Artifactory and Nexus, but as far as I could tell, giving permissions to a group for a specific project includes manual work for a user with full admin rights, namely creating that repository.
Is there a freely available maven repository server, that allows creation and administration of repositories by users without giving them access to other repositories? If not, is there one, that can restrict write access for an artifact to the person who first deployed it?
Even better if Artifactory or Nexus can in fact do something like that and I just missed it.
You can create an arbitrary number of repositories in one Nexus 2.x (professional) server. Then you can set up different user accounts with different writing rights, e.g. you can create a projectA repository and define a projectAuser which has writing rights only for this particular repository.
I guess this is possible in Artifactory and Nexus 3 as well, but I do not have experience.
In Artifactory you have many options, I recommend you:
Create a virtual maven repository with permissions for a group of users.
Configure the settings.xml of this group of users with this virtual repository.
Create remote repositories to access to Github or any other websites.
Add these remote repositories to the virtual repository.
Create local repositories if you need and add to the virtual repository.
Do this with every group of users that you want and you will have independent artifacts and repositories.
I want to setup a development environment that allows reusing some artifacts from public Maven repositories like Maven Central, Code Haus. Specifically, I like the concept of transitive dependencies.
In our company, our production network cannot export any data outside, but we can push data inside. We already have some gateways to copy file from the outside into our network. Therefore, I could use this to copy the required packages manually but we would miss the power of maven. In our case, the perfect solution would be to be able to get data from public repository but be forbidden to deploy to the external repo.
So I would like to have your expert view on this problem.
We can use various means, as long as the capability to export data outside our network is guarantee:
External packages are created on a disk area that is read-only from production servers.
Some HTTP requests are filtered.
Using a repository manager, as Nexus.
In the repository management guide, Nexus talks about this possibility (http://books.sonatype.com/nexus-book/reference/confignx-sect-manage-repo.html). I would like a confirmation from you guys about how secure it is. Specifically, this has to be updated only by the IT manager.
Regards,
Loïc.
This is completely feasible and a common setup with Nexus. Here are the steps roughly.
Lock all developers and CI server inside the network disallowing direct access to outside servers
Setup Nexus to proxy external repositories like Central as desired
Allow Nexus to reach to those external repositories via the proxy
Configure developers and CI server machines to access Nexus to get the dependencies (and transitive dependencies) as desired
Optionally you can also
Configure CI servers to deploy any internal packages to Nexus
Configure deployment tools to get components for deployment from Nexus
Also note this can be done via different repository formats and toolchains. The common one is Maven, but Nexus also supports NPM, Nuget, Rubygems, sites, YUM and others.
And if you want to make some of your packages in Nexus available to the outside you can configure this as well following multiple options.
Also note that a proxy repository is by definition read only in terms of deployments to it directly. Thats what a hosted repository is for...
I have problems with configurations using Maven + Artifactory.
I try to download a new external file using a user created in Artifactory and my Artifactory doesn´t make download, claiming "Access denied" but if I put the same credentials as defined in remote settings, my application can download every external jars.
If I use the same permission setting of my remote configuration settings.xml where the Artifactory was installed (user admin) I can make downloads quickly.
There´s some way to configure to create a user in my Artifactory and configure the permission to make downloads of new artefacts? Because I didn´t find in anywhere.
I think that is more secure for my company if I have the possibility to create a new user in my Artifactory and just give the permissions: read and to download new artefacts but this option doesn´t exist in Artifactory.
How could I do this?
Because you've created a user entity within Artifactory, make sure it's got at least read permissions on all the repositories you'd like to resolve from.
For easier Maven configuration, you can also use Artifactory to generate proper Maven settings for yourself; this helps to reduce typos and reference mistakes (make sure you're logged in as the user entity you've created whilst generating the settings). After applying the settings file you can also run the mvn help:effective-settings goal on your project to make sure everything was applied correctly.
Finally, if you're required to authenticate with the remote repository you're proxying, you'll need to he specify the credentials in the configuration of that remote repository.
Make sure the user you are using to connect to Artifactory has Deploy permissions in Artifactory. The Deploy permission allows the user to download artifacts from repositories (in other words, populate cache with remote artifacts).
https://www.jfrog.com/confluence/display/RTF/Managing+Permissions
Deploy Allows deploying artifacts and deploying to caches (i.e.
populating caches with remote artifacts)
More information from the JFrog forum:
http://forums.jfrog.org/Maven-using-anonymous-user-even-though-artifactory-server-setup-in-the-settings-xml-td4634521.html