There's still around 5 releases every month only at apache that go to the m1 repo (most of them with poms).
I'd rather have the official jars being deployed without poms than do it manually, and accept anybody's upload request for let's say Tomcat, with all the problems that it could cause. . On Jan 28, 2008 11:39 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > On 28-Jan-08, at 11:33 AM, Carlos Sanchez wrote: > > > from m1 syncing partners that didnt have poms > > > > We should just shut off the m1 conversion. Happy to support the m1 > repository mapping, but that process is broken not to mention it pegs > the machine when it runs. > > > > On Jan 28, 2008 11:25 AM, Jason van Zyl <[EMAIL PROTECTED]> 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? > >> > >> > >> 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] > >> > >> > > > > > > > > -- > > 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 > ---------------------------------------------------------- > > Our achievements speak for themselves. What we have to keep track > of are our failures, discouragements and doubts. We tend to forget > the past difficulties, the many false starts, and the painful > groping. We see our past achievements as the end result of a > clean forward thrust, and our present difficulties as > signs of decline and decay. > > -- Eric Hoffer, Reflections on the Human Condition > > > > > > --------------------------------------------------------------------- > 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]
