Good point, it's probably a bad idea to add a pom that contains any dependencies or other information that would affect the build of a project using the dependency. Although I think it would be safe to add information like project url, description, and license if those are available since those would not affect builds.
Brian Fox wrote: > Possibly if we introduce a pom that has the exact internal model maven > generates when it can't find one. This could cause some issues for > people who have their own versions of those poms. > > On Mon, May 3, 2010 at 2:05 PM, Paul Gier <pg...@redhat.com> wrote: >> Jason van Zyl wrote: >>> On May 3, 2010, at 12:10 PM, Benjamin Bentmann wrote: >>> >>>> Hi, >>>> >>>> somehow related to my previous question about the checksums, what are our >>>> chances to automatically detect and fix bad maven-metadata.xml's deployed >>>> to Central like seen in [0]? >>>> >>> While the content of the POMs is not something we can't really change, the >>> information about what artifacts exist I believe is something we can fix. >>> >> I agree that we can't change content of any existing poms. But can we add a >> basic pom where there is none? For example, I noticed that this artifact >> does >> not have any pom. >> >> http://repo2.maven.org/maven2/ws-commons/policy/1.0/ >> >>> I suppose the only downside is we might potentially change the results >>> someone is getting if they are using ranges. But ranges are used so >>> infrequently, and it really is undefined right now whether you would deploy >>> something with this range resolved or resolve against a repository with >>> fixed versions (more like OSGi). I think we could probably correct the >>> metadata with very little, if any, harmful impact. >>> >>> This is one area where I would likely side on changing the contents in >>> Maven Central. But how it's changed is another question. >>> >>> We could simply run over it with Nexus and fix it all. But if it's not >>> fixed at the source the cat will just come back. I think a real solution >>> involves something Brian and I have been talking about for a while where >>> project registers for ownership of a groupId. We could suggest fixes which >>> can be accepted and then tracking to any changes to this metadata would >>> also need to be recorded. >>> >>>> Benjamin >>>> >>>> >>>> [0] http://jira.codehaus.org/browse/MEV-658 >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> --------------------------------------------------------- >>> >>> Selfish deeds are the shortest path to self destruction. >>> >>> -- The Seven Samuari, Akira Kurosawa >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
