if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long
On Jan 28, 2008 8:19 AM, Tamás Cservenák <[EMAIL PROTECTED]> wrote: > 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~ > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
