5

I like to generate images from .puml files in a maven project.

What i do not like to archivee is a hard binding between the project and the library that generates the images. So I like to use this build command:

mvn com.github.jeluard:plantuml-maven-plugin:1.2:generate \
  -Dplantuml.outputDirectory=target \
  -Dplantuml.sourceFiles={*.puml}

So the third line fills the sourceFiles-class-variable

Unfortunately the syntax {*.puml} seems to be wrong:

[INFO] --- plantuml-maven-plugin:1.2:generate (default-cli) @ test ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.047 s
[INFO] Finished at: 2018-02-16T14:50:09+01:00
[INFO] Final Memory: 8M/245M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.github.jeluard:plantuml-maven-plugin:1.2:generate 
        (default-cli) on project test: Unable to parse configuration of mojo 
        com.github.jeluard:plantuml-maven-plugin:1.2:generate for parameter sourceFiles: 
        Cannot find default setter in class org.apache.maven.model.FileSet -> [Help 1]
Grim
  • 1,938
  • 10
  • 56
  • 123
  • Is there a good reason why you are using curly braces? Have you tried to use use `-Dplantuml.sourceFiles=*.puml`? – khmarbaise Feb 16 '18 at 19:52
  • @khmarbaise There is no *good* reason, I think I remember days I used it that way - but obviously I am wrong. I keep those braces because they look so special that others focus (like you) on that part of the question. Yes, I tried to use the parameter without curly braces, but I had no success. – Grim Feb 17 '18 at 07:34

1 Answers1

-1

It is better to specify the source fileset through a pom.xml, and specify that file through -f: mvn -f mypom.xml.

See jeluard/maven-plantuml-plugin Usage:

<build>
  <plugins>
    <plugin>
      <groupId>com.github.jeluard</groupId>
      <artifactId>plantuml-maven-plugin</artifactId>
      <version>1.2</version>
      <configuration>
        <sourceFiles>
          <directory>${basedir}</directory>               <=======
          <includes>
            <include>src/main/plantuml/**/*.txt</include> <=======
          </includes>
        </sourceFiles>
      </configuration>
      <dependencies>
        <dependency>
          <groupId>net.sourceforge.plantuml</groupId>
          <artifactId>plantuml</artifactId>
          <version>7999</version>
        </dependency>
      </dependencies>
    </plugin>
  </plugins>
</build>
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thats the hard binding I do like to avoid. – Grim Feb 20 '18 at 17:52
  • @PeterRader But it is not an "hard binding": you can generate that custom pom.xml with the exact *.xml you are after, and use it in your maven command. – VonC Feb 20 '18 at 20:35
  • Where to place that xml? – Grim Feb 21 '18 at 09:57
  • @PeterRader anywhere you want, that is why it is not an "hard binding": this is a more verbose way to specify your ` -Dplantuml.sourceFiles={*.puml}` – VonC Feb 21 '18 at 09:58
  • Well, the pom specified by `-f` must be non-remote. So a `http://wiki:8080/wiki/plantuml/mypom.xml` will not work. The file must be local. The file therefore must be local on the builder's system, so on every development machine who like to see the PlantUML images, maybe with different locations. Every change must be reported to all developers if something is changed. This might not be a good solution. All that because of a leak of the maven-plugin? There must be a better way. – Grim Feb 21 '18 at 10:14
  • @PeterRader Why not distributing a build script which will curl the latest definition of that pom.xml, copy it locally, and use it in the mvn command? – VonC Feb 21 '18 at 10:16
  • So I guide all developers to curl that pom before build images, some windows machines does not have curl, either they download changes manually or install curl-for-windows. Some are not allowed to download new software and need authentication for the wiki, I could modify the security rules of the company. Do you think it is a good way to do it? – Grim Feb 21 '18 at 10:34
  • Even simple: distribute that script and custom pom.xml with the source of the project. No more curl or download. – VonC Feb 21 '18 at 10:50
  • My point is: you cannot specify a first in command line. I am not saying my workaround is ideal, but I am just trying to help here, and this should help you moving forward. – VonC Feb 21 '18 at 10:52
  • @PeterRader to my last comment: I meant: "you cannot specify a *fileset* through command-line", hence my workaround proposition. I was typing that on my phone ;) – VonC Feb 21 '18 at 12:08
  • Ah you are a phone-hacker, solving other people's problems on the work from/to work/work(fka home). I tried to solve other people problems that way too and decided to dont do that because of ... you know mistakes ;). Anyway I recognize your enthuisasm. To the problem: to distribute a custom pom.xml (lets call it mypom.xml) with the project is a good idea. Even tho it makes sense to merge the pom.xml and the mypom.xml to have 1. reduce the amount of files in the project and therefore the complexity of the project and 2. bind the concrete implementation hard into the project. – Grim Feb 21 '18 at 12:33
  • @PeterRader You could merge it indeed, and have it inside your main pom.xlm as a profile, to be activated only your build script (if you want to be ableto call `plantuml-maven-plugin:1.2:generate` separately from a classic `mvn build`) – VonC Feb 21 '18 at 12:36
  • @PeterRader Note: despite the downvote, this is still a good solution. – VonC Feb 22 '18 at 13:24