Dan,what you write sounds good, we will set up our own repository and put our own fop-0.20.5 on it. On the other hand, its not nice to have a "private" fop while there is global repository already hosting one. The fix cannot be done ONLY by fixing the pom, because fop is dependent on other apache projects that have the same fault (register in repo1.maven.org with JARs that are not in sync with their POMs), so supplying our locally implemented fix will not a globally working solution. Remember, we are Maven starters and so we do not have to knowledge to solve this problem on our own all alone. But if the authors of that other projects will help us, we can coordinate work to make it work finally. Unfortunately it seems, they do NOT want to help us (at least for now) :-(
Markus dan tran schrieb:
If you rely on your customer to build your product, it is best to
have your own repo to
solve this kind of crisis. Have maven to search artifact first before
going to central
In the mean time, It seems you can fix the problem by fixing the pom
right?
why not submit it back?
-D
On 9/19/06, *Markus KARG* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Bruno Aranda schrieb:
> Well, probably the development community of the Apache Fop
project can
> help you. Check the project site [1].
I have asked them.
They don't know.
They even didn't know that FOP is available on that repository.
So someone just put it up there without their knowledge!
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
