I have a central Maven repository which is shared by more than one Projects within the Company LAN. Now, I need to have an artifact which is licensed for a single Project, to be placed in the shared repository.
Is it possible set authorized access to that artifact, the credential can ideally be in the pom file of the desired project.
Any better solution is more than welcome.
Maven doesn't handle access rights in repositories, since it's just a client fetching data from a server. If you're using a repository manager, read its documentation. If you're just hosting files behind an Apache HTTPD server, then configure HTTPD.
Alternatively, you could move that file in a separate repository, and configure just one project's POM to use it. This doesn't fix the fact that the repository will continue to be public, so other projects/teams could get to it if they really want to.
Related
I need to host several jar files in maven repository. There are may free web hosting companies which provide free web space. Do I need some special configuration to create a simple maven repository and upload maven jars?
In essence, a Maven repository is simply a place to store and retrieve files from. Nowadays, this is mainly done via the HTTP protocol. In an over-simplified example (as it was in the early days of Maven), things were simply hosted in a web server - you would deploy them via an HTTP PUT and retrieve them over HTTP GET. As things evolved, Maven artifact repository managers evolved and they started keeping record of various kinds of metadata.
As an over-simplified answer: if you have a proper <distributionManagement/> and <repositories/> section in your pom.xml and you can issue HTTP PUT and HTTP GET operations against a web server, then you can store these artifacts in a web server, if you really don't want to use an artifact repository manager (which is not really advisable, but hey, who am I to stop you?!). Clearly, this example doesn't cover adding credentials (which is handled by the Maven settings.xml's <servers/> id mappings to <repository/> id-s.
If your free hosting service allows you to install an artifact repository manager, you should consider picking one and installing it.
I need to push our project API's (bundled jar) to Maven Central Repository. As Part of that,i have gone through this link . However, am quite confused whether our project is eligible to publish in maven central repo,
Our API is not open source. it need to distribute only to client who purchase from us. is Maven provides any restrictions to download jar only for specific user who has some key etc?
POM.xml is requesting for licensing information. ours is not open source, if we allowed to publish, what should be licensing content in pom.xml?
Why we have to give our repo information in pom.xml? we are using bitbucket and hence providing the repo url is not accessible for others. can we have dummy repo or it is mandatory?
Please help me out guys.
Everything you publish to maven central will be available to everyone in the world.
For your use case, you can consider hosting your own maven repository.
Check sonatype nexus, artifactory, archiva...
With your own repo, you can configure a password in your server. Then your clients will need to configure your server in their pom.xml or settings.xml to download your artifacts.
I see several options:
directly in pom.xml
in company super-pom
in settings.xml (global or user)
in a profile or directly (in settings.xml or pom.xml)
We want our Jenkins to push artifacts to internal repository, and developers to pull missing artifacts from there.
If I put the repository URL in pom.xml, and later the internal repository is moved to a different address, the released versions will all have a broken link.
Super-pom saves some repetition, but in a clean setup you need to somehow know where the repository is to find the parent POM — to tell you where the repository is.
Having the URL in settings allows one to change it without modifying the artifacts, but there are two problems:
build will fail due to unresolved dependencies, if maven settings have no reference to the internal repo
developers have to update their settings.xml files manually
I'm also unsure about the merits of putting repository configuration in profiles. I know it let's you easily switch the repositories on and off, but shouldn't the -o option and snapshot resolution settings be enough for most uses?
What about using a different repository (e.g. with instrumented classes) for integration tests?
Configure a single repository in the users ${HOME}/.m2/settings.xml and configure other needed repositories in your appropriate repository manager either Nexus, Artifactory or Archiva. In Jenkins there is the Config File Provider plugin which exactly handles such situations in a very convinient way.
If you want to have repeatable builds and good control over your organization internally, use a repository manager and use a mirrorOf entry in everyone’s settings.xml to point at that url.
If you are exposing your source and want to make it easy for others to
build, then consider adding a repository entry to your POM, but don’t
pick a URL lightly, think long-term, and use a URL that will always be
under your control.
http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
I'm trying to figure out if its possible to reuse Artifactory's maven repo on the local machine where the Artifactory server is running. The following details what I am trying to do.
I have a server where Artifactory runs and I'm planning on setting up Jenkins on the same server. If possible, I would like to have only one maven repository on the server. Since Artifactory already runs there, I would expect it is maintaining some kind of a maven repository (I looked around for it but couldn't find it).
Currently, when Jenkins uses Maven to build a maven project, it downloads the dependent jars into a local maven repo (a .m2 folder) on the server. Instead of this, would it be possible to point the settings.xml that maven is using to some local folder under Artifactory where artifactory stores all the jars? Basically, I would like maven to think that all the jars are already available in a local repo (which artifactory is maintaining) and so it wouldnt have to download all the jars from artifactory.
If maven and artifactory can share the same repo folder, this would be possible. But if Artifactory uses its own strucuture to maintain the maven repository (something other than the structure maven follows with its .m2 folder) this would not be possible.
I should state that I have very minimal knowledge of Artifactory, other than the fact that it is a maven repository manager.
Answering my own question here, as more research suggests that this is not possible. I found another question here on SO that states:
Artifactory uses Java Content Repository (JCR) standard to store artifacts. It is an abstraction above various storage implementations, which include filesystem, relational databases, etc. In any case, JCR manages the store by checksums (to reduce size and bandwith), so the repository is not directly browesable in the filesystem. The default implementation is storing the binaries on the filesystem (inside $ARTIFACTORY_HOME/data/filestore and the metadata in Derby DB.
How Artifactory manages repos
A blog post by the Nexus guys also suggests that this is not possible.
Contrasting Nexus and Artifactory -> Contrast #2
How can I insert artefact in archiva not through its web interface.
It is possible to upload artifacts using maven.
Please refer to the Archiva Users Guide, Section Deploying to Repository for the details.
The following methods are available:
upload via the user interface (I presume this is the one you refer to as the web interface)
connect via any WebDAV client at http://localhost:8080/archiva/repository/repo-name (adjust according to your configuration)
use HTTP PUT with basic authentication to the same location as the WebDAV URL (this is the method that other tools like Maven, Ivy, etc. would use)
drop the file into the correct place in the file system and wait for Archiva's scanner to pick up the changed artefact
As Torsten's answer indicates, uploading using Maven's deploy phase or deploy:deploy-file goals (or equivalent from another build tool) is likely what you want since it will take care of constructing the correct path for the artefact and pushing any associated metadata, assuming you are using Archiva as a Maven artefact repository.
You have an upload screen tru the web ui.
See http://www.youtube.com/watch?v=LSXe26inf0Y