Daniel, i think we talk about two things here:
- to fix/modify retroactively already deployed poms and/or repo content - and i believe we both agree it is a disaster to do so. - to prevent failed download request every time the project is built. I was talking about the second problem, with corporate users in my mind. And that means, on possibly close projects in controlled environment. I completely agree with your arguments. I was just trying to give a "hint" for corporate users how to get rid of these failed downloads. For OSS projects/users, currently the only solution is to get people (interested maven user community) on to feet and push (demand) the affected project owners/maintainers to do something about it, to make them create deployment requests with good/valid POMs. It simply resembles me the situation to linux RPM reposes. And a solution i like from there is the "disconnection" (or extension) of the actual payload (project) versioning from the RPM (atifact) versioning, and the ability to republish a wrongly packaged RPM with _same_ payload but with increased "full name", ie. AProject-1.0.0-1.rpm versus AProject-1.0.0-2.rpm. Actually, this is what we are talking about here, right? ~t~ On Jan 28, 2008 3:54 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > 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] > > -- Thanks, ~t~
