Context:
We use a third-party maven plugin to compile lesscss into css
(lesscss-maven-plugin)
We cannot modify or update this plugin.
We cannot switch to another plugin, use grunt, or any other build
tool.
The plugin allows us to specify a JS file as a workaround to
upgrading the plugin itself.
Currently we have to have a copy of the
file included with each and every project
Question:
How can the JS file be packaged and a build/compile time dependency defined in the POM so that the file can be shared across projects easily?
Is it possible to use a URL for the file path instead of the {project.basedir}?
Example POM Snippet:
<plugin>
<groupId>org.lesscss</groupId>
<artifactId>lesscss-maven-plugin</artifactId>
<version>1.3.0</version>
<configuration>
<sourceDirectory>${project.basedir}/src/main/resources/less</sourceDirectory>
<outputDirectory>${project.basedir}/src/main/webapp/css</outputDirectory>
<compress>true</compress>
<includes>
<include>example.less</include>
</includes>
<lessJs>${project.basedir}/src/main/webapp/lib/less-1.7.0.min.js</lessJs>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
Related
I have a problem while processing .xsd file during my maven build.
I use jaxb2 plugin but I have to download external dependiencies from my .xsd files. The problem is that these dependencies (.xsd) are from enviroment which is unstable and very often my build fails because maven cannot download xsd file. How to configure jaxb plugin to force him to try download xsd few times to prevent build failure?
Part of my pom.xml configuration:
<plugins>
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<configuration>
<strict>false</strict>
<extension>true</extension>
<args>
<arg>-Xfluent-api</arg>
<arg>-XtoString</arg>
<arg>-Xsetters</arg>
<arg>-XenumValue</arg>
</args>
<plugins>
<plugin>
<groupId>net.java.dev.jaxb2-commons</groupId>
<artifactId>jaxb-fluent-api</artifactId>
<version>${jaxb.fluentapi.version}</version>
</plugin>
<plugin>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics</artifactId>
<version>0.9.3</version>
</plugin>
</plugins>
<bindingDirectory>src/main/resources/jaxb</bindingDirectory>
<bindingIncludes>
<include>bindings.xml</include>
</bindingIncludes>
<schemas>
<schema>
<fileset>
<!-- Defaults to schemaDirectory. -->
<directory>${project.basedir}/src/main/resources/orbeons</directory>
<!-- Defaults to schemaIncludes. -->
<includes>
<include>*.xsd</include>
</includes>
</fileset>
</schema>
</schemas>
</configuration>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.basedir}/generated-sources/orbeons</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
Author of the maven-jaxb2-plugin here.
You have two parts here: managing the downloads of external resources and compiling the schemas, rewriting "external" links to local files.
The first (managing downloads) is not in the scope of the maven-jaxb2-plugin, the second is supported with
catalogs.
In short, you can create a catalog file like this:
REWRITE_SYSTEM "http://www.w3.org" "w3c"
Or this:
REWRITE_SYSTEM "http://schemas.opengis.net" "maven:org.jvnet.ogc:ogc-schemas:jar::!/ogc"
And use this file to "rewrite" absolute links to local files or resources within Maven artifacts:
<configuration>
<catalog>src/main/resources/catalog.cat</catalog>
</configuration>
As for the first part, I don't think managing downloads with retries, continuations and all other stuff should be in the scope of the JAXB2 Maven plugin.
ps. You don't need build-helper-maven-plugin/add-source with maven-jaxb2-plugin, source directory is added automatically.
Apparently the maven-jaxb2-plugin does not support such a feature. (And neither does the maven-download-plugin nor even the maven-dependency-plugin).
Three solutions come into my mind at the moment (plus two and a half inspired by LIttle Ancient Forest Kami's comment) [Numbers reflect the precedence of what I would do]:
Use a CI tool (Jenkins, etc.) that supports retry on job failure. [1]
Handmade:
Use the GMavenPlus plugin with a script ... [2]
Use the Maven AntRun plugin with a script ... [3]
Use the Exec Maven plugin with a program ... [5]
... that performs the download and retry and bind it to the generate-resources phase in your project's POM.
Create a Maven plugin with appropriate parameters (url, outputDirectory, retryCount) that uses the maven-download-plugin and performs the retry. Bind its goal to the generate-resources phase in your project's POM. [4]
Create a check-download Maven project that uses the maven-download-plugin bound to the generate-resources phase to download the .xsd. [6]
Create a shell script that contains the following (in pseudo code):
download:
counter++
<check-download project>/mvn generate-resources
if error and counter < maxRetryCount goto download
if not error
<your project>/mvn ...
else
display appropriate error message
There is also a question Maven download retry? from 2005. Unanswered.
actually, I generate a maven site containing the documentation of my project. It works very well, in fact if works so well that my customers wants to get that site as a deliverable (for obvious documentation purpose).
How can I tell Maven to build a zip of the whole site and deploy it to my artifacts manager (Nexus)? I've tried several things, but if I understand correctly, deploying artifacts and generating the site are using different livecycle, and the site generation occurs after the deployment of the artifacts..
I could obviously get the generated site from the location it's deployed during site-deploy, but I would greatly appreciate an automatic and centralized way...
PS: giving access to the customer to our internal site is NOT an option.
Here is a working solution delegated to a Maven profile to isolate the behavior (and speed-up normal builds), but which could also be integrated in the default build if required (although not recommended).
<profiles>
<profile>
<id>site-zip</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.4</version>
<executions>
<execution>
<id>pack-site</id>
<phase>prepare-package</phase>
<goals>
<goal>site</goal>
<goal>jar</goal>
</goals>
<configuration>
<attach>false</attach>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.coderplus.maven.plugins</groupId>
<artifactId>copy-rename-maven-plugin</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<id>rename-file</id>
<phase>prepare-package</phase>
<goals>
<goal>rename</goal>
</goals>
<configuration>
<sourceFile>${project.build.directory}/${project.build.finalName}-site.jar</sourceFile>
<destinationFile>${project.build.directory}/${project.build.finalName}-site.zip</destinationFile>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<goals>
<goal>attach-artifact</goal>
</goals>
<phase>package</phase>
<configuration>
<artifacts>
<artifact>
<file>${project.build.directory}/${project.build.finalName}-site.zip</file>
<type>zip</type>
<classifier>site</classifier>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
What the profile is actually doing:
Configuring an execution of the Maven Site Plugin, attached to the prepare-package phase and running the site and jar goals (as also suggested by #khmarbaise).
Renaming the file from jar to zip via the Copy Rename Maven Plugin
Attaching the zip to the build via the Build Helper Maven Plugin and its attach-artifact goal
As such, running
mvn clean install -Psite-zip
Will also install in your local Maven cache the zipped site. The deploy phase would do the same on your target Maven repository then.
Note that the Maven Site Plugin and the Copy Plugin must be declared in the order above to follow the required flow within the same phase.
Also note that if zip is not a strong requirement, you can then just skip the Copy and Build Helper executions and only use the Maven Site execution. By default the jar created providing the site is already attached to the build (and hence it will be installed and deployed automatically). In order to have the zip, we had to disable this behavior (<attach>false</attach>) and re-attach it via the Build Helper plugin.
The generated zipped has automatically a classifier, which is site in this case.
You can use the maven-site-plugin.
Currently our maven build includes all the dependencies in the jar, using jar-with-dependencies.
We want to split this into two separate jars, one with the project application code and files, and one with the dependencies.
How is this done?
Thanks
This is done using the maven Assembly plugin
http://maven.apache.org/plugins/maven-assembly-plugin/
Use the maven-shade-plugin instead with following configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.1</version>
<configuration>
<finalName>${project.artifactId}-${project.version}-libs</finalName>
<artifactSet>
<excludes>
<exclude>${project.groupId}:${project.artifactId}</exclude>
</excludes>
</artifactSet>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
The trick is to define a specific final name. This avoids the replacement of the default jar, which is packaged by the maven-jar-plugin. The default name is ${project.artifactId}-${project.version}. So simply add a suffix like libs. Then exclude the artifact itself, because the classes should not be packaged twice.
The build will result in two jar files:
${project.artifactId}-${project.version}.jar, containing the classes and files of the project
${project.artifactId}-${project.version}-libs.jar, containing the content of all the dependencies
We have a common set of XSDs (datatypes, vocabulary, etc.) we're generating with the jaxb2-maven-plugin in its own Maven project. In a second project, I need to refer to one or more of those XSDs at compile time but don't want them included in the resulting artifact. I've created a catalog file, which works fine except I get everything in it.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<goals>
<goal>xjc</goal>
</goals>
</execution>
</executions>
<configuration>
<outputDirectory>${basedir}/src/main/java</outputDirectory>
<target>2.1</target>
<catalog>catalog.cat</catalog>
</configuration>
I've pored over the plugin docs, but they're woefully light on detail. Is there any way to get reuse out of common schemas without every project having to take a copy of them?
Thanks
This is something my maven-jaxb2-plugin can do:
Compiling schema from Maven Artifact
The documentation site is currently very unstable so here's snippets of the documentation.
<configuration>
<forceRegenerate>true</forceRegenerate>
<schemas>
<schema>
<dependencyResource>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin-tests-po</artifactId>
<!-- Can be defined in project dependencies or dependency management -->
<version>${project.version}</version>
<resource>purchaseorder.xsd</resource>
</dependencyResource>
</schema>
</schemas>
</configuration>
Here's a sample project.
I'm using mvn compile to compile my Maven webapp. This project has a resources folder instead of the java folder created for a .jar project. My problem is that mvn finds no sources, and I haven't find a way in the maven docs to proceed this way. Is there a way, either by mvn command options or by pom.xml modification to make mav aware of the resources folder and compile it?
I know changing the name from resources to java makes the deal, but that's a spureous way to proceed.
To include additional source directories in your project you can use the Build Helper Maven Plugin
So for example the following configuration will add the src/main/resources folder of your project as a source folder.
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${basedir}/src/main/resource</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Look at your .classpath file. That should have what folders including src and test are added. You can then add additional resources. I would normally use the IDE to look at the build path and add/exclude resources.