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]
