I still don't see what's wrong with that. I know it can break your build, but people don't think those [WARN] messages in the cmdline and the fact that maven is hitting the internet trying to download the missing pom everytime, are the sign of a problem ???
On Jan 28, 2008 11:48 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > On Monday 28 January 2008, Jason van Zyl wrote: > > On 28-Jan-08, at 11:30 AM, Daniel Kulp wrote: > > > What's worse is if someone reports a missing pom, they then go and > > > add a > > > FULL pom with deps which then gets synced to central. That could > > > cause > > > issues as we all know. > > > > Are you serious? > > Yep. They did it for neethi just last week. Look at the time stamps > at: > > http://repo1.maven.org/maven2/org/apache/neethi/neethi/2.0.2/ > > > Dan > > > > > > > > Dan > > > > > >> On 28-Jan-08, at 11:10 AM, Carlos Sanchez wrote: > > >>> i'm talking about things that are already there without pom > > >>> > > >>> On Jan 28, 2008 11:07 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > >>>> If there is no POM you should just reject it and send it back. If > > >>>> we automated this, which we will, it would fail. You can't know > > >>>> as a third party what is correct. > > >>>> > > >>>> On 28-Jan-08, at 10:51 AM, Carlos Sanchez wrote: > > >>>>> 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] > > >>>> > > >>>> Thanks, > > >>>> > > >>>> Jason > > >>>> > > >>>> ---------------------------------------------------------- > > >>>> Jason van Zyl > > >>>> Founder, Apache Maven > > >>>> jason at sonatype dot com > > >>>> ---------------------------------------------------------- > > >>>> > > >>>> happiness is like a butterfly: the more you chase it, the more it > > >>>> will > > >>>> elude you, but if you turn your attention to other things, it > > >>>> will come > > >>>> and sit softly on your shoulder ... > > >>>> > > >>>> -- Thoreau > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> ----------------------------------------------------------------- > > >>>>-- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For > > >>>> additional commands, e-mail: [EMAIL PROTECTED] > > >>> > > >>> -- > > >>> 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] > > >> > > >> Thanks, > > >> > > >> Jason > > >> > > >> ---------------------------------------------------------- > > >> Jason van Zyl > > >> Founder, Apache Maven > > >> jason at sonatype dot com > > >> ---------------------------------------------------------- > > >> > > >> > > >> > > >> > > >> > > >> ------------------------------------------------------------------- > > >>-- To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > > > 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, > > > > Jason > > > > ---------------------------------------------------------- > > Jason van Zyl > > Founder, Apache Maven > > jason at sonatype dot com > > ---------------------------------------------------------- > > > > What matters is not ideas, but the people who have them. Good people > > can fix bad ideas, but good ideas can't save bad people. > > > > -- Paul Graham > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > > 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] > > -- 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]
