I'm using Maven and its assembly plugin to build a distribution package of my project like this:
one project assembles a basic runtime (based on Felix), with the appropriate directories and bundles, in a ZIP file.
third-party libraries are collected in one project each and either converted to OSGi bundles or, if they are already OSGi compatible, they are just copied
my own project consists of several modules that are built into OSGi bundles, too.
Now, I'm adding another project that unpacks the ZIP, drops all the other JARs into the proper directories, and repackages it for distribution. Now, my bundles might contain configuration files that I want to merge into, rather than replacing, identically named ones in the runtime assembly. How do I do that?
The files are plain text (property files), but I might run into a similar situation with XML files later.
Expanding a bit on Juergen's answer for those who stumble on this - the containerDescriptorHandler in the descriptor can take four values (v2.3), these are metaInf-services, file-aggregator, plexus, metaInf-spring. It's a bit buried in the code (found in the package org.apache.maven.plugin.assembly.filter) but it is possible to aggregate config/properties files.
Here's an example descriptor that aggregates the META-INF/services and
named property files located in com.mycompany.actions.
descriptor.xml
<assembly>
...
<containerDescriptorHandlers>
<containerDescriptorHandler>
<handlerName>metaInf-services</handlerName>
</containerDescriptorHandler>
<containerDescriptorHandler>
<handlerName>file-aggregator</handlerName>
<configuration>
<filePattern>com/mycompany/actions/action.properties</filePattern>
<outputPath>com/mycompany/actions/action.properties</outputPath>
</configuration>
</containerDescriptorHandler>
</containerDescriptorHandlers>
....
</assembly>
The file-aggregator can contain a regular expression in the filePattern to match multiple files. The following would match all files names 'action.properties'.
<filePattern>.+/action.properties</filePattern>
The metaInf-services and metaInf-spring are used for aggregating SPI and spring config files respectively whilst the plexus handler will aggregate META-INF/plexus/components.xml together.
If you need something more specialised you can add your own configuration handler by implementing ContainerDescriptorHandler and defining the component in META-INF/plexus/components.xml. You can do this by creating an upstream project which has a dependency on maven-assembly-plugin and contains your custom handler. It might be possible to do this in the same project you're assembling but I didn't try that. Implementations of the handlers can be found in org.apache.maven.plugin.assembly.filter.* package of the assembly source code.
CustomHandler.java
package com.mycompany;
import org.apache.maven.plugin.assembly.filter.ContainerDescriptorHandler;
public class CustomHandler implements ContainerDescriptorHandler {
// body not shown
}
then define the component in /src/main/resources/META-INF/plexus/components.xml
components.xml
<?xml version='1.0' encoding='UTF-8'?>
<component-set>
<components>
<component>
<role>org.apache.maven.plugin.assembly.filter.ContainerDescriptorHandler</role>
<role-hint>custom-handler</role-hint>
<implementation>com.mycompany.CustomHandler</implementation>
<instantiation-strategy>per-lookup</instantiation-strategy>
</component>
</components>
</component-set>
Finally you add this as a dependency on the assembly plugin in the project you wish to assemble
pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2.1</version>
<configuration>
<descriptors>
<descriptor>...</descriptor>
</descriptors>
</configuration>
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>sample-handler</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</plugin>
and define the handlerName in the descriptor
descriptor.xml
...
<containerDescriptorHandler>
<handlerName>custom-handler</handlerName>
</containerDescriptorHandler>
...
The maven-shade-plugin can also create 'uber-jars' and has some resource transforms for handling XML, licences and manifests.
J
Old question but stumbled over it while trying to solve similar problem: Assembly plugin 2.2 has capabilities to merge files: http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_containerDescriptorHandler
e.g. handlerName "metaInf-services" (will concat all META-INF/services files), "metaInf-spring" are the only ones I know of (I personally needed metaInf-services)
I don't know of a robust solution to this problem. But a bit of looking around shows that somebody has created a plugin to merge properties files. By the look of it you need to tell it which files to merge, which is a good thing as you don't want this applied willy nilly.
Assuming you have used dependency-unpack to unpack the zip to a known location, it would be a case of configuring the plugin to merge each pair of properties files and specify the appropriate target location.
You could extend the plugin to handle XML by using something like xmlmerge from EL4J, as described in this Javaworld article.
Ive also created a merge files plugin, in my case i use it to merge SQL files from various projects into a single installer SQL file which can create all the schemas/tables/static data etc for our apps in a single file, http://croche.googlecode.com/svn/docs/maven-merge-files-plugin/0.1/usage.html
https://github.com/rob19780114/merge-maven-plugin (available on maven central) also seems to do the job.
See below for an example configuration
<plugin>
<groupId>org.zcore.maven</groupId>
<artifactId>merge-maven-plugin</artifactId>
<version>0.0.3</version>
<executions>
<execution>
<id>merge</id>
<phase>generate-resources</phase>
<goals>
<goal>merge</goal>
</goals>
<configuration>
<mergers>
<merger>
<target>${build.outputDirectory}/output-file-1</target>
<sources>
<source>src/main/resources/file1</source>
<source>src/main/resources/file2</source>
</sources>
</merger>
<merger>
<target>${build.outputDirectory}/output-file-2</target>
<sources>
<source>src/main/resources/file3</source>
<source>src/main/resources/file4</source>
</sources>
</merger>
</mergers>
</configuration>
</execution>
</executions>
Related
I need to generate a few small text files that will be used as inputs during generate-sources phase of another project (data files input to FMPP/FreeMarker). The generator is Java source code - that is, the code that generates the text files is compiled in the first project. In this kind of scenario, how are the data files normally conveyed from one project to the other?
I could cobble together a dozen lame ways to do this - I'm looking for best practice.
At the moment, I'm avoiding the problem by having the first project just produce an executable jar, which is run by the second project to produce the data files. But there's really no reason for the code to be "public" - to be installed - the output of the first project really should just be the TDD files.
I'm not sure I have the full picture of what you're trying to do here but it sounds to me like you should be using the maven dependency plugin.
I'm assuming that the first project would create an artifact with the data files you need for the second and other projects. The second project could use the dependency plugin to unpack that artifact into target/generated-sources or wherever it is needed as part of its build.
For example:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<id>unpack-interfaces</id>
<phase>initialize</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<includeArtifactIds>first-project-artifact</includeArtifactIds>
<includes>*.TDD</includes>
</configuration>
</execution>
</executions>
</plugin>
I hope I don't misunderstand you. You can run a maven2 project with exec-maven-plugin. This will run the first project and produces input for the next. If you should copy the *.tdd files, maybe you can use maven-resources-plugin for this. Hope it helps.
I'm developing a simple, stand-alone, command line Java application. The project is managed by Maven. I'd like to build a deliverable, which can be copied and run on the client's machine.
The maven-assembly plugin with the default 'jar-with-dependencies' type is ok for me, but
I don't want to package the log4j.properties file into the jar. I'd rather have it in a separate "res" folder.
I've managed to put a Class-Path header in the manifest file for the res folder, but I'm having trouble excluding the log4j.properties file from the generated jar.
What I'm trying is to have the file excluded without writing a custom assembly descriptor. I'd like to customize the default solution, like this:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<excludes>
<exclude>**/log4j.properties</exclude>
</excludes>
<archive>
<manifest>
<mainClass>com.my.App</mainClass>
</manifest>
<manifestEntries>
<Class-Path>res/</Class-Path>
</manifestEntries>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration></plugin>
but it doesn't work. Do I have to write a custom assembly descriptor for this?
From the doc, it looks like you cannot exclude files by customizing <plugin> parameters alone.
<excludes> does not look like a valid parameter for the plugin and is thus getting ignored.
I am setting up maven to take annotated java classes and produce some DDL which varies depending on the database. Is there a better way to do this? It seems like I should be able to filter the input to the hbm2ddl plugin (as part of a pipeline) rather than tell it to operate on the output of resource filtering (which I then must filter out of my final jar).
I am filtering my hibernate.cfg.xml file to substitute environment properties based on the local developer's setup:
<build>
<filters>
<filter>${user.home}/datamodel-build.properties</filter>
</filters>
<resources><resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource></resources>
</build>
Then I run hbm2ddl on the output
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>hibernate3-maven-plugin</artifactId>
...
<configuration>
<componentProperties>
<configurationfile>target/classes/com/myOrg/datamodel/hibernate.cfg.xml</configurationfile>
</plugin>
I then must filter out the hibernate.cfg.xml from my production jar since I don't want to ship anything related to my internal dev environment.
I have this same issue and here is how I solved it. I use have a separate database.properties file that holds the connection details and I don't filter any of my XML files.
This seperate database.properties file gets filtered, but since it is a test resource located in /src/main/test it doesn't get put into the final artifact. I then tell hbm2ddl where to find it as follows:
<configuration>
<components>
<component>
<name>hbm2ddl</name>
<implementation>jpaconfiguration</implementation>
</component>
</components>
<componentProperties>
<propertyfile>src/test/resources/database.properties</propertyfile>
<!-- Gives the name of the persistence unit as defined in persistence.xml -->
<persistenceunit>myapp-core</persistenceunit>
<!-- Tells the plugin to send the output to a file -->
<outputfilename>create-${database.vendor}-schema.sql</outputfilename>
<!-- Pretty Format SQL Code -->
<format>true</format>
<!-- Do not create tables automatically - other plug-ins will handle that -->
<export>false</export>
<!-- Do not print the DDL to the console -->
<console>false</console>
</componentProperties>
</configuration>
Hope it helps anyway....
If you have an existing ant file, what is the best way to convert the project to Maven. I've checked out things like fAnt, but if I'm going to mess with this stuff, I might as well go full-bore for Maven. I expected something to exist that can just start the pom.xml for me based on the existing build.xml, but I haven't found anything yet. Suggestions?
I don't know any good automated way to do such a migration because things may just be too different so I would do it manually, step by step, and keep the existing ant build in parallel of the future new one until the whole migration is done (from both technical and human points of view).
First, refactor the existing Ant build to align it on Maven conventions:
Make things modular: if your existing build is a big monolithic build producing several artifacts from a single source tree, break it down into separate modules, one for each artifact.
Update directory structure: Maven comes with a standard directory layout and, while it is possible to customize this layout (i.e. to configure plugins for another layout), this is not really recommended and is more a source of troubles than benefits. So I'd move existing app sources, configuration files, tests, etc to match Maven's layout (e.g. src/main/java for application sources, etc).
Then, start to create the Maven build:
Create POMs for each module: Create a POM, declare external libraries as Maven dependencies (maybe add them to a corporate repository, using an enterprise repository is a good practice in an enterprise context anyway), add dependencies between modules.
Finalize the multi-modules build: Add parent(s) POM(s) and inheritance/aggregating relationships. Test that there is no regression with the created artifacts.
You could do this work in a separate VCS branch if you don't want to change anything until the work is done and create scripts to move things. And when ready, merge the Maven specific stuff and apply the scripts.
You could run the Ant script from Maven with the maven-antrun-plugin. Your pom.xml would look something like this:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<dependencies>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant-nodeps</artifactId>
<version>${ant-nodeps.version}</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>init</id>
<phase>compile</phase>
<configuration>
<tasks>
<!-- Ant code goes here -->
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</build>
</project>
That way you can start to move your dependencies into Maven, and reference them in the Ant script like so
${com.foo.bar:my-lib:jar}
Then just start slowly moving pieces of your Ant into pure Maven stuff.
I'm using some off-the-shelf OSGi bundles in my application and would like to repackage them together with additional packages that are not yet OSGi compatible into a new bundle.
Case in point is EclipseLink, which is available as several OSGi bundles, most of which are optional, depending on what you want to do. I want to pick those bundles that are relevant for me, add database drivers (for example the MySQl JDBC connector) and repackage them into a new bundle that is easier to deploy.
I'm using the maven-bundle-plugin from Apache Felix. I set up a new Maven project without source code, added the four eclipselink and the mysql connector as dependencies and tried the following:
use the <Embed-Dependency> and <Embed-Transitive> instructions to include all dependencies in one bundle. Problem: Optional dependencies from the eclipselink bundles (for example, javax.mail.internet) become required as the plugin rewrites the manifest. The original bundles contain "resolution=optional" in the manifest and thus work well without.
use the manifest goal of the plugin and a jar-with-dependencies assembly, but that gives me basically the same result, only with more work.
used the bundleall goal of the plugin, which is not quite what I want, because it creates separate bundles again. Even worse, because now these bundles don't have their dependencies inside.
I'm going to face similar issues with Struts 2. I'm not going to be obsessive about this, and just go with a whole bunch of separate third-party bundles, but if I can package them more neatly, I would really like to. I'm aware that a point of OSGi is modularity, so creating big bundles kind of defeats that, but I feel that if your modules are tightly coupled anyway, you might as well put them into a single bundle.
Of course, I could manually tweak the manifests, but I definitely don't want to.
As omerkudat says, this is probably not a good practice to encourage, but as you have your reasons, this is a way you could do a poor-man's merge.
Assuming you are handling the OSGi manifest yourself, you only really need to get all the classes from the bundles and jars into the target/classes directory before the package phase.
You can do this with either of the dependency plugin's unpack-dependencies or unpack goals. I'd use the unpack-dependencies if you want to process all the project dependencies (or those following a certain naming patter or in a certain groupId) and the unpack goal if you want to have fine control over the artifacts to be unpacked (at the expense of a verbose POM). I'll assume unpack in my example. Each unpack is output to the project's outputDirectory (i.e. target/classes).
Note this will overwrite duplicate artifacts from each package in the order they're downloaded, so the manifests will be clobbering each other. To ensure your artifacts are managed correctly, I would bind the unpack goal to an early phase so that your src/main/resources are copied on top of the unpacked contents and not overwritten. In the sample below this phase is generate-resources, so it will happen after your local compile. If you need to overwrite any of the classes, use an earlier phase to unpack the dependencies such as generate-sources
My sample below unpacks the contents of junit-3.8.1 and commons-io 1.4 (just the first two dependencies I had declarations for) into target/classes before the project's resources are copied there. Note that the versions are defined in my dependencies section. If you haven't got the bundles/jars declared as dependencies you'll need to declare the version in the artifactItem as well.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>generate-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<overWrite>false</overWrite>
<outputDirectory>${project.build.outputDirectory}</outputDirectory>
</artifactItem>
<artifactItem>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<overWrite>false</overWrite>
<outputDirectory>${project.build.outputDirectory}</outputDirectory>
</artifactItem>
</artifactItems>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
</configuration>
</execution>
</executions>
</plugin>