Wayne Fay schrieb:
As previously mentioned, it is quite honestly not possible to "fix" that specific version of the pom. For a very brief period of time, Maven was allowing changes to poms but then realized this was a bad idea. So instead the proper way to fix issues like this is to actually release a new version of the Maven artifact including an updated pom.
That's why I am asking for the name of the maintainer, so that I can ask him to do that...
As for the question "who is the maintainer of this pom" -- unless the FOP team has specifically taken over the Maven artifact for their project, **anyone** can be the maintainer. This means you, or me, or any one else interested enough in Maven and FOP to actually do the work and submit the Maven Upload JIRA.
So anyone can just put up some buggy JARs into that repository.Do you think this to be beneficial for the overall quality of the content...?
In this case, I would suggest the following, as you appear to be very well versed in this particular artifact and it sounds like the FOP team does not currently maintain the pom file...
Not only not currently. THEY HAVE NEITHER WRITTEN IT. THE FOP TEAM DOES NOT AT ALL KNOW OF ITS PURE EXISTENCE.
Clear now? ;-)
Download the FOP source code (or binary if you won't compile it) for version 0.20.5 Download the pom.xml for version 0.20.5 Alter the pom.xml as needed and bump version to 0.20.5.1 Compile the source code if needed and package the JAR Create the Maven artifact bundle using the new 0.20.5.1 pom (Install this artifact in your local repo and make sure it works like you expect by using it in your project, check the Class-Path etc) Create a new Maven JIRA for this new version and attach your new bundle to the issue Wait for feedback from Carlos et al and hope you didn't screw anything up; if so, adjust your bundle as requested and re-upload Once accepted, the new artifact will appear in Central
So actually Carlos is the maintainer? That's all I liked to know actually. So I'll look into doing that.
This is your best approach (imo) to get this updated FOP artifact installed in the Maven Repo. Unless of course someone else has a better suggestion... You asked about "quality control" previously... The assumption is that the people contributing builds to Maven are competent enough to create proper builds with reasonable pom.xml files etc. Ideally every Java project will eventually take over as maintainers of the Maven artifact but this is not required, nor is it entirely reasonable to expect it to ever occur.
You need to know that our company is deeply involved into the business of quality assurance. So what you write is wrong. Nobody can rely on others to be good enough. You need to control quality EVER. As a proof, see the FOP project. Nobody knows where the author of that buggy pom.xml was, and it needed a two days discussion on how to fix it.
That's not quality assurance, that's pure random.This is acceptable for any repository, but not for that one that is listed automatically with every installation of Maven 2.0.4.
While there is some checking and testing before artifacts are installed into Central, in general, its not reasonable to expect the handful of Maven Repo maintainers to know everything about every project, so instead they simply trust the community and provide a way to "easily" update the artifacts, so when problems appear, the community can "easily" take care of it. Maven automatically looks for updates to artifacts, so new versions are pulled down and used as they are made available.
Well, in case of FOP this trust doesn't seem to work... 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
