I have a gradle build script and I'm trying to get at the dependency here.
As you can see the name (sbt-idea) cannot be simply substituted into the url after the group because there is a non-standard post fix '_2.10_0.13' to the name in the middle of the url.
I am unable to configure the maven repository type as it demands a pure convention approach
I can configure the ivy repository type to generate the correct jar url but sadly it demands that a corresponding ivy.xml (or any other name I configure it to use) in an ivy.xml format exist at the location. I cannot convince it to require a .pom instead.
Is it possible to achieve what I want to achieve using repositories in gradle?
Related
I'm working on a multi-module build which is needed to create an artifact from all WSDLs available on an internal repository. But they are a lot and I don't want to make a list of it, because it might be possible that later another WSDL project is created and needs to be included in the list, if that doesn't happen then the final artifact will be incomplete.
So I need to know if there's any way I can tell gradle to fetch artifacts present on a certain path like domain.com/path/to/repo/wsdls/ and fetch all available artifacts from this path.
I was thinking of creating a configuration which then has this specific repository to download from but it seems configuration does not include a repository and will use defined in build.gradle.
Any way to define a download-everything-pattern in dependencies block?
EDIT: Note: WSDL project means soap services in a zip archive
All Gradle ArtifactRepository implementations do is to provide the source for fetching the artifacts. It can be, for example, plain structure, maven repo and so on. I am aware that I can build my own repository implementation with some custom source.
However, I need something different: to 'hook' inside artifact resolving and fetching. For example, when Gradle is checking if foo:bar:1.0 is inside of my repository implementation, I would like to be able to capture this request and return artifact from wherever I want. (Obviously, its not a static location, otherwise one of the existing repository implementation would be enough).
In other words, when gradle asks for foo:bar:1.0 I want to control returning of artifacts jars - to have a custom Dependency resolver.
There is an old issue: https://issues.gradle.org/browse/GRADLE-1805 that asks for that.
Would this be possible with Gradle?
When building with Gradle I would like to reuse the maven repository I created in the past for dependency management, it is basically working, but I cannot find out answers for below questions from Gralde official document:
Does Gradle reuse my settings.xml from default location (my home folder) during maven dependency resolution?
How could I specify a repository in Gradle instead of using the default one? I can do it in maven command with -Drepository parameter easily.
How to control the update policy? I mean always update snapshot dependency and update release dependency per week something like this, or is my setting in settings.xml takes effect to Gradle as well?
Thanks in advance.
B.R.
My answers below are based on the following chapters from gradle user guide:
8. DEPENDENCY MANAGEMENT BASICS
51. DEPENDENCY MANAGEMENT
Now, to the specific answers:
According to DEPENDENCY MANAGEMENT BASICS (section 51.6.4. Local Maven repository), I guess the answer to this question would be yes:
Gradle uses the same logic as Maven to identify the location of your
local Maven cache. If a local repository location is defined in a
settings.xml, this location will be used. The settings.xml in
USER_HOME/.m2 takes precedence over the settings.xml in M2_HOME/conf.
If no settings.xml is available, Gradle uses the default location
USER_HOME/.m2/repository.
This applies to local repository defined as:
repositories {
mavenLocal()
}
Sections 8.5. Repositories and 51.6. Repositories in gradle user guide describes a couple of ways to define the repositories you'd like to use. these includes using mavenCentral, specifying a remote custom Maven repository, e.g.: maven { url "http://repo.mycompany.com/maven2" }, etc. If you'd like to pass the repository via command line then you can use gradle system property for that.
I believe that section 51.9. THE DEPENDENCY CACHE contains the information you're looking for. In short, the default cache is for 24 hours. However, it can be overridden configuring the ResolutionStrategy, e.g.: resolutionStrategy.cacheDynamicVersionsFor 10, 'minutes'.
Regarding using the settings in settings.xml then I could not find a clear answer for that but you're welcome to give it a try :)
i am new to maven though worked on ant a lot.After going thru http://maven.apache.org/guides/mini/guide-mirror-settings.html, i am bit confused.
i have two basic questions:-
1)whats the difference between mirror url and pluginRepository url. As my understanding both url defines the url from where repository
needs to be downloaded
2)whats the diefference b/w repository and pluginRepository?
3)what actually profile is? as per my understanding its a goal which we want to execute. For example:- when we do mvn install, install is already
defined profile by maven. Is n't it?
Let me start with a basic difference in Maven.
In general repositories are containers which can store two major types of artifacts.
The first are artifacts that are used as dependencies of other artifacts.
The other type of artifact is plugins. Maven plugins are themselves a special type of artifact. Because of this, plugin repositories may be separated from other repositories
Usually there will not made a difference between pluginRepositories and usual repositories, but technically it's possible.
Now to your first question:
It is possible to declare a repository inside the project which means to put the repository definition into the pom file which is bad practice.
The mirror setting is usually used to mirror all request from the defined repositories into a defined URL (see mirror settings). In practice delegate all request to a particular URL which is usually a URL of a repository manager.
Now we came to your third question.
A profile has nothing to do with a goal and nothing with mvn install. The call mvn install calls the maven build life cyclce which will run all life cycle phase after another. A profile can be best translated with a if-statement. You can activate a profile on command line like this:
mvn -Pdev install
mvn -Prun-its verify
which is a kind of condition in you pom.
I have a maven pom which is deployed to a repo -And I want to add extra meta data to the tags..... For example, date created, git md5, etc...
Most importantly , I want this meta data to be seen in the pom itself, (and also embedded in the jar/zip artifact, but that is easy to do).
Can I add more (nonidentifying) xml fields to a pom declaration, which can be used for browsing but not necessarily required for defining the pom resource ?
If not, what is a simple way to annotate information about a resource in a maven deployment server (I'm using archiva, which is similar to nexus)-- of course, there is the "version" field, but I don't want to have to cram all my metadata into just one field.
There are some fields in the pom.xml that can be used that are found under More Project Information in the Pom reference.
You could probably squeeze some information into the description tag and parse the way you like.
Or you could even use <properties/> and create some useful tags there that fulfill your requirements. It may not be the recommended way to use properties for this but it is still an option.
By using properties it would be very easy to get those values into the MANIFEST.MF file by using filtering techniques in combination with the Maven Jar Plugin.
An alternative approach is to use features offered by your chosen Maven repository manager:
Custom metadata in Nexus
Properties in Artifactory
Don't know if Archiva has these features, but they enable you to add custom information to artifacts but more importantly they also allow you to search on these tags.
Hope this helps.
Update
Sonatype support question on metadata