I have a multi-module Gradle project (which generates 3 artifacts per module, the sources, javadoc, and main jar). I need to generate a .pom file for my project for use with the Maven Deploy Plugin which is installed on an image that Gitlab CI uses. I have a (WIP) script which generates a .pom file with gradle, but I'm unsure of exactly where or how many .pom files I need for all of my modules.
Questions:
Where exactly should I be generating a .pom file(s) so that the
Maven Deploy Plugin can see it when I run mvn deploy:deploy in the
Gitlab yaml file?
Do I need a separate .pom file for each group of module artifacts?
Any help would be appreciated! Especially some sort of example of someone generating a .pom file with Gradle and then deploying with the Gitlab CI.
I have a Non-Java Maven project. By default the deploy goal generates a JAR file, however I would like to generate a zip file instead that should be published to nexus at a later phase.
If I create the zip file manually and place it in the target folder, Maven is not publishing it to nexus, it only publishes the JAR file automatically created.
So my question is: Is there any way to upload to nexus all the content of the target folder? If not, how do I tell Maven not to create a jar file and create a custom zip instead?
Maven has the deploy:deploy-file goal which can be configured in your pom.xml It can be used to upload arbitrary files, including zips.
You can avoid the creation of a jar if you change <packaging> to pom.
I have been uploading maven web projects artifacts with Jenkins CI to artifactory.
There is a .pom file along with the .war artifact.
Images
For .pom file for first version
For war file of first version
We can see that pom file "produced by" column displays total build info and for "war" it points accurately which build produced it.
So is there a way out to know who has created the .pom file?
My interest lies in knowing the details about non-artifact files(here it's a .pom it can really be anything from .txt to .zip!)
For "non arti-facts" as you mentionned (zip, html, mp4,...) you can use the JFrog cli to resolve things from artifactory as dependencies and publish them as generated artifacts and then publish the build information oject generated by the cli to artifactory. You can have a look to the documenatation here : https://www.jfrog.com/confluence/display/CLI/CLI+for+JFrog+Artifactory#CLIforJFrogArtifactory-CollectingBuildInformation
I'm currently facing an issue with the execution of my MUnit tests using the command line.
I'm facing a problem of "duplicate project artifact assignment" Using version 1.2 of mule-domain-maven-plugin that was fixed here with version 1.3. Removing this line of code causes FileNotFoundException on mule-domain-config.xml when running my MUnit.
After decompiling the code, I can see that 1.2 (which works with my MUnits), has 2 lines of code :
this.projectHelper.attachArtifact(this.project, "zip", domain);
this.project.getArtifact().setFile(domain);
I can see that 1.3 has only this line :
this.projectHelper.attachArtifact(this.project, "zip", domain);
Does anybody know the difference between this.projectHelper.attachArtifact(this.project, "zip", domain); and this.project.getArtifact().setFile(domain); and how to resolve this issue?
The difference is the same as the difference between the main artifact and attached artifacts.
First of all, an artifact is, put simply, an object containing the Maven coordinates pointing to it (group id / artifact id / version / classifier / type), a repository where to resolve it or where it was resolved, and a file, which is the actual concrete file to use / download / upload.
Except for POM projects, a Maven project generates a single main artifact. It depends on its packaging; for example a project with a packaging of jar will create a main JAR artifact whose file contains all the classes of your project, and a project with a packaging of war will create the web application. Furthermore, the project itself is tied to its POM file; this means that a project, not only has a file for its main artifact, but also has reference to the POM file that created it. It is only for projects of packaging pom that no main artifact will be created; this is because such projects are parent or aggregator projects, containing build logic to be shared between multiple projects, but they do not produce a main deliverable.
In addition to this, a project has attached, or secondary, artifacts. They correspond to additional artifacts that are also generated during the build of a project, and differ from the main one by their classifier and/or type, and, naturally, their actual file. Those additional artifacts are installed and deployed alongside the main one. As an example, a typical project of packaging jar would also generate its Javadoc and Sources as a JAR file as attached artifacts having the classifier javadoc and sources. It follows that a project of packaging pom can only have attached artifacts, since it has no main artifact. Finally, it is perfectly allowed to have a project without attached artifacts; only the main one (or none at all in case of a pom project) would get deployed.
Inside a Maven plugin, all those considerations comes down to the following:
The main artifact of a project is retrieved with project.getArtifact(), as an Artifact.
project.getArtifact().setFile(...) sets the actual file of the main artifact of the project. Again, for a project of packaging jar, this would be the actual JAR file that was generated on-disk. Concrete example: it is what the Maven JAR plugin does.
The MavenProjectHelper component is used to attach artifacts to the project. projectHelper.attachArtifact(project, "zip", file); would attach an artifact of type ZIP to the given project, with no classifier, and whose file is the given file. There is an overload to attach an artifact with a classifier. Concrete example: it is what the Maven Assembly Plugin does when it is configured to attach the artifacts it produces.
project.setFile(file) sets the POM file of the Maven project that created it.
To give examples, we can consider the artifacts deployed under org.mule.tools.maven in Central. Under the artifact id mule-maven-plugin, there are multiple files:
mule-maven-plugin-2.1.jar is the main artifact file,
which was created by the POM file mule-maven-plugin-2.1.pom,
while mule-maven-plugin-2.1-javadoc.jar and mule-maven-plugin-2.1-sources.jar are attached with their respective classifier.
As second example, consider the artifact id mule-esb-maven-tools. The only file deployed (except for the hash files) is mule-esb-maven-tools-1.1.pom. This is perfectly normal since it's a POM project, so it has no main artifact (there are no JARs or other deployed); there's only the POM file of the project, with no attached artifacts.
Is there a way to force artifactoryPublish task to publish the jar file first and then the pom file ? Or make pom file visible to others only when jar file is available.
We have multiple Git repositories where the jars are shared across the repositories. The Hudson build for them is triggered almost at the same time. So we have hit this case of gradle finding the pom but not the jar; But when we try to look into artifactory we see both. Just that we see jar gets uploaded couple of seconds later than the pom.
What is the best way to solve this (other than changing the time when Hudson build triggers).