Include dependency as manifest-classpath

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Duplicate
  • Affects Version/s: None
  • Fix Version/s: 1.6
  • Labels:
    None

Description

One nice feature for the war plugin would be to make it
possible to specify that a dependency should be included in the manifest classpath of the war. Is is this something that is considered?

The jelly-code is in the ejb-plugin, so I suppose it would be pretty
easy to implement (I'd be happy to write a patch).

The reason is that when you have an ejb module and one or many
web-modules in a J2EE-project (as we have) you often have common
dependencies between these modules. Let's say you need commons-logging
in all modules then you'd probably want to include
commons-logging-x.x.x.jar in the EAR-file, and reference it from all
other modules as manifest classpath entries.

In the project.xml of a webapplication you would thus have:

<!-- This is a dependency shared by many modules -->
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</groupId>
<version>1.0.3</version>
<properties>
<war.manifest.classpath>true</war.manifest.classpath>
</properties>
</dependency>
<!-- This is a webapp dependency only -->
<dependency>
<groupId>webwork</groupId>
<artifactId>webwork</artifactId>
<version>1.3</version>
<properties>
<war.bundle>true</war.bundle>
</properties>
</dependency>

  1. File
    plugin.jelly
    12/Feb/04 4:40 AM
    9 kB
    Michal Szklanowski

Issue Links

duplicates

Improvement - An improvement or enhancement to an existing feature or task. MPWAR-21 war-plugin should be able to add manifest Class-Path Entry for dependencies

  • Trivial - Cosmetic problem like misspelt words or misaligned text.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Michal Szklanowski added a comment -

This on was pretty easy to hack.
Assuming that used sets war.manifest.classpath property to true in dependency section, war:war goal geneated Class-Path entry of manifest based on these properties.

The change is implemented in attached file.

Show
Michal Szklanowski added a comment - This on was pretty easy to hack. Assuming that used sets war.manifest.classpath property to true in dependency section, war:war goal geneated Class-Path entry of manifest based on these properties. The change is implemented in attached file.
Hide
Permalink
Michal Maczka added a comment -

AFAIK usage of MANIFEST files in wars for "sharing" jars with other deployment units of the j2ee application was not supported by j2ee 1.3 SPEC. That was the major reason why this feature not never implemented in war plugin.

There were some application servers which allowed this. I don't know if it supported in the uniform way.

I don't know how the situation looks like for j2ee 1.4.

Assuming that it was not yet "standardized" the question is:
should we take the pragmatic path and "help" users which might need this feature? I think that yes as long as war plugin won't become specific for particular application server.

Other thing is that IMHO It will be rather beneficial to let users generate their own manifests files then introduce dozen of properties in POM and plugins for controlling how does manifest file look like.
It will be just simpler to use. And we can provide templates which will exhaust all usual use-cases.

Michal Maczka

Show
Michal Maczka added a comment - AFAIK usage of MANIFEST files in wars for "sharing" jars with other deployment units of the j2ee application was not supported by j2ee 1.3 SPEC. That was the major reason why this feature not never implemented in war plugin. There were some application servers which allowed this. I don't know if it supported in the uniform way. I don't know how the situation looks like for j2ee 1.4. Assuming that it was not yet "standardized" the question is: should we take the pragmatic path and "help" users which might need this feature? I think that yes as long as war plugin won't become specific for particular application server. Other thing is that IMHO It will be rather beneficial to let users generate their own manifests files then introduce dozen of properties in POM and plugins for controlling how does manifest file look like. It will be just simpler to use. And we can provide templates which will exhaust all usual use-cases. Michal Maczka
Hide
Permalink
Felipe Leme added a comment -

This was solved on release 1.6. From changes.xml:

<action dev="dion" type="update" issue="MPWAR-21">Allow automated generation of manifest Class-Path</action>

Show
Felipe Leme added a comment - This was solved on release 1.6. From changes.xml: <action dev="dion" type="update" issue="MPWAR-21">Allow automated generation of manifest Class-Path</action>

People

  • Assignee:
    Unassigned
    Reporter:
    Anders Engstr?m
Vote (2)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: