Maven Shared Components
  1. Maven Shared Components
  2. MSHARED-132

Add support for manifest attributes introduced with java.lang.instrument

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: maven-archiver-2.4
    • Fix Version/s: None
    • Component/s: maven-archiver
    • Labels:
      None
    • Number of attachments :
      0

      Description

      With J2SE 1.5 and the java.lang.instrument package, new manifest attributes have been introduced: Pre-Main-Class, Agent-Class, Boot-Class-Path, etc. (see http://java.sun.com/javase/6/docs/api/java/lang/instrument/package-summary.html for a complete list). It would be great if the maven-archiver could support these as well as it supports the very similar Main-Class and Class-Path manifest attributes. (Note, however, that the attributes introduced require the use of JARs; they are not completely independent of the archive format, so maybe maven-archiver is not a perfect fit.)

        Activity

        Show
        Benjamin Bentmann added a comment - You can already add any entries you like: http://maven.apache.org/shared/maven-archiver/index.html http://maven.apache.org/shared/maven-archiver/examples/manifestEntries.html
        Hide
        Andreas Sewe added a comment -

        I am aware of this possibility, which for Pre-Main-Class and Agent-Class it works fine (just as it would for Main-Class, by the way ); it simply changes the name of the XML element I have to use. Support for the Class-Path manifest attribute, however, has some more smarts build in. I thus wonder whether some of them might suit Boot-Class-Path as well.

        There is, however, the issue that you would rarely want all dependencies to show up in Boot-Class-Path; some of them should probably still end up in the Class-Path entry. The question then is how to make this configurable. Maybe one can distinguish by means of a classifier, as is possible with, e.g., the include and exclude directives of dependency:copy-dependencies.

        That being said, I can live with explicit manifestEntries; it only causes me to repeat myself whenever the Boot-Class-Path grows longer, as for each of its entries I still have to have a provided-scoped dependency (to cause Maven to compile my boot class path JARs automatically).

        Show
        Andreas Sewe added a comment - I am aware of this possibility, which for Pre-Main-Class and Agent-Class it works fine (just as it would for Main-Class , by the way ); it simply changes the name of the XML element I have to use. Support for the Class-Path manifest attribute, however, has some more smarts build in. I thus wonder whether some of them might suit Boot-Class-Path as well. There is, however, the issue that you would rarely want all dependencies to show up in Boot-Class-Path ; some of them should probably still end up in the Class-Path entry. The question then is how to make this configurable. Maybe one can distinguish by means of a classifier, as is possible with, e.g., the include and exclude directives of dependency:copy-dependencies . That being said, I can live with explicit manifestEntries ; it only causes me to repeat myself whenever the Boot-Class-Path grows longer, as for each of its entries I still have to have a provided -scoped dependency (to cause Maven to compile my boot class path JARs automatically).

          People

          • Assignee:
            Unassigned
            Reporter:
            Andreas Sewe
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: