I set up my virtual repository in artifactory to cache gradle distribution libraries by adding a remote repository called 'gradle-distributions' as described here. This remote repository points to this repository
As it looks like, the stated remote repository is not up to date any more because the latest version offered is gradle-1.0-milestone-8-bin.zip.
Is there a workaround for this issue, like pointing to a different remote repository or whatsoever?
Thanks in advance.
Gradleware now distributes Gradle from http://services.gradle.org/distributions/
But I am not sure that's what you are looking for. If you need some Gradle modules to depend on (like the api), you should use gradleApi() dependency, as described here.
If you're looking for other dependencies, you can configure your Gradle to use standard Artifactory remote repositories like lib-releases and make sure that Bintray's JCenter is configured as a remote repository and included in remote-repos virtual repository.
Gradle has moved the repository to http://services.gradle.org/distributions/
Related
I am setting up an ant build system on a project with dependency resolution being managed by ivy. I have it up and running with the file system being used for the local and shared repository currently. My ultimate goal would be that when developers are fixing bugs or creating new functionality, they would only be able to put artifacts into their local repository. When they belive their code is ready to be used by the rest of the team, it would be promoted to the proper branch in SVN and the group in charge of doing official builds would compile and publish the new artifacts.
So I guess my questions are how can you control who can publish to a repository? Does ivy just rely on filesystem permissions?
Also, I would eventually like to make my shared repository available via http. I think I could point apache to the file system repository directories for retrieving artifacts, but how do you setup publishing to an http repository?
I would suggest that you setup a repository manager to manage your project's build artifacts.
The best choices are one of the following:
nexus
artifactory
archiva
Publishing to a Maven repository means that your artifacts can be consumed by projects using other build technologies. All modern build systems support Maven (Including ivy, see the ibiblio resolver).
You could specify three resolvers in your ivy settings file. First would be a chain resolver which include remote and local ivy repositories. Second would be a local resolver for local ivy repository. Third a resolver to remote ivy repository only.
Every developer retrieves artifacts using first chain resolver.
Usual developer publish artifacts using second local resolver.
Your special team could use third remote resolver to publish in remoter ivy repository.
To protect remote repository from usual developers place it on (S)FTP server with write protection by password.
The only problem in this case is how to set versions on artifacts so that artifacts published in remote repository in some cases override locally published in some not.
Our team used such scheme few years ago. But now we use only local ivy repositories and CI server to build and run tests from various branches. We came up to this after switching to git.
for existing ivy repo easy to setup this: rest-ivy
I get what internal libraries are. But what is the purpose of a snapshot repository in archiva?
Libraries - private releases
Snapshots - private builds?
I have archiva set up and working with LDAP, but I am wondering why I need a snapshot repository. What purpose does this solve? Why is this used in development?
Also, lets say I update a library in the internal repo. Does this automatically update in the project POM files which use Maven, or I must update those poms to use the new JAR version?
Usually before releasing a maven project, the version is -SNAPSHOT.
So with such repositories you can share fresh SNAPHOT of your project for other people in your team to test or with a ci server.
Snapshots is maven idea to give version number as -SNAPSHOT , its under development it can be change any time.
Internal repository is the release repository with fixed version number. You can modify the SNAPSHOT, but That artifact never changes after it is released.
When we use internal, if dependency does not found inside it, then it will download it from central repository of maven. where as in snapshot it does not.
While building Maven projects (Spring and jbpm 4.4 to be specific),
I see that the libraries that I already have in Maven local repository, gets downloaded again or the console log suggests so.
Say my local repo already have the commons-collection3.1 in my library, is it necessary to download from the maven repository?
Is there a setting that can let maven know to look in the local repo first?
Thanks,
Ayusman
You might have the updatePolicy for SNAPSHOT repository set to always in your settings.xml. See this guide to settings.xml.
Maven will look in the local repository first by default.
Downloading in Maven is triggered by a project declaring a dependency that is not present in the local repository.
http://maven.apache.org/guides/introduction/introduction-to-repositories.html
We are using SVN as a Maven Repositary. We knew that it isn't advisable to have SVN backed maven repository, but still we have to go with it due to limitation within our organization. SVN backed repository used currently is partially implemented.We have developers working from two different geographical location. Problem we face now is whenever a developer adds a artifact to maven repo(svn repository) all other developers have to update the local svn view manually to get the newly added artifact before we do mvn clean package.
IS there a way to automatically download the artifact from svn maven repository to local repo if the artifact doesn't exists locally?
SVN is hosted with a webserver so maven repositary is accessed using HTTPS protocol only. We use maven 2.2 version.
I tried with wagon plugin which would deploy the build output(jar\war) to scm directly. We are not interested in deploying the build outputs. We need a solution to download artifacts automatically from svn maven repo if it isn't exists locally?
You make no mention of how your SVN repository exposes it's artifacts to the development teams. If it truly a Maven repository (conforming to the standard Maven repository layout) then you could just specify it's URL in the "repositories" section of your POM. Updating the local repo would then no longer be necessary.
I suspect that what you have checked into subversion is not a Maven repository layout? You'd lose one of the key benefits of using subversion if each new version of an artifact was being checked in as a new file....
You are describing the functionality offered by any Maven repository manager, for example: Nexus.
I understand your reluctance to embrace a new repository technology, but SCM systems like subversion are primarily designed for tracking changes to textual files.
In conclusion, if you truly wish to keep subversion in the loop I'd suggest one of two options:
Use subversion to control the contents of the local repository. (3rd party dependencies and the artifacts generated by the developers)
Use a repository manager like Nexus. Let Nexus manage cached content from external repositories, but commit the contents of locally hosted repositories into Subversion.
I am working on converting websphere portal project to maven framework for CI build. I am wondering if there is a way to reference websphere jars other than via dependencies in pom.xml and loading them all to maven repository? I cannot imagine loading them ALL to the repository...
Please advice! Thanks!
When using Maven, it is advisable that all dependent jars are installed in the repository. Even Websphere ones.
Ideally a corporate repository will come in handy here, so that you keep a separate repository for all the Websphere jars accessible to all the users in your project. See http://maven.apache.org/repository-management.html for more.
If this is not an option, then use the local file repository explained on a previous questions - here.
You'll still need to add each dependency in POM.
Also read http://sdudzin.blogspot.com/2007/09/maven-2-and-websphere-automated-build.html
if you have a lot of projects that require this, you can also create a parent pom that would have all the dependencies so your project/module/portlet poms are cleaner.