I have a current project which consist out of two independently developed projects:
I do have a Jenkins instance available for building my projects and I'd would like to "marry" both of the projects in a CD job to a single deployable file (.jar)
Is this a job of jenkins, to copy all needed files together? Or is this usually solved with a maven plugin? I couldn't find much information about that, although it seems like a very common step to me.
Ant or Maven are usually used for this. For example, Apache Wicket calls npm and Grunt from within the pom.xml:
<artifactId>wicket-js-tests</artifactId> <packaging>jar</packaging> <name>Wicket JavaScript Tests</name> <description>JavaScript tests for all Wicket modules</description> <execution> <id>install node and npm</id> <goals> <goal>install-node-and-npm</goal> </goals> <phase>generate-resources</phase> <configuration> <npmVersion>5.6.0</npmVersion> <nodeVersion>v8.9.0</nodeVersion> </configuration> </execution> <execution> <id>npm install</id> <goals> <goal>npm</goal> </goals> <configuration> <arguments>install</arguments> </configuration> </execution> <execution> <id>grunt build</id> <goals> <goal>grunt</goal> </goals> <configuration> <!--<arguments> - -verbose </arguments>--> </configuration> </execution> And Apache Freemarker Docgen calls npm and Gulp from within build.xml:
<!-- See README.md about installing node.js and Gulp! --> <target name="node-deps"> <exec executable="npm" dir="${basedir}" failonerror="true" osfamily="unix"> <arg line="install" /> </exec> <exec executable="cmd" dir="${basedir}" failonerror="true" osfamily="windows"> <arg line="/c npm install" /> </exec> </target> <target name="gulp"> <exec executable="node" failonerror="true" dir="${basedir}"> <arg line="node_modules/gulp/bin/gulp.js"/> </exec> <!-- <exec executable="${nodeJsCommand}" failonerror="true" dir="${basedir}"> <arg value="node_modules/gulp/bin/gulp.js"/> </exec> --> </target> References
Q: Is this a job of Jenkins, to copy all needed files together?
Yes, it's. There are a couple of ways you could do this :
Different jobs. One for the backend, a second for the SPA and one more for the assembly.
Jenkins pipelines. It's the same idea than #1 but in a single job. Pipelines are more programmable than regular jobs based on plugins and exportable. If you have support for pipelines I suggest do it this way.
One way or another, Jenkins is a good place to do this marriage.
Q: Or is this usually solved with a maven plugins?
Since you already have both projects decoupled, it wouldn't make much sense to break the decoupling at the end of the SDLC. It's good decoupling projects' builds phases so that they can be built any time regardless of the state of one or another. Well, it's good having decoupled any SDLC.
Nevertheless, if you feel more comfortable with Maven, you could package the SPA into a jar file and add the jar to the backend as a Maven dependency. This sort of dependencies are known as Webjars and they have become fairly common these days. However, it still makes the java project dependent. If I had to choose, I would keep both projects decoupled all the time. If they have to be married, I find preferable to do that somewhere else.
While Maven is very capable of this sort of task, it's not its main reason to exist. Only because it can do it, it doesn't mean we have to do it. That's not the case of Jenkins. Jenkins was designed and built to fulfil this kind of necessities and it does it very well. It has full support from the community. Not to mention the number of plugins and tools we can integrate to meet our CI/CD needs.
