Dependency mapping with the assembly plugin

[Jeffrey E Care <ca...@us.ibm.com>]

I have a situation where many of my projects need to produce an adjunct 
artifact (in addition to the primary JAR) for later collection into my 
distribution image.

I'd like to simplify the process that I use to generate the distribution 
image, as right now the POM for the distribution project has lots of 
dependency declarations that look like this:

<dependency>
  <groupId>com.ibm.group</groupId>
  <artifactId>foo</artifactId>
  <version>${project.version}</version>
</dependency>
<dependency>
  <groupId>com.ibm.group</groupId>
  <artifactId>foo</artifactId>
  <version>${project.version}</version>
  <classifier>adjunct</classifier>
  <type>zip</type>
</dependency>

The second declaration is essentially a duplicate of the first, just with 
the classifier & type added. I'd like to get rid of the second 
declaration. I'd like the assembly plugin to automatically discover the 
adjunct artifacts if they exist for projects that are already declared as 
dependencies for the primary artifact.

I know that I can use the classifier & type mapping capabilities of the 
dependency plugin to do this, unpack the adjuncts & then use a fileset in 
my assembly descriptor. But I can't help think that it would be cleaner if 
the assembly plugin could just handle this internally.

Has there ever been such a use case put forward? Is there a better way to 
handle this requirement? (please do not suggest that I restructure my 
projects to eliminate the need for the adjunct artifacts)

--JEC

Re: Dependency mapping with the assembly plugin

[Jeffrey E Care <ca...@us.ibm.com>]

Wayne Fay <wa...@gmail.com> wrote on 04/02/2013 03:23:03 PM:

> > I have a situation where many of my projects need to produce an 
adjunct
> > artifact (in addition to the primary JAR) for later collection into my
> > distribution image.
> 
> What types of things are stored in your adjunct artifacts? How are
> they created? Why can those things not live in the primary artifact
> instead?

Configuration fragments. Runtime support files that must be loaded from 
the file system instead of the classpath. Shell scripts. All of the files 
that end up in the adjunct artifacts are logically related to the runtime 
code that is hosted in their respective projects.

Re: Dependency mapping with the assembly plugin

[Wayne Fay <wa...@gmail.com>]

> I have a situation where many of my projects need to produce an adjunct
> artifact (in addition to the primary JAR) for later collection into my
> distribution image.

What types of things are stored in your adjunct artifacts? How are
they created? Why can those things not live in the primary artifact
instead?

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org