We have been working hard over the past few weeks on the latest set of changes Jive's Maven archetype, which I am happy to highlight here.
Each time a new major version of Jive has been released (5.0, 6.0, 7.0) we have created a new version of our Jive Maven archetypes. This has allowed for the easy inclusion of modules or elements specific to that new version. Additionally, the archetypes have been never really been released, and have been left as SNAPSHOTs. This has enabled developers, each time they create a new project or plugin, to get the most recent version of of the archetype, along with any fixes or improvements therein. Honestly, this has always felt a little weird. While it makes sense from a practical standpoint, we're not really following any best practices by doing so. We didn't want anyone to miss out on the latest just because they got the version number of the archetype wrong, specifying version 220.127.116.11, for example, when there's a really great fix in 18.104.22.168.
That's all changing today, with our new jive-maven-unified-archetype (and jive-maven-unified-plugin-archetype). The unified archetype will support both 6.x and 7.x Jive projects. It will also be versioned with each change. But that's ok because we are also releasing a new Jive Maven Plugin, called jive-project-plugin. With a few tweaks to your settings.xml file, you'll now be able to create a new custom project without ever dealing with the archetype directly, or knowing the name of its latest version.
You'll now be able to create a project simply by running the following on the command line:
mvn -U jive:create-project
or a new plugin with:
mvn -U jive:create-plugin
You will then be asked questions regarding the kind of project you want to create, including:
- Jive version (and, yes, EAE and Search versions will be changed accordingly)
- Project group ID
- Project artifact ID
- Instance type (internal or external)
It's all detailed in How To: Create a Custom Jive Project. We definitely welcome your feedback should you experience any problems using it, or have any suggestions for improvement.
Historically, custom themes have lived in the web module, in the /src/main/themes directory, of our maven-jive-archetype. This has worked pretty well to this point, but changes we have made to our build environment at Jive dictated that we make a change. Under the new jive-maven-unified-archetype, themes have been moved out into its own module, as a peer to the web module.
We have worked on a number of customer projects lately that have consisted of only Jive plugins and custom themes, with no custom WAR (which is a good thing!). However, with the themes tied to the web module, that meant that we always had a WAR artifact to deploy to Maven, empty or not. That's over 100MB per deployment. Over time, and with all our customers, that amounts to a ton of wasted space. Now, when you build your project, the themes module will produce its own binary artifact, themes-<version>.zip
EAE and Search
The run-services module has had an awkward existence since its creation in the 6.0.x version of the maven-jive-archetype. If you leave it as a module, referenced in the root POM, it gets built and potentially deployed to Maven upon release. To avoid this, we have made a couple changes to prevent this.
- run-services is no longer a module in the root POM
- The <parent> reference to the root project has also been removed from the run-services POM.
- <eae.version> and <search.version> properties have been moved from the root project to run-services.
These changes give the run-services project a sort of transient existence, in that it's still useful when running your Jive instance locally, but will never be built or deployed if you leave things alone.