Hi, I'm with Jason here: once something is released, it should be carved into stone. The maven remote repository (every remote one, not just the central!) should only "move forward" in time. We cannot allow "backward" modification of artifacts since it may have unforeseeable consequences! Not to mention reproducibility...
Anyway, if you _must_ have the missing POM (or simply want to prepare for a new fixed release that will have one, and not to litter your own project with exclusions), it is easily resolvable by some advanced repository managers like Proximity. With Proximity -- for example -- you are able easily to "sneak" in (or even spoof if a broken exists remotely) the missing POM by grouping a central proxy repo with with a hosted repository -- where you keep these POMs to "fix" central. So, you could maintain a "thin layer" of repos data overlayed over "central" repo without breaking anything. Anyway, since maven "means infrastructure", it is to be expected from serious maven users to not connect directly to central (and be dependent of network outages for example) and use advanced repo managers to solve problems like this (broken deployments). Something as i see as a probable fix for situations when we are stuck (ie. the artifact is deployed wrongly but the project itself or it's staff is not interested in fixing it or are simply unreachable) is maybe to release/gather/share some sort of above mentioned "fix layers" for users to lay down on their MRMs and live with it. Or maybe make the deployment process more flexible, and allow repo maintainers to redeploy something -- even if it's origin project did not request it -- to fix something that is _obviously_ wrong. But, heh, deps are not those sort of things. ~t~ On Jan 27, 2008 6:58 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 25-Jan-08, at 5:22 PM, Carlos Sanchez wrote: > > > great, but > > - who is going to enforce it? > > - who is going to say what the right pom is for a project that doesnt > > build with Maven? > > > > If someone from a project submits a POM then we should take that. If > projects don't then we take a submission from the community. The base > requirement should be that the complete transitive closure be > available publicly and preferably in central. The new artifact > resolution code will be able to do this but right now if we required > correct SCM information then we could have a process grab the code and > try to build it for Maven projects. Oleg can speak to some of the work > in the new artifact code that can help ensure the integrity of > deployments. > > > there's still people saying that poms should be modifiable! > > > > For a release it cannot be modifiable, period. The graph cannot be > mutable after a release. That has to be written in stone. If someone > doesn't see something and made a mistake then they have to release > again. > > It boils down to we get strict or this body of information we have > will grow less useful over time and that's all there is to it. > -- Thanks, ~t~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
