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]
