Jörg,
thank you for this additional words. Actually it was not clear to me that I cannot tell Maven that a dependancy has to be taken "as it is" (without adding a version number). Certainly it is well known to me that Maven has a version adding facility, but it is not written somewhere that it cannot be "switched off". Also I think writing a request for enhancement will get rejected in any ways: My proposal would be to add a pom entry that specifies "Maven: This is the actual JAR name, do not try to further do anything with it.".No need to, it will be rejected. See, how could Maven ever locate and download a unique artifact without a version? That's one of the critical poiints providing a POM for a library that is not build with Maven. First you have to look at the provided docs to learn about the deps and their versions, then you'll examine the provided jars - since the docs are often out of date. If the jars have versions in their names, good. If not, look at the manifest and take the implementation version. If the manifest is vanilla, it gets problematic. I meanwhile take the date of the manifest itself in the jar for such a version:org.whatever.group:archive-with-vanilla-manifest:20040323.123456 And it can be cumbersome if you try to publish the pom here - for FOP I also had to provide the POMs for the JAI artifacts ... But any of this actions does not help if the original artifact defines a classpath in its manifest. There are two problems: 1/ the referenced artifacts have no version 2/ Maven selects a different version integrating the artifact into a container First problem is not solvable - at least not within the public repo. Second problem might just indicate a version problem that cannot be solved either, since Maven has a reason to select a different version, becasue other artifacts reference the same dep in a different version. To resolve your case, I would first establish a private repo for your group/company. Then create a FOP jar without that classpath entry (e.g. with version 0.20.5-company-1) and add it to this repo. The use a company wide global POM where you define in the dependencyManagement that FOP version. Nevertheless you have to know, that any other 'public' artifact depending on FOP will reference the other version, so you have to take care of this. The only possible solution for ibiblio would be a release of the jar without the manifest entry from the FOP team. But I doubt that will ever happen, since they work since years on the next version ;-)
Markus
begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R & D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R & D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard
smime.p7s
Description: S/MIME Cryptographic Signature
