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]

Reply via email to