While I completely agree about the poms needing to be "carved in stone", I really DON'T agree with the requirement to "use advanced repo managers to solve problems like this".
That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the "works for me" response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the <licenses> section, <organization> section, url, description, etc.... ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if they use that metadata. (example: remote-resources) Dan On Monday 28 January 2008, Tamás Cservenák wrote: > 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. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
