I've been doing quite a bit of searching and am unable to put all the pieces together. I want to create an ivy repository on one of our servers. I want to lock it down so it is private, and then be able to publish to this repository from Gradle.
I know how to publish using Gradle, and I have that working with a local ivy file system that Gradle creates:
repositories {
mavenCentral()
ivy {
name "localRepos"
url "${System.properties['user.home']}/repos"
}
}
uploadArchives {
repositories {
add project.repositories.localRepos
}
}
So what I need to do now is translate that into publishing to a remote private repos. But first, obviously, I need to create that repos and I can't seem to figure that out from the Ivy documentation or Google searching. Can someone point me in the right direction?
I'd prefer not to have to go down the Nexus, etc approach (no Maven).
An Ivy repository is just a file store, and hence you need to set up a server (e.g. Apache httpd) that allows to read and write those files (e.g. via HTTP GET/PUT). However, I strongly recommend to use a repository manager. Artifactory is a good choice.
Related
We lost our ivy repository for 3rd party libraries (a lot of them). The only thing we have is the ivy cache sitting on a build agent. Now we decide to move to Artifactory, ivy:install can copy dependencies from a repo to another, but ivy cache is not a repo. In addition, the ivy cache keeps all versions of a jar file under the same directory (ivy cache default pattern) - [organization]/[module]/[type]s/ (no revision). But we'd like to sort them out into different directories - [organization]/[module]/[revision]/[type]s/.
After doing this, should the new repo in artifactory function the same as any other repository? In other words, do I miss anything by creating a repository in this way?
Any help is greatly appreciated.
You can create a new repository layout in Artifactory that will match the Ivy cache layout:
[org]/[module]/[type]s/[module](-[classifier])-[baseRev](-[fileItegRev]).[ext]
Then create a new local repository configured with the Ivy cache layout and import the content of your Ivy cache into the new local repository.
Finally create a new virtual repository configured with the default Ivy layout and include the local repository you created. The virtual repository will perform the transformation between the Ivy cache layout and the Ivy default layout. You will need to configure Ivy to resolve artifacts from the virtual repository. In addition you will be able to include other Ivy repositories in this virtual.
In Gradle, we have configured a local maven repository, and artifacts are uploaded there for use in my local builds of other projects.
I'd prefer to use an Ivy repository (so I can have a custom pattern for artifact names).
How do you configure Gradle to upload to a local Ivy repository?
Try this (based on this and the API):
uploadArchives {
repositories {
ivy {
ivyPattern "/home/robin/.ivy2/local/[organisation]/[module]/[revision]/ivys/[artifact](-[classifier]).[ext]"
artifactPattern "/home/robin/.ivy2/local/[organisation]/[module]/[revision]/[ext]s/[artifact](-[classifier]).[ext]"
}
}
}
(replacing those patterns with your real ivy/artifact patterns).
currently, I'm testing Gradle as an alternative to Maven. In my projects, there are some 3rd party jars, which aren't available in any (Maven) repositories. My problem is now, how could I manage it to install these jars into my local .gradle repository. (If it's possible, I don't want to use the local Maven repository, because Gradle should run independently.) At the moment, I get a lot of exceptions because of missing jars. In Maven, it's quite simple by running the install command. However, my Google search for something similar to the Maven install command wasn't successful. Has anybody an idea?
you can include your file system JAR dependencies as:
dependencies {
runtime files('libs/a.jar', 'libs/b.jar')
runtime fileTree(dir: 'libs', include: '*.jar')
}
you may change runtime for compile/testCompile/etc..
A more comprehensive answer was given on a mailing list by Adam Murdoch at http://gradle.1045684.n5.nabble.com/Gradle-Make-a-3rd-party-jar-available-to-local-gradle-repository-td1431953.html
As of April 2010 there was no simple way to add a new jarfile to your ~/.gradle repository. Currently researching whether this has changed.
As of October 2014, this is still the case--because gradle does an md5 checksum of your jarfile, you can't simply download it and put it into a directory under .gradle/caches, and gradle doesn't, as far as I can tell, have any tasks which let you take a local file and push that file to its cache.
Used option (1) out of Adam Murdoch post (already linked above: http://gradle.1045684.n5.nabble.com/Gradle-Make-a-3rd-party-jar-available-to-local-gradle-repository-td1431953.html) with gradle-1.3 and it works just nicely!
Here his comment:
Copy the jars to a local directory and use a flatDir() repository to use them out of there. For example, you might copy them to
$projectDir/lib and in your build file do:
repositories {
flatDir(dirs: 'lib') }
The files in the lib directory must follow the naming scheme:
name-version-classifier.extension, where version and classifier are
optional. So, for example you might call them groovy-1.7.0.jar or even
groovy.jar
Then, you just declare the dependencies as normal:
dependencies {
compile 'groovy:groovy:1.7.0' }
There's a little more detail one flatDir() repository at:
http://gradle.org/0.9-preview-1/docs/userguide/dependency_management.html#sec:flat_dir_resolver
Similar to the above, but using an ivy resolver instead of flatDir(). This is pretty much the same as the above, but allows a
lot more options as far as naming and locations go.
There's some detail at:
http://gradle.org/0.9-preview-1/docs/userguide/dependency_management.html#sub:more_about_ivy_resolvers
Don't bother with declaring the dependencies. Just copy the jars to a local directory somewhere and add a file dependency. For example,
if the jars are in $projectDir/lib:
dependencies {
compile fileTree('lib') // this includes all the files under 'lib' in the compile classpath }
More details at:
http://gradle.org/0.9-preview-1/docs/userguide/dependency_management.html#N12EAD
Use maven install to install the dependencies into your local maven cache, and the use the maven cache as a repository:
repositories {
mavenRepo(urls: new File(System.properties['user.home'], '.m2/repository').toURI().toURL()) }
Maybe I'm missing something from my reading of your question, assuming your gradle repo is of the flatDir type, you should be able to copy the files there in the form myjar-1.0.jar and resolve them as myjar of version 1.0.
Not sure why should it be necessary for Gradle to run maven in order to access a local maven repository. You can just define the maven repos and it should resolve dependencies. You can use gradle upload to push the jars local or remote maven repos if you need to. In that case, it will execute maven.
In short: deploy to repository manager. It can local, on company LAN.
An altogether different way of thinking about this type of problem, specially if it happens often, is to use a repository manager. There are some great open source options out there such as Artifactory, Nexus or Archiva.
Lets assume you have a jar file from some dubious origin that needs to be included in your build until you have the opportunity of refactoring it out. A repository manager would allow you to upload the file to your own repository as, for the sake of this example, dubious-origin-UNKNOWN.jar
Then your build.gradle would look something like this:
repositories {
mavenRepo urls: "http://your.own.repository/url";
}
dependencies {
compile "dubious:origin:UNKNOWN";
}
There are a lot of other advantages to using a repository manager such as caching of remote artifacts, remove artifacts from scm, staging releases, more granular user permissions, and so forth.
On the down side, you would be adding a server which carries some maintenance overhead to keep your builds running.
Depends on the size if your project, I suppose.
I think something like this should work:
dependencies {
files('yourfile.jar')
}
Does it work for you?
I have set up a Maven 2 repository (call 'dev repository') using Apache Archiva which holds artifacts of my private projects.
If I build an artifact of my own project, say group1:cat for example, and Cat depends on { group1:dog, commons:collection }. The group1:cat and group1:dog are sit in dev repository, and commons:collection in the Central.
Now, when I build group1:cat, maven will fetch group1:dog and commons:collection, the problem is maven will always search in both dev repository and central repository to find the dependencies, but what I want is it search group1:dog in dev repositories only, and search commons:collection in central repositories only. I have central mirrors say central-mirror1 and central-mirror2, so how to configure maven so it will search commons:collection in default central repository and central-mirror-1,2 etc., and won't bother my dev repositories at all?
(...) what I want is it search group1:dog in dev repositories only, and search commons:collection in central repositories only.
I don't know how to achieve this and I don't think it's possible. How could maven be aware of the "source" repository for a given artifact?
But actually, why don't you make everything go through Archiva? What's the point of not using Archiva for all requests? If you don't want maven to check both repositories for your dependencies, it seems to be a pretty obvious solution. Moreover, people usually don't want to rely directly on central in a corporate environment (e.g. if it goes down you can't work anymore). No, really, I don't get it.
So, I'd just declare Archiva as a mirrorOf all repositories, like this:
<settings>
...
<mirrors>
<mirror>
<id>internal-repository</id>
<name>Maven Repository Manager running on repo.mycompany.com</name>
<url>http://repo.mycompany.com/proxy</url>
<mirrorOf>*</mirrorOf>
</mirror>
</mirrors>
...
</settings>
My setup uses my local Archiva instance to proxy central (and other 3rd party repositories). In my super pom, I've changed my repositories to only point to my local Archiva, and not search central at all. Everything comes in via my local proxy.
It's not quite what you're asking for, but I think it's an appropriate setup.
You can then use Archiva's black/white lists to tell it where to search for things.
I tried to configure the Maven plug in (version 4) to add the JBoss Maven repository at http://repository.jboss.com/maven2/ following the guide at http://wiki.netbeans.org/MavenBestPractices#section-MavenBestPractices-UtilizingAndManagingMavenRepositories.
The new repository appears in the list of Maven repositories, but I can not see any items (artifacts), updating the index does not help.
It looks like a problem with the Maven plug in. Maybe it requires an ".index" subdirectory which is not available on the JBoss server.
The JBoss repository has a Nexus index at http://repository.jboss.com/maven2/.index/. I think the problem is that Netbeans might not be making use of this index. I would recommend installing Nexus, adding the JBoss repo to a public group and then pointing your Netbeans instance at a local instance of Nexus.
Download Nexus from http://nexus.sonatype.org
Install it by unpacking the tar.gz or zip on your machine
Fire it up by running bin/jsw//nexus start
Go to http://localhost:8081/nexus
Log in as the default admin user: admin/admin123 is the username/password
Click on Repositories
Click the Add... button
Add a new repository for the JBoss repositorywith a remote location of: http://repository.jboss.com/maven2/
Save the new repository. (You will also want to make sure that Download remote index is selected)
Add the repository to your public group by clicking on the public group and dragging the new JBoss repository to the selected repositories.
Configure your ~/.m2/settings.xml file to have the same contents as: http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html
At that point, all of your repository requests are going to flow through Nexus. Nexus already ships with proxy repositories for Central. So all you did was to add in the JBoss repository and then add it to the public group. Once you do this, you'll find that your builds are going to be much, much faster.