No, it's a pure Maven plugin for building WebObjects and Project Wonder applications and frameworks.
"Pure Maven" means it does not use the WOProject Ant Tasks which means it runs faster and makes it easier to improve both the plugin and the build process. It's close to a drop-in alternative to the WOLifecycle Maven Plugin, although with some differences (listed below).
vermilingua
has seen production use for years in multiple
applications and frameworks (including a fork of Wonder) and can
be considered stable and safe to use.
Replace the wolifecycle-maven-plugin
<plugin>
element in your
pom.xml
with vermilingua-maven-plugin
:
<plugin>
<groupId>is.rebbi</groupId>
<artifactId>vermilingua-maven-plugin</artifactId>
<version>1.0.3</version>
<extensions>true</extensions>
<!-- Configuration only if you're using the old 'resources' name for the resources folder
<configuration>
<woresourcesFolderName>resources</woresourcesFolderName>
</configuration>
-->
</plugin>
There are several optional parameters.
woresourcesFolderName
: provided for compatibility with
wolifecycle-maven-plugin
. Without it, vermilingua
defaults to
src/main/woresources
for WebObjects bundle resources, rather than
src/main/resources
, allowing that folder to serve it's designated
standard Maven purpose, which is to keep Java classpath resources.performSplit
: when set true
, vermilingua
will generate an
additional "WebServerResources" bundle for "split deployments".wolifecycle-maven-plugin
There are some features in wolifecycle-maven-plugin
that are not
supported at all.
.patternset
files (in the woproject
folder)..framework
bundles: only generates Maven-style JAR frameworks.flattenComponents
configuration parameter: any folder structure in
src/main/components
is flattened, as WebObjects doesn't know how
to locate components in sub-folders at runtime anyway.flattenResources
configuration parameter: it's not clear what the
use case is for this parameter, as WebObjects can find other
resources in sub-folders at runtime.Other differences include:
src/main/woresources
rather than src/main/resources
(which is
now reserved for Java classpath resources As God Intended).${build.finalName}
(set in the POM)
will only affect the name of the WOA folder. The insides of two WOAs
made from the same project, but compiled with different
finalName
s, will look exactly the same.