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
Related
We use Gradle for for our builds. After our CI, we publish our Jar artifacts to our Nexus Maven Repo which other Internal teams can access and use.
We have a problem now wherein one of our Internal teams who does not have access to codebase requires the Jsp tag files and TLD files in a shared repo to compile their custom JSPs.
To achieve this, I have created a "raw" repository in our Nexus with a plan to publish/upload the required tag files using a Gradle task which the Other team can download to their workspace from the same repo using another Gradle task which downloads them.
I got stuck on how to publish/upload all the JSP tag files available in one particular folder to Nexus Raw repo from Gradle
Any help is highly appreciated.!
My team is migrating our code to an Azure environment and Microsoft's own article on the subject describes how to use Maven in an Azure environment:
https://learn.microsoft.com/en-us/azure/devops/java/labs/mavenpmvsts/?view=vsts
One of Maven's best practices is to avoid defining repository elements within the pom file and use a repository manager configured within the settings.xml instead.
The Microsoft article instructs otherwise: they say to add the repository url right in the pom file.
I would have been okay with it if the repository element was defined only in the distributionManagement section, but that is not the case. The article defines the url in a repositories element outside of the distribution context.
My understanding of the repository element of the pom.xml file is that it overrides the source of artifacts used for fetching dependencies. The problem I see defining this in the pom file is that it could have adverse effects depending how the library is being reused.
Use case example:
1) Shared library is created with repository url defined in pom
2) Shared library is deployed. POM file containing url and JAR file are published.
3) Artifact repository is moved, renamed or copied, url is changed.
4) Later on, a new application using that shared library is created, but uses the new repository url. The URL in the application pom is now different from the one in the shared library's previously published pom.
Because Maven uses a dependency graph and inheritance, what I would expect to happen is that when we build the new application:
1) maven will read the application pom file and begin exploring the dependency graph by downloading pom files for each of the application's dependencies from the URL found in the application's pom. In this case, the only download is the shared library's pom.
2) maven will explore transitive dependencies and read the shared library's pom. Reading the shared library's pom, the repository section will take precedence over the application's pom in the context of the shared library's dependencies. The shared library's dependencies poms would be downloaded from the old URL.
3) maven will continue like that and download all the pom files until the dependency tree has been built.
4) depending on project configuration, maven will go through the graph it built to download the jars and etc using the same rules.
In this use case, maven would download artifacts from both the old source and the new source. If the old source no longer exists or isn't accessible in this build context, the project cannot be built. This is why it's best to avoid setting repository urls in a pom file.
Or so I thought.
I wrote a scripted demo with local repositories to show my team exactly what would happen and to my surprise, even though Maven does download the shared library's pom file containing a different repository url, the repository tag does not seem to be overriding the one from the application being built. Logs show all artifacts being downloaded from the source specified in the "top" application pom.
So my question to Stack Overflow is two fold:
1) Why am I wrong? Did I misunderstand Maven's inheritance, dependency graph building and behavior?
2) Shouldn't Maven download the shared library's dependencies from the url specified in the repository tag, if specified? I'm sure there are some cases where the artifacts must come from a private repo. (ex: org.geotools)
3) Does anyone have experience setting up Maven on Azure? Did you follow Microsoft's guide or found a way to move repository urls to your settings.xml in an Azure environment?
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?
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 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?