On Monday 28 January 2008, Jason van Zyl wrote: > How did anything without a POM get into the m2 repository? > > From the m1 conversion (which we should turn off now)? > > From syncing partners?
Definitely from syncing partners is a huge one. I know the ws commons group at apache is REALLY bad about getting poms into their stuff on a consistent basis. Some releases do, but then the very next release might not. 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. 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]
