An example of it's use is provided on the maven doco site
classifier:
The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. ...
As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use.
I have two jars which are JDK specific, one depends on the other (version). This means I have 4 jars.
bcprov-jdk16-141.jar
^ depends - bcpg-jdk16-141.jar
bcprov-jdk15-141.jar
^ depends - bcpg-jdk15-141.jar
This is of course, bouncy castle, and am using it with camel-crypto component for Camel. Bouncy castle comes in a version for each JDK, one for JDK 1.5, one for JDK 1.6. Great! The classifier is a case for this.
The code I will be writing primarily depends on bcpg (PGP implementation). So if I just depend on it, it will (should) pull in the parent bcprov.
A few things I noted when creating the pom changes was that
(first) The name of the bouncycastle jar is names as
bcprov-jdk16-141.jar
Maven puts the classifier "after" the version.
arbitrary string that - if present - is appended to the artifact name just after the version number.So .. under maven, the bouncy castle jar should be
bcprov-141-jdk16.jar
bcprov-${version}-${classifier}.jar
At first, no worries, the bcprov jar up on ibiblio is old anyway and is missing the other jar I need which is bcpg, the PGP implementation. (the bit I want to add for Camel).
Putting this altogether:
in the root pom, we need to get a "property" version string so we can use it in the classifier.
<!-- set a property for the jdk version we are using based on the match of the jdk in use -->
<profile>
<id>jdk16</id>
<activation><jdk>1.6</jdk></activation>
<properties><jdk-version>jdk16</jdk-version></properties>
<profile>
<id>jdk15</id>
<activation><jdk>1.5</activation>
<properties><jdk-version>jdk15</jdk-version></properties>
In doing this, we will have ${jdk-version} as a property. This leads to a dependency like
<dependency>
<groupid>bouncycastle</groupid>
<artifactid>bcpg</artifactid>
<version>${bouncycastle-version}</version>
<classifier>${jdk-version}</classifier>
</dependency>
The last bit to resolve is to install the renamed jars into my local repository and have bcpg depend on bcprov. But this is where maven fell over. One classifer jar and another, share the same "non" classifier pom.
mvn install:install-file -DgroupId=bouncycastle -DartifactId=bcpg -Dversion=141 -Dclassifier=jdk16 -Dpackaging=jar -Dfile=/home/rbuckland/datastore/java/bcpg-jdk16-141.jar
This will then put in the renamed jar bcpg-jdk16-141.jar as bcpg-141-jdk16.jar.
Where it falls over. Maven2 has one pom for all classif(ied)er versions. So the listing for the repository is thus
ls /home/rbuckland/.m2/repository/org/bouncycastle/bcpg/141/
bcpg-141-jdk15.jar
bcpg-141-jdk16.jar
bcpg-141.pom
Not a pom for each. So in the pom (above) i need to declare the dependency on bcprov, but of course , in this repository pom for bcpg,
(a) specificing no classifier, the dependency does not get picked up
(b) tried ${classifier} .. hopeful
(c) tried ${pom.classifier} .. hopeful
I gave up. So instead the workaround is that the "version" of the var encompasses the JDK version instead. ie:
<dependency>
<groupid>bouncycastle
</groupid>
<artifactid>bcpg</artifactid>
<version>${jdk-version}-${bouncycastle-version}</version>
And then we can do what we need (of note, with this, the original naming of the jar by bouncycastle team stays).
Ah well.
No comments:
Post a Comment