Maven 1.x PDF Plugin

add support for external imaging libraries like jimi and jai

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.4
  • Labels:
    None
  • Environment:
    maven-1.0rc2, maven-pdf-plugin 2.1
  • Number of attachments :
    0

Description

Problems with the insertion of PNG image files.
JIMI/JAI libraries needed for handling them.

How I've solved it:

I created 3 new properties in my project.properties. Each of
them just pointing to its respective library location.

maven.pdf.jimi.jar=$

{maven.repo.local}/jimi/jars/jimi-1.0.jar
maven.pdf.jaicore.jar=${maven.repo.local}

/jai/jars/jai_core-1.1.2.jar
maven.pdf.jaicodec.jar=$

{maven.repo.local}

/jai/jars/jai_codec-1.1.2.jar

After that I've inserted the following lines to the plugin.jelly
script file:

<pathelement location="$

{pom.getPluginContext('maven-pdf-plugin').getVariable('maven.pdf.jimi.jar')}

"/>
<pathelement location="$

{pom.getPluginContext('maven-pdf-plugin').getVariable('maven.pdf.jaicore.jar')}

"/>
<pathelement location="$

{pom.getPluginContext('maven-pdf-plugin').getVariable('maven.pdf.jaicodec.jar')}

"/>

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Lukas Theussl added a comment -

An alternative that does not need the additional properties:

<pathelement location="$

{pom.getContext().getMavenRepoLocal()}/jimi/jars/jimi.jar"/>
<pathelement location="${pom.getContext().getMavenRepoLocal()}

/jai/jars/jai_core.jar"/>
<pathelement location="$

{pom.getContext().getMavenRepoLocal()}

/jai/jars/jai_codec.jar"/>

(not sure about the naming conventions, the three jars should also be added at http://maven.apache.org/reference/standard-sun-jar-names.html)

ie, the jars get automatically picked up if they are present in the local repository.

Show
Lukas Theussl added a comment - An alternative that does not need the additional properties: <pathelement location="$ {pom.getContext().getMavenRepoLocal()}/jimi/jars/jimi.jar"/> <pathelement location="${pom.getContext().getMavenRepoLocal()} /jai/jars/jai_core.jar"/> <pathelement location="$ {pom.getContext().getMavenRepoLocal()} /jai/jars/jai_codec.jar"/> (not sure about the naming conventions, the three jars should also be added at http://maven.apache.org/reference/standard-sun-jar-names.html ) ie, the jars get automatically picked up if they are present in the local repository.
Hide
Permalink
Arnaud Heritier added a comment -

I prefered something "standard" like Lukas proposed. But what about jar releases ?
I'm not in favor to store in a repository a jar without a release number.
Another idea is to get Jimi or Jai in the project dependency. It's less restricting in the plugin but it's more annoying for the project because in m1 we can't separate build and runtime dependencies.
Any thought ?

Show
Arnaud Heritier added a comment - I prefered something "standard" like Lukas proposed. But what about jar releases ? I'm not in favor to store in a repository a jar without a release number. Another idea is to get Jimi or Jai in the project dependency. It's less restricting in the plugin but it's more annoying for the project because in m1 we can't separate build and runtime dependencies. Any thought ?
Hide
Permalink
Lukas Theussl added a comment -

Jimi and Jai are not free and cannot be distributed via Ibiblio. Therefore I don't think it's a good idea to put them into the project dependencies - you shouldn't be obliged to download these jars manually in order to run the pdf goal.
For the jar release numbers, we'll either have to fall back to the first suggestion (set the version via a property), or use a hardcoded string (telling the user that he has to use a certain version of the jars).
Another possibility would be to loop over all .jar files found in the local repository (don't know if that's possible).

Show
Lukas Theussl added a comment - Jimi and Jai are not free and cannot be distributed via Ibiblio. Therefore I don't think it's a good idea to put them into the project dependencies - you shouldn't be obliged to download these jars manually in order to run the pdf goal. For the jar release numbers, we'll either have to fall back to the first suggestion (set the version via a property), or use a hardcoded string (telling the user that he has to use a certain version of the jars). Another possibility would be to loop over all .jar files found in the local repository (don't know if that's possible).
Hide
Permalink
Arnaud Heritier added a comment -

It's too difficult to search on the repository. I don't think that it is a problem to ask to the user to add a dependency on its project to use jimi even if this jar must be installed manually on its repository. But I don't like to ask to the user to add dependencies because it's not its project that use it but a plugin. I prefered finally the Fabio's proposal adding some properties. I'll apply it and we'll change if we find something better.

Show
Arnaud Heritier added a comment - It's too difficult to search on the repository. I don't think that it is a problem to ask to the user to add a dependency on its project to use jimi even if this jar must be installed manually on its repository. But I don't like to ask to the user to add dependencies because it's not its project that use it but a plugin. I prefered finally the Fabio's proposal adding some properties. I'll apply it and we'll change if we find something better.
Hide
Permalink
Arnaud Heritier added a comment -

Modification applied.

Show
Arnaud Heritier added a comment - Modification applied.

People

  • Assignee:
    Arnaud Heritier
    Reporter:
    Fábio Franco Uechi
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: