I cannot find in gradle docs which artifacts are uploaded by default. Is it so, that only compilation artifacts are uploaded? I have a case where I'm left with multiple jars in workspace after build process and I wanted to make sure that no garbage is uploaded.
I found info that in case of multiple artifacts I can define addFilter() but what about main artifact upload? How gradle determines which jar is uploaded by default?
I'd appreciate clear information and if someone could point me to documentation that I missed.
I cannot find in gradle docs which artifacts are uploaded by default
Gradle does not upload anything for you. You must configure whatever publishing plugin you are using with the artifacts you want published.
The official publishing plugins are:
Maven Publish
Maven Plugin (deprecated)
Neither of these plugins publish anything by default.
I have a case where I'm left with multiple jars in workspace after build process
This is normal. However, if you are seeing artifacts that should not created, then you'll need to audit your Gradle build to see how that artifact is being created and disable it if needed.
There is (1) official Gradle plugin that I am aware of that does configure the above plugins to publish an artifact. This is documented on at the very bottom here: https://docs.gradle.org/current/userguide/java_gradle_plugin.html
Related
I have a maven module which is configured with a feature packaging (an Apache Karaf feature). This project has no primary artifact to deploy but an attached feature.xml file. When I try to deploy the project to Github package the upload seems to work:
Uploaded to github: https://maven.pkg.github.com/cdelg-ct/repo/com/mycompany/app/my-mod/1.0-SNAPSHOT/my-mod-1.0-20200701.090836-1-features.xml
But then, the above file does not show up in the Github Packages UI and other projects cannot depend on it (Could not find artifact). Note the pom is well deployed as the other sibling jar modules.
Did anyone manage to get classifier to work with Github Maven Packages?
You are using a SNAPSHOT version.
By default, SNAPSHOT versions are not fetched.
Quick way to check it, try a release version.
If it works, you have to configure your maven settings to allow spapshots versions.
I'm building a multiplatform javafx application. The final process is to create an installer (exe,dmg,deb.. with jre bundled) and upload it to a special "product release" repo. Given how javafx build needs to be done, it runs an jenkins matrix job on 3 different platforms. The last step is the deployment. I attach the installer with the build-helper-maven plugin.
I'm able to upload the installer correctly for one platform, but because the deploy seems to upload the pom file, it cannot be uploaded again from another jenkins slave.
First I was having problem of maven uploading the "main jar", but I managed to disable that by binding the jar plugin to 'none' phase (I use the maven-javafx-plugin which creates own main jar). However I'm unable to disable the pom generation and uploading. I have set
<generatePom>false</generatePom>
for the maven-deploy-plugin but it seems to not have any effect (I assume it works for the main jar which I have already disabled).
Is it possible to disable the pom generation/upload completely (similar like gradle's 'uploadDescriptor false' option) and only upload 'attached artifacts' ?
EDIT/NOTE: I probably try the deploy file option next, https://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html, but it would be nice to know if this can be done on the complete project level
I managed to solve this. I did it with the deploy-file option:
I bound the default-deploy to none in order to disable it. Then I made new "native-deploy" execution which I bound to deploy phase. In it's configuration I put the generatePom false and pointed the file to the same I was earlier using to attach it as side artifact (via the build helper plugin). I did have to put the coodrinates again (i.e. passtrough from project.*). But did work and uploaded the installers from all machines without any pom files. I did have to re-enable the default jar creation because maven complained that there is no artifact bound (I guess I could change the packaging to be pom, anyway it is not uploaded because the default upload is disabled so ok there).
I guess if there is more general solution it would be more correct answer but for me this is enough.
I'm running Nexus and I have a snapshots Maven repository. When I publish artifacts to that repository I also run a "Rebuild Maven Metadata Files" type task that runs for about 5 minutes and updates "LATEST" to actually point to the newest artifacts. Can I update that LATEST reference some other way? I publish with Gradle. Can Gradle just update that specific groups metadata?
Thanks
The maven metadata file is NOT managed by Nexus but by the client side tool. By default that is Maven and it downloads the metadata file as part of the deployment, updates it with the new snapshot data and uploads it again.
Potentially Gradle does not do that correctly and that is the reason you have to use the workaround of using the Nexus scheduled task. I don't think Gradle has any further tools to fix it up better. The only thing I can think of you could do is to kick off the scheduled task from Gradle automatically. But you would still have the timing problem.
Best would be to file a bug against Gradle and get it fixed.
I am having issues with hosting maven jars with Github (site-maven-plugin) so I want to move with Bintray asap.
What are the steps to host a existing maven jar in bintray?
Here is my error when doing: mvn releae prepare
Caused by: org.apache.maven.shared.release.ReleaseFailureException: You don't have a SNAPSHOT project in the reactor projects list.
What I have now is I can do mvn clean install with no problems at all. Can I just upload the files under ./m2 repo? I basically uploaded the .jar and .pom I found in the maven repository.
How can I access the library I uploaded on Bintray from my pom.xml?
You can get started with publishing from Maven to Bintray by copy-pasting some pom parts from "Set Me Up" guide:
Full user manual is available as well.
Please note, that you can't upload SNAPSHOTs to Bintray. It's a distribution platform and it is not intended for development process.
Saying that, you are welcome to take advantage of a free Artifactory account for hosting your snapshot during development.
Using OJO you don't need to use the troublesome Maven Release Plugin anymore. Once you're satisfied with the snapshots quality you can promote them to be releases and upload them to Bintray in one REST call (or click of a button in Jenkins),
Is it possible to deploy arbitrary zip archive artifacts to Nexus through Maven as snapshots?
We have a build step that is not supported through any application-specific Maven plugin. Instead, our full build and deployment process is as follows:
1) Maven POM compiles the Java component of the build, using Jenkins.
2) Shell script calls create a deployable artifact shell scripts were wrapped around calling a code generation application, which are then zipped up into an archive by the application itself. I need these artifacts deployed to Nexus as both snapshots, and as releases as appropriate.
I tried using the maven-assembly-plugin however this assumes that the plugin itself is creating the zip archive, not simply deploying an archive that was produced by some other method.
I would prefer to do this within Maven since our Nexus settings and credentials are already within the environment and do not need to be passed manually on the command line. Using the Nexus UI for this is not a viable option since this needs to be part of a standard build-deploy-test process, which may happen many times per day, for a couple dozen applications.
For completeness, I'm answering my own question (oh bother...)
I resolved this issue by using the maven-assembly-plugin, which allows you to define arbitrary artifacts, and deploy them (snapshots or releases) to Nexus. The assembly plugin uses a bill of materials (src.xml) that defines the exact contents of the artifact (either including or excluding files, directories, changing file permissions, etc). This can also be used for creating Java uber jars, but it appears that using the Maven Shade Plugin is the preferred method for creating uber jars.
Maven Assembly Plugin main webpage