How to make Eclipse unpack bundles without Eclipse-BundleShape header - eclipse-plugin

I have a large number of bundles from a legacy Eclipse RCP application that I want to be able to use in a Tycho build. There is no p2 repository with these bundles yet, so I created one. This already works pretty well, except that the bundles which need to be unpacked in the installation are still installed as JARs.
My first approach to create the p2 repository was to deploy the bundles to a Maven repository and then use pomDependency=consider to include them in an eclipse-feature and eclipse-repository. However, Tycho ignores the unpack attributes in the feature.xml so this doesn't work (cf. this documentation). The recommended solution for this problem is to add Eclipse-BundleShape: dir in the manifests of the included bundles. I could do that - but since I have hundreds of bundles, this would be quite a large effort.
Then, I was given the tip to use the "Features and Bundles Publisher Application": With this application, the feature and bundle artifacts are created in the p2 repository at the same time, so the information about the bundle shape can be copied over from the feature.xml into the respective bundles.
However this still doesn't work: Although I have set unpack="true" for one of the bundles being published, the bundle doesn't have the
<instruction key='zipped'>
true
</instruction>
in the content.xml in the p2 repository and hence is not unpacked when installing it. Any ideas what I could be doing wrong? Any other ideas how to get this working?
This is my pom.xml for the p2 repository creation:
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycorp.xyz.expose</groupId>
<artifactId>com.mycorp.xyz.expose.orbit</artifactId>
<version>1.0.0</version>
<dependencies>
<dependency>
<groupId>com.mycorp.xyz.expose</groupId>
<artifactId>com.mycorp.somelib</artifactId>
<version>6.40.0</version>
</dependency>
<!-- and many more... -->
</dependencies>
<build>
<outputDirectory>${project.build.directory}/artifacts</outputDirectory>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.9</version>
<executions>
<execution>
<id>copy</id>
<phase>process-resources</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/artifacts/plugins</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.eclipse.tycho.extras</groupId>
<artifactId>tycho-p2-extras-plugin</artifactId>
<version>0.21.0</version>
<executions>
<execution>
<id>publish-features-and-bundles</id>
<phase>compile</phase>
<goals>
<goal>publish-features-and-bundles</goal>
</goals>
<configuration>
<sourceLocation>${project.build.directory}/artifacts</sourceLocation>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-p2-repository-plugin</artifactId>
<version>0.21.0</version>
<executions>
<execution>
<id>assemble</id>
<phase>package</phase>
<goals>
<goal>verify-repository</goal>
<goal>archive-repository</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
The only other file in the project is the following feature.xml in src/main/resources/features`:
<?xml version="1.0" encoding="UTF-8"?>
<feature
id="com.mycorp.xyz.expose.orbit"
label="..."
version="1.0.0">
<plugin
id="com.mycorp.somelib"
download-size="0"
install-size="0"
version="0.0.0"
unpack="true"/>
<!-- and many more... -->
</feature>

I've debugged the Features and Bundles Publisher Application that is running in the described setup, and it turns out that the publisher doesn't associate the unpack="true" from the feature.xml with the bundles because the versions don't match.
So you'll need to provide the actual OSGi versions of the referenced bundles instead of 0.0.0 in the feature.xml. There is no automatic replacement like in a normal Tycho build. So the feature.xml would e.g. look like this:
<?xml version="1.0" encoding="UTF-8"?>
<feature
id="com.mycorp.xyz.expose.orbit"
label="..."
version="1.0.0">
<plugin
id="com.mycorp.somelib"
download-size="0"
install-size="0"
version="6.40.0.140829051758"
unpack="true"/>
</feature>
Then, the bundle is unpacked at installation time as expected.

Related

Maven war artifact with car extension

I am trying to use Maven to generate an artifact for deploying on Vignette Portal. The packaging is exactly the same as a war artifact but the file should have car extension instead.
Options I've tried and I've not been able to complete.
Use war plugin and rename the final artifact (keeps adding .war extension)
Use assembly plugin with zip descriptor (not able to change .zip to .car extension)
Create a new packaging type as described here (can't use war plugin for .car extension)
Which would be the easiest 'Maven' way to generate the .car file? Could you give me some guidance?
Thank you.
I think it's not possible to rename the main deliverable artifact of a project.
Anyway, in the past, what I've done so far was making maven copy the file with a new name and then "attach" it to the deliverables of a build; by configuring two plugins:
maven-ant-run to copy
maven-build-helper to attach in order to be deployed to my repo along with the main artifact of my project.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<configuration>
<target>
<copy file="${project.build.directory}/${project.build.finalName}.war"
tofile="${project.build.directory}/${project.build.finalName}.car" />
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
And the second:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>attach-instrumented-jar</id>
<phase>verify</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>${project.build.directory}/${project.build.finalName}.car</file>
<type>car</type>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
I hope that can help you. At least until you find a better solution.

Is there any maven goal that is similar to 'dist'?

I'm working on a project that used ant. I had a target dist that would basically do jar first, and then install the application into a directory.
This means, it would create directories like bin/, lib/ and config/ in the installation directory, and then copy the relevant files into each of these directories.
My question is two-fold:
Is there any maven goal that does this kind of thing?
If not, I want to do maven dist and make this happen. How would you suggest I accomplish this using Maven?
If I can't have my own "target" (like dist), then what would be the best way?
Bottom line: I want to do all this, but don't want to alter the behavior of the default "targets" like compile and package etc.
Thanks,
jrh
PS: I'm using maven version 2.2.21
I don't know what would go in config, but lib and bin is easy.
To copy all dependencies to a folder just do this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>
${project.build.directory}/dist/lib
</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
To output your jar to a bin folder do this (reference page):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<finalName>${project.artifactId}</finalName>
<outputDirectory>${project.build.directory}/dist/bin</outputDirectory>
</configuration>
</plugin>
Ah, there are additional requirements:
Bottom line: I want to do all this, but don't want to alter the behavior of the default "targets" like compile and package etc.
In this case I'd use a profile to turn this on:
<profile>
<id>dist</profile>
<build>
<plugins>
<!-- insert stuff from above here -->
</plugins>
</build>
</profile>
Now you would do mvn clean package -Pdist to get your dist directory and if you don't add the profile, you get default behaviour.
Basically, things work differently in maven from the way they do in ant. There are no targets, there are only lifecycle phases and plugin goals.
You can either execute a lifecycle phase, which will call all maven plugin goals that are bound to all phases up to this one (e.g. if you do mvn compile, the following phases will be executed: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile). But there is no (easy) way to define a lifecycle phase named dist.
Or you can execute a specific plugin goal (you can actually execute multiple phases and / or plugin goals). E.g. you could write your own dist plugin and call it using mvn dist:dist, but I wouldn't recommend that because you are using existing functionality and the profile solution should be a pretty good fit.
You could try writing an assembly descriptor for the assembly plugin (or search google for a suitable one).
Something like this
<assembly
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>dist</id>
<formats><format>zip</format></formats>
<fileSets>
<fileSet>
<directory>src/main/config</directory>
<outputDirectory>config</outputDirectory>
<useDefaultExcludes>true</useDefaultExcludes>
</fileSet>
</fileSets>
<files>
<file>
<source>${project.build.directory}/${project.artifactId}.jar</source>
</file>
</files>
<dependencySets>
<dependencySet>
<useProjectArtifact>false</useProjectArtifact>
<outputDirectory>lib</outputDirectory>
</dependencySet>
</dependencySets>
</assembly>
will create a ${project.artifactId}-dist.zip inside your target directory. The zip file will be laid out like
yourProjectName/
yourProjectName/config/...
yourProjectName/lib/...
yourProjectName/${project.artifactId}.jar
It looks like the assembly plugin will only create compressed files, it won't just copy them to a dist folder.
Seans answer is good and I almost went for it until I found out about the appassembler plugin http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/.
See here for an example https://github.com/khmarbaise/maven-training/tree/master/502-assembly-plugin
It is called as part of the package lifecycle.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>appassembler-maven-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>assemble</goal>
</goals>
</execution>
</executions>
<configuration>
<binPrefix>utility</binPrefix>
<assembleDirectory>${project.build.directory}/appassembler</assembleDirectory>
<extraJvmArguments>-Xms512m -Xmx1024m</extraJvmArguments>
<generateRepository>false</generateRepository>
<repositoryName>lib</repositoryName>
<repositoryLayout>flat</repositoryLayout>
<includeConfigurationDirectoryInClasspath>true</includeConfigurationDirectoryInClasspath>
<platforms>
<platform>windows</platform>
<platform>unix</platform>
</platforms>
<programs>
<program>
<mainClass>com.soebes.tools.cli.UtilityCLI</mainClass>
<name>utility</name>
</program>
</programs>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2</version>
<configuration>
<descriptors>
<descriptor>src/main/assembly/bin.xml</descriptor>
<descriptor>src/main/assembly/bin-unix.xml</descriptor>
<descriptor>src/main/assembly/src.xml</descriptor>
</descriptors>
<tarLongFileMode>gnu</tarLongFileMode>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
The descriptors it references are fairly straigtforward and it also creates a batch and shell script for you to run your application!
You cannot have maven dist, with NetBeans (and other IDEs I believe) you can create a custom action dist which executes as mvn install -Pdist (or mvn clean package -Pdist, as suggested by Sean).

Renaming resources in Maven

I am trying to find a way to copy a resource file to a new name in the target directory in a Maven build. Pretty much everything I have found while searching suggests workarounds involving multiple sub-directories in /src/main/resources and selecting among them via profiles. However, in my case, this does not solve the problem, namely that the file I want has a "magic" name.
Basically what I want to do is have a /src/main/resources/default.DS_Store file get copied to ${project.build.directory}/.DS_Store. Since the .DS_Store file has special meaning in Mac OSX, it is not desirable to have a file with that name in the source tree, and in version control. However, I do want the data in the file to be in the source tree and version control, and have it renamed to the "magic" name during the build.
I'm starting to think that ant is the only way to do this automatically. Is there any easier way?
Using the antrun-maven-plugin makes it easy, but in case you are looking for a more mavenish way which is supported within eclipse m2e, then you can use the copy-rename-maven-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>compile</phase>
<goals>
<goal>rename</goal>
</goals>
<configuration>
<sourceFile>${project.build.outputDirectory}/default.DS_Store</sourceFile>
<destinationFile>${project.build.outputDirectory}/.DS_Store</destinationFile>
</configuration>
</execution>
</executions>
</plugin>
And in case you have any feedback/issues with the plugin, you can reach out at https://github.com/coderplus/copy-rename-maven-plugin/
Example usage of the assembly plugin to copy and/or rename a file:
pom file:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>test</artifactId>
<version>0.0.1-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2.1</version>
<configuration>
<descriptors>
<descriptor>src/main/descriptors/example.xml</descriptor>
</descriptors>
</configuration>
</plugin>
</plugins>
</build>
</project>
Descriptor file:
<?xml version="1.0" encoding="UTF-8"?>
<assembly>
<id>example</id>
<formats>
<format>dir</format>
</formats>
<files>
<file>
<source>src/main/resources/something.properties</source>
<outputDirectory>/</outputDirectory>
<destName>something.properties</destName>
</file>
<file>
<source>src/main/resources/something.properties</source>
<outputDirectory>/</outputDirectory>
<destName>something_en.properties</destName>
</file>
</files>
</assembly>
I had the same problem using the copy-rename-maven-plugin solved my problem
<project>
...
<build>
<plugins>
<plugin>
<groupId>com.coderplus.maven.plugins</groupId>
<artifactId>copy-rename-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>copy-file</id>
<phase>generate-sources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<sourceFile>src/someDirectory/test.environment.properties</sourceFile>
<destinationFile>target/someDir/environment.properties</destinationFile>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
I see 2 options to solve your problem:
Use the Maven-Ant-Plugin, and define an Ant rename task that will rename your file only at the packaging phase, in the build directory.
Use this dedicated Maven plugin (I didn't test it): http://code.google.com/p/maven-file-rename-plugin/
You can avoid the over head of Ant by using the Maven Assembly plugin and the file assembly descriptor.

How to make jetty-maven-plugin deploy a war that is retrieved from a repository?

I'm setting up an integration test module for a good sized web project. The integration test module is separated from the web project itself, and it has it's own pom.
The idea is to use the maven-soapui-plugin to send requests and verify the response. Setting up the soapui-plugin is no hassle. However, I'm having trouble with figuring out how I can tell the jetty-maven-plugin to deploy a war from a remote repository.
If I have understood correctly, the jetty-maven-plugin has a property called '<webApp>/<webApp>' which lets me specify the war file to deploy. The problem is that the war file is not present in the module itself.
I have heard that I can use the maven assembly plugin to retrieve the war from a repository via the projects artifactId, but I am yet to figure out how I would go about doing so.
Here's a summary of what I want:
Retrieve a specific war from a repository or the like, in example via its artifactId.
Deploy this war to the jetty-maven-plugin (goal deploy-war?)
get maven-soapui-plugin to run tests and report the results back in the integration-test phase.
I am pretty sure I've got step 3 covered, but I am very unsure how to achieve step 1 and 2.
Any help is greatly appreciated
It is maybe possible to use dependency:copy to retrieve the war, unpack it and to get the whole thing working with the maven jetty plugin, but this would be hacky and kinda ugly. A cleaner solution would be to use the Maven Cargo plugin and this is my suggestion. Below, a sample POM showing how to retrieve a WAR artifact using its coordinates and how to deploy it on an embedded Jetty container using Cargo:
<dependencies>
<dependency>
<groupId>war group id</groupId>
<artifactId>war artifact id</artifactId>
<type>war</type>
<version>war version</version>
</dependency>
...
</dependencies>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<configuration>
<!-- Container configuration -->
<container>
<containerId>jetty6x</containerId>
<type>embedded</type>
</container>
<!-- Configuration to use with the container or the deployer -->
<configuration>
<deployables>
<deployable>
<groupId>war group id</groupId>
<artifactId>war artifact id</artifactId>
<type>war</type>
<properties>
<context>war context</context>
</properties>
</deployable>
</deployables>
</configuration>
<!-- Don't wait, execute the tests after the container is started -->
<wait>false</wait>
</configuration>
<executions>
<execution>
<id>start-container</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop-container</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Finally, just bind the soapui plugin on the integration-test phase.
I'm doing the same thing, John, but I took a different approach with the Jetty plugin. I think the end result is the same. I'm developing an integration-test suite to run against several web service WARs. I'm using dependency:copy in the package phase and then a list of <contextHandler/>s configured for maven-jetty-plugin:
<project>
…
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-wars</id>
<phase>package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/wars-to-be-tested</outputDirectory>
<stripVersion>true</stripVersion>
<artifactItems>
…
<artifactItem>
<groupId>groupId</groupId>
<artifactId>artifactId</artifactId>
<version>version</version>
<type>war</type>
</artifactItem>
…
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>7.1.3.v20100526</version>
<configuration>
…
<contextHandlers>
…
<contextHandler implementation="org.mortbay.jetty.plugin.JettyWebAppContext">
<war>${project.build.directory}/wars-to-be-tested/artifactId.war</war>
<contextPath>/context</contextPath>
</contextHandler>
</contextHandlers>
</configuration>
<executions>
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<goal>stop</goal>
<goal>run</goal>
</goals>
<configuration>
<scanIntervalSeconds>0</scanIntervalSeconds>
<daemon>true</daemon>
</configuration>
</execution>
<execution>
<id>stop-jetty</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
I would prefer to declare the various wars as dependencies and then use dependency:copy-dependencies to set up the wars-to-be-tested directory; this would allow the Maven reactor to figure out that it needs to build my integration-test module after the wars it'll be testing. The problem I ran into was that the Jetty plugin thought that I wanted to "overlay" all of the wars that were listed as dependencies (a concept that I'd never even heard of until I saw it happen); I don't know if allowing that to happen would have hurt anything, but I didn't like it, so I went with the dependency:copy method.
This is just an alternative to using Cargo. I'll be looking into that myself, but I just wanted to provide another way of doing it.

How to create source distribution with self sustainable maven build?

What I want to do is to create source code distribution of my application with all dependencies and burn it on DVD. So that I could build it in 100 years (well, ok, you know what I mean...). No online dependencies on libraries or maven plugins!
I know that Ant would be better for this, but I'm using maven in my project. I'm not going to switch to Ant just for that, I'm asking how to do this with maven. Or, if there is a way how to generate self sustainable Ant build that I could put on DVD that would be great too.
(there is ant:ant plugin but it just generates Ant build.xml that points dependencies to local maven repo)
The approach I've taken is that I wanted to create special local repository that I can put on DVD and then build project with mvn -o -Dmaven.repo.local=repo/on/dvd. I was trying to make such repository with dependency:copy-dependencies anduseRepositoryLayout param set to true. But it doesn't copy freaking maven plugins that my build depends on...
The only way I can think of to include the plugins is to specify a different local repository for the build on the command line and ensure all the dependency sources etc are downloaded, then create an archive including the project's contents and the custom repository.
Here is a pom that downloads the sources and javadocs (it downloads them to the project's target directory, which we exclude from the archive because they will also be in the local repository). The assembly descriptor bundles the project's contents and the local repository into a single (pretty large) archive.
Note the processing is all in a profile because you really don't want this running on every build. If temporary local repository is in the target directory you can easily clean the mess up afterwards with a mvn clean.
To activate the profile do something like the following:
mvn package -Parchive -Dmaven.repo.local=.\target\repo
Here's the pom:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>name.seller.rich</groupId>
<artifactId>test-archive</artifactId>
<version>0.0.1</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.5</version>
<scope>test</scope>
</dependency>
</dependencies>
<profiles>
<profile>
<id>archive</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>sources</id>
<phase>pre-package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<classifier>sources</classifier>
<failOnMissingClassifierArtifact>false</failOnMissingClassifierArtifact>
<!--the target directory won't be included, but the sources will be in the repository-->
<outputDirectory>${project.build.directory}/sources</outputDirectory>
</configuration>
</execution>
<execution>
<id>javadocs</id>
<phase>pre-package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<classifier>javadoc</classifier> <failOnMissingClassifierArtifact>false</failOnMissingClassifierArtifact>
<outputDirectory>${project.build.directory}/javadocs</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptors>
<descriptor>src/main/assembly/archive.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
And here's the assembly:
<assembly>
<id>archive</id>
<formats>
<format>zip</format>
</formats>
<fileSets>
<fileSet>
<directory>${project.basedir}</directory>
<outputDirectory>/</outputDirectory>
<excludes>
<exclude>target/**</exclude>
</excludes>
</fileSet>
<fileSet>
<directory>${maven.repo.local}</directory>
<outputDirectory>repo</outputDirectory>
</fileSet>
</fileSets>
</assembly>
Watch this:
Maven Assembly Plugin
Quote from the homepage:
Do you want to create a binary
distribution from a Maven project that
includes supporting scripts,
configuration files, and all runtime
dependencies? You need to use the
Assembly Plugin to create a
distribution for your project.
It's well configurable. I used it especially for making self-running demo versions of web-applications with an embedded jetty server and user documentation.
I don't have a complete answer. Last time I looked at this, I thought that cleaning out the localRepository at the start of the build (or using a separate one) and the running mvn dependency:go-offline.
If you're really keen, you'll also want to bundle maven itself and a JDK into the distribution. This likely takes it out of scope of a pure maven build.