How to regenerate the manifest for a binary artefact

[Harry Klerks]

Hi,

I have an EAR file (containing several modules and other dependencies) from
an external source that I want to integrate into my Maven based build
system.

The EAR file and its contents are built by an ANT based build system and
some of the artefacts do not comply with the Maven filenaming conventions (
i.e. they do not contain version numbers).

I have installed all the binaries in our own repository and created POMs for
them containing the (runtime) dependencies mentioned in the manifest
classpath.

But now the classpaths in the manifest files are incorrect because they do
not contain version numbers.

What I want to do is roughly the following:

   - use dependency:unpack to unpack the archive
   - skip compile phase and let Maven complete the build of the artefact
   including generation of a correct manifest based on the POM that I installed
   in the repository
   - repackage

Question then is; is this the correct way to go about it and how can I
accomplish this?

Regards,
Harry Klerks

Building an EAR from source and binaries

[Harry Klerks]

In a multi-module setup, I am trying to build an EAR from a mix of projects
for which I have the source code and a number of binary modules for which I
do not have the source code. I have installed these binaries in my local M2
repository and reference them in various POMs. So far so good, but a number
of these binaries are J2EE modules themselves, so they are also mentioned in
the dependencies list in the POM of the EAR-project. Most of these modules
contain a MANIFEST.MF file with a classpath entry that names the
dependencies by their 'non-maven-name', i.e. X.jar instead of X-1.0.jar, and
that obviously causes problems when these modules are deployed by the
Application Server.

Thoughts anyone?

Harry Klerks