Not sure about that, I think you’re partially reading the docs… note that “file” is required and is the file you’re deploying… and “files” is a csv list of files as extra side artifacts.
I’ve used this before from CLI and not had this problem, however I’ve never tried doing this from within a POM. I suppose I could cheat and just exec:exec or antrun:run.
If I make it just any release version - it still pushes two artifacts. If I just happen to use the same value as flora-version, it only deploys one. However this is kind of the apex of the problem.. the version of flora is unknown at the start of the reactor build. Attaching the full pom so it’s more clear. But essentially I need to create an instance of a container which has a very esoteric installation of latex and macros. That builds some PDF documentation within the container - however the latex source is inside the container which maps to some version within the container. So after running the container that builds the pdf output - I need to take all those pdf’s and create an artifact from them with a version that matches the flora version in the container. The problem is that Maven makes certain POM properties immutable such that they cannot be changed at runtime. If ${project.version} were able to modified, I could solve this quick an easy. Worst case I assign some bogus release version to my POM and just ignore - but it just seems lame that I can’t make this work the way I need. |
pom.xml
Description: XML document
|
smime.p7s
Description: S/MIME cryptographic signature
