I'm attempting to zip up a directory of minified javascript and css, and then publish it to my local maven repo.
I can't simply publish the artifact, because publishing requires the install task, which is only available if I include BOTH the maven AND java plugin.
Including the java plugin produces a jar file, which I do not want.
I've attempted to use the maven-publish plugin, but it also seems to only want to publish .jar and .war files.
Is there any way to simply zip up my build directory (which only contains minified js and css produced from gulp) and upload it to my local maven repo without involving unneeded plugins?
In this case you can simply declare your own Upload task to accomplish this.
apply plugin: 'maven'
task install(type: Upload) {
configuration = configurations.archives
repositories {
maven {
url "file://${System.getProperty('user.home')}/.m2/repository"
}
}
}
artifacts {
archives archiveTask // replace with name of task that builds you .zip
}
Related
I have a multi-project gradle (version 2.1!!) build consisting of non-java projects.
I would like to deploy the generated artifacts (.tar.gz files) to a Nexus and also to a directory.
Currently I define the repositories in the root build.gradle in the repositories block and also again for each sub-project in a repositories block inside the subprojects in the root build.gradle file.
I apply the base plugin to the root project and the maven-publish plugin to all subprojects that have artifacts to be deployed.
I tried to follow the instructions here:
https://docs.gradle.org/2.1/userguide/publishing_maven.html
https://docs.gradle.org/2.1/dsl/org.gradle.api.publish.maven.MavenPublication.html
https://discuss.gradle.org/t/how-to-have-multiple-uploadarchives/19381/3
How can I make uploadArchives dependent on another task?
and a few more...
but nothing worked. :-(
Here's what I do:
...
# apply the maven-publish plugin only to sub-projects that produce artifacts that should be uploaded.
apply plugin: 'maven-publish'
publishing {
publications {
tarFiles (MavenPublication) {
artifact compressTar
}
}
repositories {
add rootProject.repositories.fsShare
add rootProject.repositories.nexusDeploy
}
}
...
The compressTar is my custom Tar task that creates the artifacts that I want to upload.
When I execute ./gradlew publishTarFilesPublicationToNexusDeployRepository I get the following error:
Execution failed for task ':mySubProject:publishTarFilesPublicationToNexusDeployRepository'.
> Failed to publish publication 'tarFiles' to repository 'nexusDeploy'
> Failed to retrieve remote metadata myRootProject:mySubProject:0.0.0.0-SNAPSHOT/maven-metadata.xml: Could not transfer metadata myRootProject:mySubProject:0.0.0.0-SNAPSHOT/maven-metadata.xml from/to remote (https://myProject.nexus.url:443/nexus3/repository/builds/): Could not get resource 'myRootProject/mySubProject/0.0.0.0-SNAPSHOT/maven-metadata.xml'
When I execute uploadArchives, the task succeeds, but nothing is uploaded anywhere and from the output it looks like the uploadArchives task is only executed for sub-projects that didn't get the maven-plugin applied.
What is the right way to do this? Which plugins should I apply when/where?
Apparently there were two un-related "problems at work" here.
Problem 1): I was not able to publish to Nexus and got a Failed to retrieve remote metadata-error:
Answer 1): I was trying to publish a "SNAPSHOT" to a repository that was configured not to accept "SNAPSHOT" build. Renaming the build version from 1.2.3.4-SNAPSHOT to anything else (e.g. 1.2.3.4-SNAPSHOT-dev or more reasonable 1.2.3.build4`) worked fine.
Problem 2) Publishing to 'flatDir' repository didn't work. The maven-publish plugin didn't create the publish task for it.
Answer 2) To use maven-publish to publish to a directory, flatDir apparently is not recognized as repository the maven-publish plugin can publish to. Defining the 'directory' repository as follows worked fine:
maven {
name "fsShare"
url "/share/pkg"
}
I am using an external gradle plugin called jsonschema2pojo. For that I added the following code inside build.gradle file and I could successfully use that plugin. But I cannot locate the jar that must be downloaded and stored somewhere.
Where do I find the jar that is downloaded for external plugin?
I looked inside ~/.gradle/caches/ folder. For me the caches folder contains the following subfolders:
2.11, 3.3, jars-1, modules-2, artifacts-24, jars-2.
In this project I am using gradle wrapper (with gradle version 2.11) to build the project. So I looked inside ~/.gradle/caches/2.11 folder which contains the following subdirectories:
plugin-resolution, scripts, workerMain.
I was expecting a jar starts with jsonschema2pojo somewhere here, but could not locate one.
buildscript {
repositories {
mavenLocal()
}
dependencies {
classpath 'org.jsonschema2pojo:jsonschema2pojo-gradle-plugin:0.4.29'
}
}
apply plugin: 'jsonschema2pojo'
You will find the plugin .jar file inside the ~/.gradle/caches/modules-2/files-2.1/ folder.
I am using a closed source vendor application that occasionally sends me updates of jars in a zip file.
I want to refer to the zip in the Gradle build, unzip it and publish all the jars within it to my Nexus repo. I am assuming that they all have the same GroupId and that the name and version can be inferred from the file name itself.
Whilst testing out my script, I would rather not publish to Nexus and have to delete lots of test artifacts so I am using a flatDir repo for now.
So far I have this
apply plugin: 'maven'
configurations {
zipArchives
}
uploadResultArchives {
repositories {
mavenDeployer {
flatDir(dirs: 'mvn')
pom.groupId = 'com.stackoverflow.example'
}
}
}
artifacts{
zipArchives file: file('unzipdir/api-1.2.34.jar')
}
This suffers from multiple problems.
It requires me to manually add the files to the artifacts list
It creates a pom with dependencies from the rest of my project instead of a pom with no dependencies
I haven't parsed out the versionId yet
This solution looks like the versionId is going to be the same for all
Is there a better way to approach this?
I have a gradle build with many subprojects. One subproject generates a WAR and needs to include xhtml files from ui-module subprojects that will be included in the WAR. At the moment I search for the ui-modules programatically and copy the files. But I was wondering if I could solve it with a separate configuration.
I want to generate zip files with the xhtml files into the configuration uiModule as artifacts. Later the artifacts should be unzipped into the war. My build.gradle for the ui-modules looks like this
configurations {
uiModule
}
task zipXhtmlFiles(type: Zip) {
from 'xhtmlResources'
}
artifacts {
uiModule zipXhtmlFiles
}
The war should access the xhtmlFiles like this
apply plugin: 'war'
dependencies {
uiModule project('someUiModuleProject')
}
war {
//unzipping will be done later
from configurations.uiModule.allArtifacts
}
However, when I create the war, the zipXhtmlFiles is not executed and when I print the arifacts they don't contain the zip files. Can this be solved without writing an extra task class? Am I getting something wrong?
I am slowly moving two projects over to Gradle. Project A produces a jar file that is used by Project B.
Project A is a GWT component and Project B is a GWT application.
How do I get Gradle to generate a Jar that contains the Java source code of Project A rather than the compiled classes?
I have tried adding the following to the build.gradle file, but this generates a second Jar file containing the source - I want the main artefact to contain the source, so that it is published to my local Maven repository when I run the install task.
task sourceJar(type: Jar) {
classifier = 'sources'
from sourceSets.main.allSource
}
artifacts {
archives sourceJar
}
Is there a way to override the standard Jar creation task?
You can define your own 'myArtifacts' configuration and publish that instead. Note that since the install task is of type Upload, you should be able to change the default artifacts configuration from archives to sourceArchives:
configurations{
sourceArchives
}
artifacts{
sourceArchives sourceJar
}
install.configuration = configurations.sourceArchives
Hopefully, install should now just publish members of sourceArchives configuration.