If you deploy your final release to an app server that is J2EE 1.4 compliant, then your application will break currently, due to the bug I reported. That's why I want to fix it. If your customer has this problem, the your support officer will look into the bug database before doing anything else first, where he will find that this is known bug that is to be fixed by updating the local repo of the customer to mirror the meanwhile fixed fop. What's nightmare with that? It's even better than setting up a test environment and let the supporter reconstruct the problem. BTW, if you are J2EE compliant, you are deploying EARs, which actually are unchanged for your and for your customers. If you change the FOP due to my fix, your EAR's version has definitively changed and you will see this.But it would be beneficial for you since I would change it in a way that FOP is valid for everyone, so you can remove your workarounds. Since in your case the Class-Path isn't taken into account anyways as you wrote, what have you lost?Reproducability! If we deploy our final release to an app server that is compliant to the spec in this way, well, then it breaks. Now consider a we get back a bug report, the assigned developer checks out the version and tries to debug it ... and since he gets now suddenly a different FOP cannot reproduce the error. *THIS IS MAINTENACE NIGHTMARE*! And that's why a final release must never change. If we build a mainenance release including fop-0.20.5-mvn-1 it is obvious that we use a different version and that *new* version is supposed to fix the problem.
How do you want to hold off me from doing it? Everybody told me this is a free land and nobody controls the repo...Therefore the only way to fix the repo is to release something new. Andf the right thing is to have a new version with a jar that does not have a classpath entry in the manifest! If you have two artfiacts with such entries referencing the same dep in different version, you cannot even build an EAR with Maven containing both libraries.
Btw, please read the J2EE 1.4 + MANIFEST.MF specifications. It seems you're not aware of the need of correct Class-Path: settings to get the J2EE certified logo.
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
