Antoine Levy-Lambert wrote:
This is a valid point. Ideally POMs should only come from the project
releasing the binaries, not from its users.
SHOULD as opposed to MUST, in RFC terms.
Nobody wants to write the POMs, but as Maven effectively forces you to
get all your dependencies from a repository, if you want to build with
something, you need the Pom in there, even if it is a stub with no
dependencies (which are how most of my poms are, BTW). By letting users
contribute that stuff back, only one person has to do the work.
The hope is that that one person gets it right, else a mistake is hard
coded in wrong, forever.
I myself sent an upload request for jsch with initially a wrong groupId
of jsch and not com.jcraft. This was fixed later by Carlos Sanchez.
Users of libraries who need Maven uploads should contact the library
provider and make them create their own POMs.
;-) So I have to contact jcraft concerning POMs, I did not do it until now.
Naughty.
Realistically, your release manager will not want to make a 1.0.1
release because of the wrong POM.
But projects which provide their own POMs should consider the POMs as
part of their sources.
Better have a test process for it, then. Something to audit the md and
verify that all the artifacts are available.
This means that if people have issues with the Ant POMs after 1.7.0 is
out, IMHO they should create bug reports in bugzilla with a patch attached,
and wait until the next release.
Well, you have added a comment saying 'talk to the ant team about these
poms' to each one, though I'd be happier if the poms were driven off
lib/libraries.properties, as I've stated before. The risk now is that
those poms will age badly, with new releases of ant having poms out of
sync with the source. That is, unless you can get continuum or to build
ant from source using them.
As I stated earlier on in this discussion: every artifact's metadata
ought to inclue information about the origin of the metadata, rather
than just the artifact. Both groups could leave space for dublin-core
author metadata about both, just with something in the schema, elements
<artifactinfo> and <metadatainfo> of type xsd:any xmlns="##other".
-Steve
-steve
