In our company we have a data store that holds a wide variety of objects. This data store could be seen as a remote repository with a proprietary format. We would to make those objects available in a Nexus Repository Manager in a similar fashion as a remote Maven repository.
I wonder, would it be possible to create a proxy to this non-standard proprietary repository? Our proprietary data store has some version information, that we could map to a standard repository format.
Any help like an example or pointing me to documentation or existing plugins would be greatly appreciated.
You can proxy almost anything available via http(s) using a raw format proxy in nexus. Now if you want to proxy something that is not maven to a maven format, it's not possible.
If you have some version info you can use, I imagine you can create a script that would get a set of artifacts from your company repo and register them correctly using the nexus API in a maven hosted repo. That would not be a proxy but a partial async mirror.
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 am having trouble accessing the svn revision number through Maven. The only real help I've received from the SCM usage page is the following:
<scm>
<connection>scm:svn:http://somerepository.com/svn_repo/trunk</connection>
<developerConnection>scm:svn:https://somerepository.com/svn_repo/trunk</developerConnection>
<tag>HEAD</tag>
<url>http://somerepository.com/view.cvs</url>
</scm>
This means nothing to me as I can't figure out what connection, developerConnection, and url mean. I simply plugged in the url to my repo for all 3 elements. I also don't know why Maven does not ask me for the username and password for the repository.
I am very new to Maven and might be asking a very basic question but would appreciate a full explanation as to how I am to access the svn repo.
First I would begin by clarifying the usage of Maven which seems to cause the confusion in your case:
Apache Maven is a software project management tool... that can manage the project's build.
Apache Maven has nothing to do with your revisions being pushed to your source code management system (SVN in your case).
Typically, you'll be pushing your changes through an IDE (Eclipse, IntelliJ IDEA and alike) or through a command line to your SVN repository and you won't in any way be pushing those changes through Maven in which case you'll be breaking its usage purpose.
Now comes the question, why you may need then those SCM related properties?
The answer is simple and should be relevant since Maven is a project build tool, it must handle your project release cycle which is final piece of the project build cycle... And it won't be able to do it in coherent way without updating your remote project informations since you are using an SCM remote repository.
Now back to those SCM related properties, and what do they mean:
connection: an URL connection endpoint to your SCM repository and which will only used for read access.
developerConnection: an URL connection endpoint to your SCM repository and which will be used for write access. (That's what a developer role is intended to do after all, push changes to the repository).
tag: it specifies the tag under which the project lives and I've seen only HEAD being used in there and assume would be the default.
url: it specifies a browsable repository, such as the one going through viewvc (In most cases you can replace the /svn/ path under your connection URL with /viewvc/)
SCM (Software Configuration Management, also called Source Code/Control Management or, succinctly, version control) is an integral part of any healthy project. If your Maven project uses an SCM system (it does, doesn't it?) then here is where you would place that information into the POM.
connection, developerConnection: The two connection elements convey to how one is to connect to the version control system through Maven. Where connection requires read access for Maven to be able to find the source code (for example, an update), developerConnection requires a connection that will give write access. The Maven project has spawned another project named Maven SCM, which creates a common API for any SCMs that wish to implement it. The most popular are CVS and Subversion, however, there is a growing list of other supported SCMs. All SCM connections are made through a common URL structure.
scm:[provider]:[provider_specific]
Where provider is the type of SCM system. For example, connecting to a CVS repository may look like this:
scm:svn:https://somerepository.com/svn_repo/trunk
tag: Specifies the tag that this project lives under. HEAD (meaning, the SCM root) should be the default.
url: A publicly browsable repository. For example, via ViewCVS.
Source
Analogy : https://www.youtube.com/watch?v=9In7ysQJGBs
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...
in company where I am working we are starting to use artifactory like tool of repositories managment, and then I'm reading the user guide of this tool. We started in the configuration creating a virtual repository, a few local and remote repositories. On the use guide i found the following thing:
Prevent disclosing sensitive business information derived from your artifact queries to whomever can intercept the queries, including the
owners of the remote repository itself.
I saw that this could be avoided through
exclude pattern
functionality on the virtual repository. Can you give us some suggestion about this? What kinds of request we should avoided to do?
You should avoid requests for internal artifacts being sent to remote repositories (directly or via virtuals). This can happen when projects depends on internal libraries or within multi module projects where modules depends on each other. When working with virtual repositories Artifactory will always search for such artifacts in local repositories first. However, if someone asked for a wrong version or had a typo in the artifact name, the artifact will not be found in a local repository and Artifactory will try to look for it in the remote repositories configured in this virtual.
To avoid exposing sensitive business information as described above, we strongly recommend the following best practices:
The list of remote repositories used in an organization should be managed under a single virtual repository to which all requests are directed
All internal artifacts should be specified in the Excludes Pattern field of the virtual repository (or alternatively, of each remote repository) using wildcard characters to encapsulate the widest possible specification of internal artifacts.
Assuming all of your projects/modules are using some kind of namespace, for example com.mycompany, you can configure an exclusion pattern for artifacts under this namespace: com/mycompany/**.
For more information take a look at avoiding security risks with an excludes pattern
Do you know a way to configure Nexus OSS so that it publishes the artifact repository to a remote server in a form that can be statically served, e.g. by Apache Httpd? I'd like to use this static copy to serve only my own artifacts, so the nexus server could actively trigger an update in case there is something new published.
Technically, I think it should be possible to create the metadata for the repo and store them in a static file, but I'm not sure with that. Any hints appreciated.
If there is another repo manager to achieve that, it would be fine for me as well.
I clearly understand the advantages to use the repo manager directly, but due to IT rules I can run Nexus only internally and it would be necessary to have these artifacts available in a (private) repo copy on the Internet as well.
A typical way to solve this IT requirement of only exposing known servers like Apache httpd is to setup Apache httpd as a reverse proxy as documented here.
You can use that approach in a more restrictive way by only exposing a specific repository or better repository group (so you can combine snapshots and releases) and tying that together with a specific user or a specifically restricted setup of the anonymous user that is used by default when no credentials are passed through.
Also if you need more help feel free to contact us in the user mailinglist or on hipchat.