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
Related
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?
I have a Spring Integration requirement , where I need to externalize the libraries and properties file from my war file. I am able to achieve this through Maven assembly plugin, where i create a zip file which may contain
lib/*.jar
properties/{artifactId}/*.properties
The reason I am adding the artifact Id to the path is, I will be creating 100s of wars in future and would need to distinguish between them.
This wars will not contain Web.xml and the Initializer is part of one of my libraries file.
THe Initializer should know the artifactId in order to load the correct properties.
With maven, the maven artifact details gets published to
META-INF/maven/${groupId}/${artifactId}/pom.properties
META-INF/maven/${groupId}/${artifactId}/pom.xml
If I could move these files to
META-INF/maven/pom.properties
META-INF/maven/pom.xml
My application would be able to read the artifact id from pom.properties.
I need help in achieve this.
Or if there are any other approach please help in solving the issue.
The Maven archiver component does that: see here at addMavenDescriptor element. It doesn't seem to be possible to customize the paths of these files.
But I guess every property you need can just be placed in a specific file and so you just have to create a resource file (properties like) containing all the information you want and let Maven filter that file for you.
I want to know how can I add metadata for an artifact which I want to push to nexus repository.
Can I define the metadata in POM file. Is there any tags in pom for doing this?
If adding through POM is not possible what are the other ways to do this?
There are three ways you can do it imho.
Add properties right in the pom. The problem I see with that is that you can not inspect the values easily in Nexus or search on them.
Add another file that is a properties file as an attached artifact with the Maven build helper plugin. That way they are in a separate file that can be parsed a bit easier than a Maven pom. Otherwise the same problems from 1. are there.
For both of these approaches you could create a custom Nexus plugin that shows that information somehow.
If you are using Nexus Professional you can activate the Custom Metadata plugin and use the approach described on the support site to get the properties into Nexus. Then you can also use search and so on to find specific components based on their metadata.
A simple way to do it is to add a <properties> tag with different properties holding your metadata.
<properties>
<my.name>The King</my.name>
<my.goal>Bring joy to my people</my.goal>
</properties>
You can put in anything you want and it will be in the pom put under Nexus.
I hope this helps.
What is the preferred way for a maven plugin to process Xml files (external, not the pom) and possibly map them to objects? (e.g. using perhaps the same "technique" like for the configuration via #Parameter)
Where can I find some good examples?
Thank you,
Alex
The way the maven plugins do this, by indirectly using the maven-modello which can be used of course separately without any relationship to maven, cause it's a different view which supports different versions etc. of a model instead in comparsion to things like JAXB etc.
The documentation of the modello model will give a good impression of what is possible.
Other plugins for example the maven-assembly-plugin are using the modello model to parse external xml file.