You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@maven.apache.org by Jochen Wiedmann <jo...@gmail.com> on 2007/10/04 17:09:22 UTC

Fix missing POM files

Hi,

repo1.maven.org contains a number of jar files without POM. Examples
include woodstox/wstx-asl/3.0.2/, or castor/castor/1.0/. As these are
quite a pain in the development by causing unnecessary and failed
download requests every time, I'd like to fix this, at least for those
where I note it.

Question is how. Suggestion: Create new upload bundles under com.ctc
(woodstox), or org.exolab (Castor)? Other ideas?

Thanks,

Jochen

-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

I still don't see what's wrong with that. I know it can break your
build, but people don't think those [WARN] messages in the cmdline and
the fact that maven is hitting the internet trying to download the
missing pom everytime, are the sign of a problem ???

On Jan 28, 2008 11:48 AM, Daniel Kulp <dk...@apache.org> wrote:
> 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 <ja...@maven.org> 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 <ta...@cservenak.net>
> > >>>>>
> > >>>>> 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 <dk...@apache.org> 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 <ja...@maven.org>
> 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
> > >>>>>>> dkulp@apache.org
> > >>>>>>> http://www.dankulp.com/blog
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --------------------------------------------------------------
> > >>>>>>>-- ----- To unsubscribe, e-mail:
> > >>>>>>> dev-unsubscribe@maven.apache.org For additional commands,
> > >>>>>>> e-mail: dev-help@maven.apache.org
> > >>>>>>
> > >>>>>> --
> > >>>>>> 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: dev-unsubscribe@maven.apache.org
> > >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>
> > >>>> 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: dev-unsubscribe@maven.apache.org For
> > >>>> additional commands, e-mail: dev-help@maven.apache.org
> > >>>
> > >>> --
> > >>> I could give you my word as a Spaniard.
> > >>> No good. I've known too many Spaniards.
> > >>>                            -- The Princess Bride
> > >>>
> > >>> ------------------------------------------------------------------
> > >>>-- - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > >>> additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >> Thanks,
> > >>
> > >> Jason
> > >>
> > >> ----------------------------------------------------------
> > >> Jason van Zyl
> > >> Founder,  Apache Maven
> > >> jason at sonatype dot com
> > >> ----------------------------------------------------------
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> -------------------------------------------------------------------
> > >>-- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > --
> > > J. Daniel Kulp
> > > Principal Engineer, IONA
> > > dkulp@apache.org
> > > http://www.dankulp.com/blog
> > >
> > > --------------------------------------------------------------------
> > >- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
>
> J. Daniel Kulp
> Principal Engineer, IONA
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Daniel Kulp <dk...@apache.org>.

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 <ja...@maven.org> 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 <ta...@cservenak.net>
> >>>>>
> >>>>> 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 <dk...@apache.org> 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 <ja...@maven.org> 
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
> >>>>>>> dkulp@apache.org
> >>>>>>> http://www.dankulp.com/blog
> >>>>>>>
> >>>>>>>
> >>>>>>> --------------------------------------------------------------
> >>>>>>>-- ----- To unsubscribe, e-mail:
> >>>>>>> dev-unsubscribe@maven.apache.org For additional commands,
> >>>>>>> e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>> --
> >>>>>> 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: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>> 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: dev-unsubscribe@maven.apache.org For
> >>>> additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>> --
> >>> I could give you my word as a Spaniard.
> >>> No good. I've known too many Spaniards.
> >>>                            -- The Princess Bride
> >>>
> >>> ------------------------------------------------------------------
> >>>-- - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> >>> additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder,  Apache Maven
> >> jason at sonatype dot com
> >> ----------------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------------------
> >>-- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer, IONA
> > dkulp@apache.org
> > http://www.dankulp.com/blog
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Jason van Zyl <ja...@maven.org>.

On 28-Jan-08, at 11:30 AM, Daniel Kulp wrote:

> 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.
>

Then they get moved to submitting via JIRA. Carlos if they truly suck  
and they are abusing the direct access to the repository then we  
should turn off syncing from all the WS-* projects until they sort  
their shit out. They can potentially screw everyone.

> 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?

> 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 <ja...@maven.org> 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 <ta...@cservenak.net>
>>>>>
>>>>> 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 <dk...@apache.org> 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 <ja...@maven.org> 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
>>>>>>> dkulp@apache.org
>>>>>>> http://www.dankulp.com/blog
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> ----- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>> --
>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> --
>>> I could give you my word as a Spaniard.
>>> No good. I've known too many Spaniards.
>>>                            -- The Princess Bride
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> -- 
> J. Daniel Kulp
> Principal Engineer, IONA
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Daniel Kulp <dk...@apache.org>.

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 <ja...@maven.org> 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 <ta...@cservenak.net>
> >>>
> >>> 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 <dk...@apache.org> 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 <ja...@maven.org> 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
> >>>>> dkulp@apache.org
> >>>>> http://www.dankulp.com/blog
> >>>>>
> >>>>>
> >>>>> ----------------------------------------------------------------
> >>>>>----- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>> --
> >>>> 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: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> 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: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

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 <ja...@maven.org> 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 <ja...@maven.org> 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 <ja...@maven.org> 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 <ta...@cservenak.net>
> >>>>> 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 <dk...@apache.org> 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 <ja...@maven.org> 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
> >>>>>>> dkulp@apache.org
> >>>>>>> http://www.dankulp.com/blog
> >>>>>>>
> >>>>>>>
> >>>>>>> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> 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: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>
> >>>> 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: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> I could give you my word as a Spaniard.
> >>> No good. I've known too many Spaniards.
> >>>                            -- The Princess Bride
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder,  Apache Maven
> >> jason at sonatype dot com
> >> ----------------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Jason van Zyl <ja...@maven.org>.

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 <ja...@maven.org> 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 <ja...@maven.org> 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 <ta...@cservenak.net>
>>>>> 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 <dk...@apache.org> 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 <ja...@maven.org> 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
>>>>>>> dkulp@apache.org
>>>>>>> http://www.dankulp.com/blog
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> I could give you my word as a Spaniard.
>>> No good. I've known too many Spaniards.
>>>                            -- The Princess Bride
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
>
> -- 
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

from m1 syncing partners that didnt have poms

On Jan 28, 2008 11:25 AM, Jason van Zyl <ja...@maven.org> 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 <ja...@maven.org> 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 <ta...@cservenak.net>
> >>> 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 <dk...@apache.org> 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 <ja...@maven.org> 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
> >>>>> dkulp@apache.org
> >>>>> http://www.dankulp.com/blog
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >> 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: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Jason van Zyl <ja...@maven.org>.

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 <ja...@maven.org> 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 <ta...@cservenak.net>  
>>> 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 <dk...@apache.org> 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 <ja...@maven.org> 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
>>>>> dkulp@apache.org
>>>>> http://www.dankulp.com/blog
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
>
> -- 
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

i'm talking about things that are already there without pom

On Jan 28, 2008 11:07 AM, Jason van Zyl <ja...@maven.org> 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 <ta...@cservenak.net> 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 <dk...@apache.org> 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 <ja...@maven.org> 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
> >>> dkulp@apache.org
> >>> http://www.dankulp.com/blog
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Jason van Zyl <ja...@maven.org>.

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 <ta...@cservenak.net> 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 <dk...@apache.org> 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 <ja...@maven.org> 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
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>>
>> --
>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

given these premises
- pom is not in the repo
- project is not willing to put it

then authoritative data can come from project users, after all this is
a community.

As i said before my opinion is that we can still put poms in projects
that didnt have them


On Jan 28, 2008 11:27 AM, Tamás Cservenák <ta...@cservenak.net> wrote:
> Heh, so you are willing to trade "build reproducibility" (for all
> projects linked to central repo) for "care about the community"?   o.O
>
> Hrm, please put that on a vote before you do it!
>
> IF you are talking about putting up "dummy" (depsless, only GAV) POMs:
> IMHO, by putting "dummy" poms (without dependency to not screw
> existing builds), only ones with GAV, you do not provide any value to
> community: OSS projects usually move fast, and will quickly switch to
> newer (hopefully fixed) artifacts from central with correct POMs. And
> the companies will... heh, they will use some "advanced repo manager"
> to solve it ;D
>
> IF not, how would you be able to get authoritative data to fill in the
> missing POMs?
>
> Thanks,
> ~t~
>
> On Jan 28, 2008 7:51 PM, Carlos Sanchez <ca...@apache.org> 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there,
| Heh, so you are willing to trade "build reproducibility" (for all
| projects linked to central repo) for "care about the community"?   o.O
|
| Hrm, please put that on a vote before you do it!
|
| IF you are talking about putting up "dummy" (depsless, only GAV) POMs:
| IMHO, by putting "dummy" poms (without dependency to not screw
| existing builds), only ones with GAV, you do not provide any value to
| community: OSS projects usually move fast, and will quickly switch to
| newer (hopefully fixed) artifacts from central with correct POMs. And
| the companies will... heh, they will use some "advanced repo manager"
| to solve it ;D
The content of such poms is no real value but it stops millions of
totally useless requests towards ibiblio and produces longer builds and
stupid warnings. So it is more a denial-of-service attack that should be stopped.
Look at axis2 with all its dependencies! There is no newer version out
and I have about 50-100 useless requests to missing poms per day.
My project team has 10 developers so multiply this by ten.
I am also using maven for my open-source project. Same result.
As ibiblio if you can get a 404 statistic.

When you change the version of one of your dependencies you always have to
face the fact that transitive dependencies change. That has nothing to
do wheter the earlier version had just a stupid GAV pom or not.

Adding a pom with additional dependencies afterwards causes a change
of transitive dependencies in projects that did not change anything.
Please note that business projects need a config-management where
deployment is audit-proof and rebuilding a release on an old tag
should still have the same result as it had when the tag was created.
As people describe there is a workaround to solve this issue for
enterprises but if they dont why should we cause such trouble if
there is no need to do so.

Ahh - I read your posting again. You were not talking about dependencies
in the later added poms but in the next version. So my last paragraph
was not directly related to what you were saying...
|
| IF not, how would you be able to get authoritative data to fill in the
| missing POMs?
|
| Thanks,
| ~t~
|
| On Jan 28, 2008 7:51 PM, Carlos Sanchez <ca...@apache.org> 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
|>
|
Regards
~  Jörg
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
| For additional commands, e-mail: dev-help@maven.apache.org
|
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHoOyLmPuec2Dcv/8RAjbqAJ4m22dFzvlNd248uJNICYhc7eUVNQCfWkO1
ZNrRQwYYbbD439sTOJahMM0=
=4TsK
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Tamás Cservenák <ta...@cservenak.net>.

Heh, so you are willing to trade "build reproducibility" (for all
projects linked to central repo) for "care about the community"?   o.O

Hrm, please put that on a vote before you do it!

IF you are talking about putting up "dummy" (depsless, only GAV) POMs:
IMHO, by putting "dummy" poms (without dependency to not screw
existing builds), only ones with GAV, you do not provide any value to
community: OSS projects usually move fast, and will quickly switch to
newer (hopefully fixed) artifacts from central with correct POMs. And
the companies will... heh, they will use some "advanced repo manager"
to solve it ;D

IF not, how would you be able to get authoritative data to fill in the
missing POMs?

Thanks,
~t~

On Jan 28, 2008 7:51 PM, Carlos Sanchez <ca...@apache.org> 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

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 <ta...@cservenak.net> 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 <dk...@apache.org> 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 <ja...@maven.org> 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
> > dkulp@apache.org
> > http://www.dankulp.com/blog
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
>
> --
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Tamás Cservenák <ta...@cservenak.net>.

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 <dk...@apache.org> 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 <ja...@maven.org> 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
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
Thanks,
~t~

RE: Fix missing POM files

Posted by "Brian E. Fox" <br...@reply.infinity.nu>.

I think it's simple and is what we've been doing. Once it hits the central repo, it's done...no changes to anything period. 

The advanced repo manager thing is a workaround for sure, but in an enterprise a very valid and frequently used one. It obviously doesn't help OOS projects, but changing the things in the repos breaks stuff for everyone.

Re: Fix missing POM files

Posted by Daniel Kulp <dk...@apache.org>.

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 <ja...@maven.org> 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
dkulp@apache.org
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Tamás Cservenák <ta...@cservenak.net>.

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 <ja...@maven.org> 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.
>

-- 
Thanks,
~t~

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Jason van Zyl <ja...@maven.org>.

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.

> and the fact that maven is ready for business doesnt mean taht you can
> use anything however you want, you should enforce policies on what
> plugin versions you want, what third party libraries,... because we
> may take decisions here that will affect the decisions at some
> companies, while not at others. Many times there's not black or white
>
>
> On Jan 25, 2008 4:16 PM, Joerg Hohwiller <jo...@j-hohwiller.de> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi there,
>>
>> I am sometimes late on threads but anyways...
>>
>> | i don't agree, the point of not having a pom there is to be able to
>> | add one later with the right info. If you work against something
>> | without pom, hey, it's your decision, but you are aware that it's a
>> | problem, as all the warnings tell you
>> I do NOT agree. Adding a jar and later some pom with dependencies is
>> odd. You should enforce that no artifacts can go to central repro
>> if they do not come with a proper pom.
>> To fix the actual problem default poms should be added to
>> the repository. Further versions of these artifacts can add the
>> correct dependencies.
>> Please consider that maven is not just used by open-source users  
>> for fun but
>> also by brute business. If some company is running a deployment
>> that comes to a wrong result because of dependencies in a
>> pom that was just added to the repository (e.g. because then a  
>> different version
>> than before was chosen for a dependent artifact), they will flame  
>> maven.
>> Don't we say that maven is also ready for business?
>> Do you have an idea how much harm the maven community has done to  
>> enterprise
>> (and other) users by releasing buggy plugins?
>> I do not want to blame anybody! Giving your spare time for open- 
>> source is
>> worth some honor and humans make mistakes. But we should be aware  
>> of the
>> sensibility of our decisions.
>>
>> Best regards
>> ~  Jörg
>>
>> |
>> | On 10/15/07, William Ferguson <Wi...@yarris.com> wrote:
>> |> Isn't the goal here to stop incessant warnings during a build  
>> about
>> |> trying to downalod a missing POM?
>> |>
>> |> The way to do that is to that is to upload a POM for that  
>> artifact to
>> |> the repository.
>> |>
>> |> But Nico is right is that the uploaded POM should not break  
>> existing
>> |> builds. Which means that the POM just needs to be bare bones and  
>> list no
>> |> dependencies as the missing POM introduces no deps.
>> |>
>> |> So Nico, I'd suggest you create a simple POM with just groupId,
>> |> artifactId and version and get it uploaded to the repository.
>> |>
>> |> Can I also suggest that it is a worthy task to auto generate and  
>> upload
>> |> such POMs for all artifacts in central with a missing POM.
>> |>
>> |> William
>> |>
>> |>
>> |> -----Original Message-----
>> |> From: carlossg@gmail.com [mailto:carlossg@gmail.com] On Behalf  
>> Of Carlos
>> |> Sanchez
>> |> Sent: Tuesday, 16 October 2007 2:01 AM
>> |> To: Maven Developers List
>> |> Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files -  
>> Email has
>> |> different SMTP TO: and MIME TO: fields in the email addresses
>> |>
>> |> sorry, but that's not the case currently. If it has no metadata  
>> it can
>> |> be added, that's why you get warnings when the metadata is  
>> missing.
>> |>
>> |> On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
>> |>> I fully agree about collaborating and submitting more artifacts  
>> to the
>> |>> repo with good meta-datas. The only issue I can see is about
>> |>> reproductible builds if those meta-datas change.
>> |>>
>> |>> The established rule NOT to change meta-datas after publication
>> |>> applies IMHO also to artifacts without meta-datas. Anyone  
>> providing
>> |>> metadatas for an artifact that is allready in repo, so that can  
>> be
>> |>> used by many people, will potentialy break there builds, with  
>> no way
>> |>> in maven2 to quickly fix this issue by stopping the transitive
>> |> dependencies.
>> |>> Nico.
>> |>>
>> |>> 2007/10/15, Carlos Sanchez <ca...@apache.org>:
>> |>>> On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
>> |>>>> I'm not the guy who uploaded castor 1.0 on the maven repo,  
>> and I'm
>> |>>>> also
>> |>>> not
>> |>>>> the guy who used it in the project. I came later and have to
>> |>>>> maintain
>> |>>> the
>> |>>>> project now.
>> |>>> that's collaboration ;) if you want to use something that uses
>> |>>> castor and want to do it the right way, yes you should  
>> contribute a
>> |>>> pom
>> |>>>
>> |>>>> Do you think I should contribute an empty POM just to ensure
>> |>>>> no-one can latter contribute one with some (maybe) unexpected
>> |> dependencies ?
>> |>>> not an empty pom, but it shouldn't take more than 10 min to  
>> figure
>> |>>> out what the dependencies are
>> |>>>
>> |>>>> A better solution IMHO should be to have an option for a
>> |>>>> dependency in
>> |>>> my
>> |>>>> POM to excludes all transitive dependencies. The current
>> |>>>> <exclusion> elements require to list dependencies. With such a
>> |>>>> feature, a project
>> |>>> that
>> |>>>> has legacy reference on a dependency with no POM can simply set
>> |>>>> no-transitivity to be reproductible in any case.
>> |>>> that's already filled in jira
>> |>>>
>> |>>>> Many artifacts in the repo don't have POMs (from m1 -> m2
>> |>>>> migration ?)
>> |>>> not lately but old ones, yes
>> |>>>
>> |>>>> Nico.
>> |>>>>
>> |>>>> 2007/10/15, Carlos Sanchez <ca...@apache.org>:
>> |>>>>> On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
>> |>>>>>> Warning : This could break existing projects !
>> |>>>>>>
>> |>>>>>> My project has a dependency on castor-1.0. This one has no
>> |> POM.
>> |>>>>>> If you povide one, rebuilding my app will introduce new
>> |>>>>>> transitive dependencies that were not expected, and my build
>> |>>>>>> will become non-reproductible.
>> |>>>>>>
>> |>>>>>> Only new release of an artifact can come with a POM.
>> |>>>>>
>> |>>>>> mmm, that's not the case, you shouldn't made releases of  
>> things
>> |>>>>> without poms, you should have contributed one already
>> |>>>>>
>> |>>>>>
>> |>>>>>> Nico.
>> |>>>>>>
>> |>>>>>> 2007/10/11, Jochen Wiedmann <jo...@gmail.com>:
>> |>>>>>>> On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:
>> |>>>>>>>
>> |>>>>>>>> http://maven.apache.org/guides/mini/guide-maven-evangelism
>> |>>>>>>>> .html
>> |>>>>>>> Quoting from that text:
>> |>>>>>>>
>> |>>>>>>> ... unless you provide a pom for it ...
>> |>>>>>>>
>> |>>>>>>> I am ready to do that, at least in the cases that harm me.
>> |>>>>>>> But
>> |>>> how?
>> |>>>>>>> Through the standard upload procedure?
>> |>>>>>
>> |>>>>> <quote>open an issue at JIRA MEV  with the relevant  
>> information
>> |>>> </quote>
>> |>  
>> ---------------------------------------------------------------------
>> |> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> |> For additional commands, e-mail: dev-help@maven.apache.org
>> |>
>> |>
>> |
>> |
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.5 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iD8DBQFHmnvimPuec2Dcv/8RAm1MAJ0enhk25RE+HnobPXMl9Ap7U922KQCfX/tu
>> S0jzEznAiXh9hBK1V3qK6+Q=
>> =g77f
>> -----END PGP SIGNATURE-----
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
>
> -- 
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                         -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Carlos,
| great, but
| - who is going to enforce it?
Sorry, I can not tell. Of course this is not easy to do.
But you do have policies for your repository. It seems
that they are not enforced or not strong enough.
The best thing for a formal rule is to have a technical
solution that prevents the rule to be violated.

I just wanted to make sensible for the impact of changing
the repository.
| - who is going to say what the right pom is for a project that doesnt
| build with Maven?
Another good question. However, in our case we were talking about
artifacts that have no pom. Then maven assumes a default pom with no
dependencies. All that was suggested was to add this default pom explicitly.
If this is wrong, it was wrong from the time the artifact was added.
The policy is not to change artifacts after they have been deployed.
So the project has to deploy a new version if the pom is wrong!

A technical answer for your question is that you can use things like classpath
helper to answer this. Anyhow you are right, that only to project owners should
decide how there pom should be like. IMHO this is not the question here for
the version that is already released.
|
| there's still people saying that poms should be modifiable!
The chaos is already big enough. Please do not make it worse!
Poms are modifyable but they should not be for releases in repositories like our
central repo.
|
| and the fact that maven is ready for business doesnt mean taht you can
| use anything however you want, you should enforce policies on what
| plugin versions you want, what third party libraries,... because we
| may take decisions here that will affect the decisions at some
| companies, while not at others. Many times there's not black or white
You are right. But again I just want to say be as sensible about changes as
possible. Therefore my oppinion is: yes add these poms but without dependencies.
If dependencies should be added, new versions have to be created.

Take care
~  Jörg
|
|
| On Jan 25, 2008 4:16 PM, Joerg Hohwiller <jo...@j-hohwiller.de> wrote:
| Hi there,
|
| I am sometimes late on threads but anyways...
|
| | i don't agree, the point of not having a pom there is to be able to
| | add one later with the right info. If you work against something
| | without pom, hey, it's your decision, but you are aware that it's a
| | problem, as all the warnings tell you
| I do NOT agree. Adding a jar and later some pom with dependencies is
| odd. You should enforce that no artifacts can go to central repro
| if they do not come with a proper pom.
| To fix the actual problem default poms should be added to
| the repository. Further versions of these artifacts can add the
| correct dependencies.
| Please consider that maven is not just used by open-source users for fun but
| also by brute business. If some company is running a deployment
| that comes to a wrong result because of dependencies in a
| pom that was just added to the repository (e.g. because then a different version
| than before was chosen for a dependent artifact), they will flame maven.
| Don't we say that maven is also ready for business?
| Do you have an idea how much harm the maven community has done to enterprise
| (and other) users by releasing buggy plugins?
| I do not want to blame anybody! Giving your spare time for open-source is
| worth some honor and humans make mistakes. But we should be aware of the
| sensibility of our decisions.
|
| Best regards
| ~  Jörg
|
| |
| | On 10/15/07, William Ferguson <Wi...@yarris.com> wrote:
| |> Isn't the goal here to stop incessant warnings during a build about
| |> trying to downalod a missing POM?
| |>
| |> The way to do that is to that is to upload a POM for that artifact to
| |> the repository.
| |>
| |> But Nico is right is that the uploaded POM should not break existing
| |> builds. Which means that the POM just needs to be bare bones and list no
| |> dependencies as the missing POM introduces no deps.
| |>
| |> So Nico, I'd suggest you create a simple POM with just groupId,
| |> artifactId and version and get it uploaded to the repository.
| |>
| |> Can I also suggest that it is a worthy task to auto generate and upload
| |> such POMs for all artifacts in central with a missing POM.
| |>
| |> William
| |>
| |>
| |> -----Original Message-----
| |> From: carlossg@gmail.com [mailto:carlossg@gmail.com] On Behalf Of Carlos
| |> Sanchez
| |> Sent: Tuesday, 16 October 2007 2:01 AM
| |> To: Maven Developers List
| |> Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has
| |> different SMTP TO: and MIME TO: fields in the email addresses
| |>
| |> sorry, but that's not the case currently. If it has no metadata it can
| |> be added, that's why you get warnings when the metadata is missing.
| |>
| |> On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
| |>> I fully agree about collaborating and submitting more artifacts to the
| |>> repo with good meta-datas. The only issue I can see is about
| |>> reproductible builds if those meta-datas change.
| |>>
| |>> The established rule NOT to change meta-datas after publication
| |>> applies IMHO also to artifacts without meta-datas. Anyone providing
| |>> metadatas for an artifact that is allready in repo, so that can be
| |>> used by many people, will potentialy break there builds, with no way
| |>> in maven2 to quickly fix this issue by stopping the transitive
| |> dependencies.
| |>> Nico.
| |>>
| |>> 2007/10/15, Carlos Sanchez <ca...@apache.org>:
| |>>> On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
| |>>>> I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm
| |>>>> also
| |>>> not
| |>>>> the guy who used it in the project. I came later and have to
| |>>>> maintain
| |>>> the
| |>>>> project now.
| |>>> that's collaboration ;) if you want to use something that uses
| |>>> castor and want to do it the right way, yes you should contribute a
| |>>> pom
| |>>>
| |>>>> Do you think I should contribute an empty POM just to ensure
| |>>>> no-one can latter contribute one with some (maybe) unexpected
| |> dependencies ?
| |>>> not an empty pom, but it shouldn't take more than 10 min to figure
| |>>> out what the dependencies are
| |>>>
| |>>>> A better solution IMHO should be to have an option for a
| |>>>> dependency in
| |>>> my
| |>>>> POM to excludes all transitive dependencies. The current
| |>>>> <exclusion> elements require to list dependencies. With such a
| |>>>> feature, a project
| |>>> that
| |>>>> has legacy reference on a dependency with no POM can simply set
| |>>>> no-transitivity to be reproductible in any case.
| |>>> that's already filled in jira
| |>>>
| |>>>> Many artifacts in the repo don't have POMs (from m1 -> m2
| |>>>> migration ?)
| |>>> not lately but old ones, yes
| |>>>
| |>>>> Nico.
| |>>>>
| |>>>> 2007/10/15, Carlos Sanchez <ca...@apache.org>:
| |>>>>> On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
| |>>>>>> Warning : This could break existing projects !
| |>>>>>>
| |>>>>>> My project has a dependency on castor-1.0. This one has no
| |> POM.
| |>>>>>> If you povide one, rebuilding my app will introduce new
| |>>>>>> transitive dependencies that were not expected, and my build
| |>>>>>> will become non-reproductible.
| |>>>>>>
| |>>>>>> Only new release of an artifact can come with a POM.
| |>>>>>
| |>>>>> mmm, that's not the case, you shouldn't made releases of things
| |>>>>> without poms, you should have contributed one already
| |>>>>>
| |>>>>>
| |>>>>>> Nico.
| |>>>>>>
| |>>>>>> 2007/10/11, Jochen Wiedmann <jo...@gmail.com>:
| |>>>>>>> On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:
| |>>>>>>>
| |>>>>>>>> http://maven.apache.org/guides/mini/guide-maven-evangelism
| |>>>>>>>> .html
| |>>>>>>> Quoting from that text:
| |>>>>>>>
| |>>>>>>> ... unless you provide a pom for it ...
| |>>>>>>>
| |>>>>>>> I am ready to do that, at least in the cases that harm me.
| |>>>>>>> But
| |>>> how?
| |>>>>>>> Through the standard upload procedure?
| |>>>>>
| |>>>>> <quote>open an issue at JIRA MEV  with the relevant information
| |>>> </quote>
| |> ---------------------------------------------------------------------
| |> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
| |> For additional commands, e-mail: dev-help@maven.apache.org
| |>
| |>
| |
| |
|
|>
|>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
|>
|>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHm4H3mPuec2Dcv/8RAtVpAJ0TczFEr9ftJZIxHRDGI4xj8NcDpwCgl5yg
7VpisbFydet+TGOKP05P+uA=
=Mh64
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Inconsistent pom for jaxws-api 2.1

Posted by Marat Radchenko <sl...@gmail.com>.

It is a known bug. Use
http://repo1.maven.org/maven2/javax/xml/ws/jaxws-api/2.1-1/ instead.

2008/1/26, Raymond Feng <en...@gmail.com>:
> Hi,
>
> Our build has a dependency on javax.xml.ws:jaxws-api:2.1. And we have the
> java.net configured as a maven repo in our pom.xml. The build fails randomly
> because the same artifact is available at [2] but it has a different pom as
> [1]. A bunch of transitive dependencies are missing in [2], such as jsr-181.
> If it happens that [2] is downloaded by mvn, then our build will fail.
>
> [1] http://download.java.net/maven/1/javax.xml.ws/poms/jaxws-api-2.1.pom
> [2]
> http://repo1.maven.org/maven2/javax/xml/ws/jaxws-api/2.1/jaxws-api-2.1.pom
>
> Is this a bug in [2]?
>
> Is there a way that we can define the ordering of the maven repo so that we
> can consistenly get [1]?
>
> Thanks,
> Raymond
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Inconsistent pom for jaxws-api 2.1

Posted by Raymond Feng <en...@gmail.com>.

Hi,

Our build has a dependency on javax.xml.ws:jaxws-api:2.1. And we have the 
java.net configured as a maven repo in our pom.xml. The build fails randomly 
because the same artifact is available at [2] but it has a different pom as 
[1]. A bunch of transitive dependencies are missing in [2], such as jsr-181. 
If it happens that [2] is downloaded by mvn, then our build will fail.

[1] http://download.java.net/maven/1/javax.xml.ws/poms/jaxws-api-2.1.pom
[2] 
http://repo1.maven.org/maven2/javax/xml/ws/jaxws-api/2.1/jaxws-api-2.1.pom

Is this a bug in [2]?

Is there a way that we can define the ordering of the maven repo so that we 
can consistenly get [1]?

Thanks,
Raymond 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Inconsistent pom for jaxws-api 2.1

Posted by Raymond Feng <en...@gmail.com>.

Hi,

Our build has a dependency on javax.xml.ws:jaxws-api:2.1. And we have the 
java.net configured as a maven repo in our pom.xml. The build fails randomly 
because the same artifact is available at [2] but it has a different pom as 
[1]. A bunch of transitive dependencies are missing in [2], such as jsr-181. 
If it happens that [2] is downloaded by mvn, then our build will fail.

[1] http://download.java.net/maven/1/javax.xml.ws/poms/jaxws-api-2.1.pom
[2] 
http://repo1.maven.org/maven2/javax/xml/ws/jaxws-api/2.1/jaxws-api-2.1.pom

Is this a bug in [2]?

Is there a way that we can define the ordering of the maven repo so that we 
can consistenly get [1]?

Thanks,
Raymond 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

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?

there's still people saying that poms should be modifiable!

and the fact that maven is ready for business doesnt mean taht you can
use anything however you want, you should enforce policies on what
plugin versions you want, what third party libraries,... because we
may take decisions here that will affect the decisions at some
companies, while not at others. Many times there's not black or white


On Jan 25, 2008 4:16 PM, Joerg Hohwiller <jo...@j-hohwiller.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi there,
>
> I am sometimes late on threads but anyways...
>
> | i don't agree, the point of not having a pom there is to be able to
> | add one later with the right info. If you work against something
> | without pom, hey, it's your decision, but you are aware that it's a
> | problem, as all the warnings tell you
> I do NOT agree. Adding a jar and later some pom with dependencies is
> odd. You should enforce that no artifacts can go to central repro
> if they do not come with a proper pom.
> To fix the actual problem default poms should be added to
> the repository. Further versions of these artifacts can add the
> correct dependencies.
> Please consider that maven is not just used by open-source users for fun but
> also by brute business. If some company is running a deployment
> that comes to a wrong result because of dependencies in a
> pom that was just added to the repository (e.g. because then a different version
> than before was chosen for a dependent artifact), they will flame maven.
> Don't we say that maven is also ready for business?
> Do you have an idea how much harm the maven community has done to enterprise
> (and other) users by releasing buggy plugins?
> I do not want to blame anybody! Giving your spare time for open-source is
> worth some honor and humans make mistakes. But we should be aware of the
> sensibility of our decisions.
>
> Best regards
> ~  Jörg
>
> |
> | On 10/15/07, William Ferguson <Wi...@yarris.com> wrote:
> |> Isn't the goal here to stop incessant warnings during a build about
> |> trying to downalod a missing POM?
> |>
> |> The way to do that is to that is to upload a POM for that artifact to
> |> the repository.
> |>
> |> But Nico is right is that the uploaded POM should not break existing
> |> builds. Which means that the POM just needs to be bare bones and list no
> |> dependencies as the missing POM introduces no deps.
> |>
> |> So Nico, I'd suggest you create a simple POM with just groupId,
> |> artifactId and version and get it uploaded to the repository.
> |>
> |> Can I also suggest that it is a worthy task to auto generate and upload
> |> such POMs for all artifacts in central with a missing POM.
> |>
> |> William
> |>
> |>
> |> -----Original Message-----
> |> From: carlossg@gmail.com [mailto:carlossg@gmail.com] On Behalf Of Carlos
> |> Sanchez
> |> Sent: Tuesday, 16 October 2007 2:01 AM
> |> To: Maven Developers List
> |> Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has
> |> different SMTP TO: and MIME TO: fields in the email addresses
> |>
> |> sorry, but that's not the case currently. If it has no metadata it can
> |> be added, that's why you get warnings when the metadata is missing.
> |>
> |> On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
> |>> I fully agree about collaborating and submitting more artifacts to the
> |>> repo with good meta-datas. The only issue I can see is about
> |>> reproductible builds if those meta-datas change.
> |>>
> |>> The established rule NOT to change meta-datas after publication
> |>> applies IMHO also to artifacts without meta-datas. Anyone providing
> |>> metadatas for an artifact that is allready in repo, so that can be
> |>> used by many people, will potentialy break there builds, with no way
> |>> in maven2 to quickly fix this issue by stopping the transitive
> |> dependencies.
> |>> Nico.
> |>>
> |>> 2007/10/15, Carlos Sanchez <ca...@apache.org>:
> |>>> On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
> |>>>> I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm
> |>>>> also
> |>>> not
> |>>>> the guy who used it in the project. I came later and have to
> |>>>> maintain
> |>>> the
> |>>>> project now.
> |>>> that's collaboration ;) if you want to use something that uses
> |>>> castor and want to do it the right way, yes you should contribute a
> |>>> pom
> |>>>
> |>>>> Do you think I should contribute an empty POM just to ensure
> |>>>> no-one can latter contribute one with some (maybe) unexpected
> |> dependencies ?
> |>>> not an empty pom, but it shouldn't take more than 10 min to figure
> |>>> out what the dependencies are
> |>>>
> |>>>> A better solution IMHO should be to have an option for a
> |>>>> dependency in
> |>>> my
> |>>>> POM to excludes all transitive dependencies. The current
> |>>>> <exclusion> elements require to list dependencies. With such a
> |>>>> feature, a project
> |>>> that
> |>>>> has legacy reference on a dependency with no POM can simply set
> |>>>> no-transitivity to be reproductible in any case.
> |>>> that's already filled in jira
> |>>>
> |>>>> Many artifacts in the repo don't have POMs (from m1 -> m2
> |>>>> migration ?)
> |>>> not lately but old ones, yes
> |>>>
> |>>>> Nico.
> |>>>>
> |>>>> 2007/10/15, Carlos Sanchez <ca...@apache.org>:
> |>>>>> On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
> |>>>>>> Warning : This could break existing projects !
> |>>>>>>
> |>>>>>> My project has a dependency on castor-1.0. This one has no
> |> POM.
> |>>>>>> If you povide one, rebuilding my app will introduce new
> |>>>>>> transitive dependencies that were not expected, and my build
> |>>>>>> will become non-reproductible.
> |>>>>>>
> |>>>>>> Only new release of an artifact can come with a POM.
> |>>>>>
> |>>>>> mmm, that's not the case, you shouldn't made releases of things
> |>>>>> without poms, you should have contributed one already
> |>>>>>
> |>>>>>
> |>>>>>> Nico.
> |>>>>>>
> |>>>>>> 2007/10/11, Jochen Wiedmann <jo...@gmail.com>:
> |>>>>>>> On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:
> |>>>>>>>
> |>>>>>>>> http://maven.apache.org/guides/mini/guide-maven-evangelism
> |>>>>>>>> .html
> |>>>>>>> Quoting from that text:
> |>>>>>>>
> |>>>>>>> ... unless you provide a pom for it ...
> |>>>>>>>
> |>>>>>>> I am ready to do that, at least in the cases that harm me.
> |>>>>>>> But
> |>>> how?
> |>>>>>>> Through the standard upload procedure?
> |>>>>>
> |>>>>> <quote>open an issue at JIRA MEV  with the relevant information
> |>>> </quote>
> |> ---------------------------------------------------------------------
> |> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> |> For additional commands, e-mail: dev-help@maven.apache.org
> |>
> |>
> |
> |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHmnvimPuec2Dcv/8RAm1MAJ0enhk25RE+HnobPXMl9Ap7U922KQCfX/tu
> S0jzEznAiXh9hBK1V3qK6+Q=
> =g77f
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there,

I am sometimes late on threads but anyways...

| i don't agree, the point of not having a pom there is to be able to
| add one later with the right info. If you work against something
| without pom, hey, it's your decision, but you are aware that it's a
| problem, as all the warnings tell you
I do NOT agree. Adding a jar and later some pom with dependencies is
odd. You should enforce that no artifacts can go to central repro
if they do not come with a proper pom.
To fix the actual problem default poms should be added to
the repository. Further versions of these artifacts can add the
correct dependencies.
Please consider that maven is not just used by open-source users for fun but
also by brute business. If some company is running a deployment
that comes to a wrong result because of dependencies in a
pom that was just added to the repository (e.g. because then a different version
than before was chosen for a dependent artifact), they will flame maven.
Don't we say that maven is also ready for business?
Do you have an idea how much harm the maven community has done to enterprise
(and other) users by releasing buggy plugins?
I do not want to blame anybody! Giving your spare time for open-source is
worth some honor and humans make mistakes. But we should be aware of the
sensibility of our decisions.

Best regards
~  Jörg
|
| On 10/15/07, William Ferguson <Wi...@yarris.com> wrote:
|> Isn't the goal here to stop incessant warnings during a build about
|> trying to downalod a missing POM?
|>
|> The way to do that is to that is to upload a POM for that artifact to
|> the repository.
|>
|> But Nico is right is that the uploaded POM should not break existing
|> builds. Which means that the POM just needs to be bare bones and list no
|> dependencies as the missing POM introduces no deps.
|>
|> So Nico, I'd suggest you create a simple POM with just groupId,
|> artifactId and version and get it uploaded to the repository.
|>
|> Can I also suggest that it is a worthy task to auto generate and upload
|> such POMs for all artifacts in central with a missing POM.
|>
|> William
|>
|>
|> -----Original Message-----
|> From: carlossg@gmail.com [mailto:carlossg@gmail.com] On Behalf Of Carlos
|> Sanchez
|> Sent: Tuesday, 16 October 2007 2:01 AM
|> To: Maven Developers List
|> Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has
|> different SMTP TO: and MIME TO: fields in the email addresses
|>
|> sorry, but that's not the case currently. If it has no metadata it can
|> be added, that's why you get warnings when the metadata is missing.
|>
|> On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
|>> I fully agree about collaborating and submitting more artifacts to the
|>> repo with good meta-datas. The only issue I can see is about
|>> reproductible builds if those meta-datas change.
|>>
|>> The established rule NOT to change meta-datas after publication
|>> applies IMHO also to artifacts without meta-datas. Anyone providing
|>> metadatas for an artifact that is allready in repo, so that can be
|>> used by many people, will potentialy break there builds, with no way
|>> in maven2 to quickly fix this issue by stopping the transitive
|> dependencies.
|>> Nico.
|>>
|>> 2007/10/15, Carlos Sanchez <ca...@apache.org>:
|>>> On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
|>>>> I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm
|>>>> also
|>>> not
|>>>> the guy who used it in the project. I came later and have to
|>>>> maintain
|>>> the
|>>>> project now.
|>>> that's collaboration ;) if you want to use something that uses
|>>> castor and want to do it the right way, yes you should contribute a
|>>> pom
|>>>
|>>>> Do you think I should contribute an empty POM just to ensure
|>>>> no-one can latter contribute one with some (maybe) unexpected
|> dependencies ?
|>>> not an empty pom, but it shouldn't take more than 10 min to figure
|>>> out what the dependencies are
|>>>
|>>>> A better solution IMHO should be to have an option for a
|>>>> dependency in
|>>> my
|>>>> POM to excludes all transitive dependencies. The current
|>>>> <exclusion> elements require to list dependencies. With such a
|>>>> feature, a project
|>>> that
|>>>> has legacy reference on a dependency with no POM can simply set
|>>>> no-transitivity to be reproductible in any case.
|>>> that's already filled in jira
|>>>
|>>>> Many artifacts in the repo don't have POMs (from m1 -> m2
|>>>> migration ?)
|>>> not lately but old ones, yes
|>>>
|>>>> Nico.
|>>>>
|>>>> 2007/10/15, Carlos Sanchez <ca...@apache.org>:
|>>>>> On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
|>>>>>> Warning : This could break existing projects !
|>>>>>>
|>>>>>> My project has a dependency on castor-1.0. This one has no
|> POM.
|>>>>>> If you povide one, rebuilding my app will introduce new
|>>>>>> transitive dependencies that were not expected, and my build
|>>>>>> will become non-reproductible.
|>>>>>>
|>>>>>> Only new release of an artifact can come with a POM.
|>>>>>
|>>>>> mmm, that's not the case, you shouldn't made releases of things
|>>>>> without poms, you should have contributed one already
|>>>>>
|>>>>>
|>>>>>> Nico.
|>>>>>>
|>>>>>> 2007/10/11, Jochen Wiedmann <jo...@gmail.com>:
|>>>>>>> On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:
|>>>>>>>
|>>>>>>>> http://maven.apache.org/guides/mini/guide-maven-evangelism
|>>>>>>>> .html
|>>>>>>> Quoting from that text:
|>>>>>>>
|>>>>>>> ... unless you provide a pom for it ...
|>>>>>>>
|>>>>>>> I am ready to do that, at least in the cases that harm me.
|>>>>>>> But
|>>> how?
|>>>>>>> Through the standard upload procedure?
|>>>>>
|>>>>> <quote>open an issue at JIRA MEV  with the relevant information
|>>> </quote>
|> ---------------------------------------------------------------------
|> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
|> For additional commands, e-mail: dev-help@maven.apache.org
|>
|>
|
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmnvimPuec2Dcv/8RAm1MAJ0enhk25RE+HnobPXMl9Ap7U922KQCfX/tu
S0jzEznAiXh9hBK1V3qK6+Q=
=g77f
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by William Ferguson <Wi...@yarris.com>.

In that case I think the warning about a missing POM needs to be
stronger and make people aware of the implications of someone suddenly
uploading one.


-----Original Message-----
From: carlossg@gmail.com [mailto:carlossg@gmail.com] On Behalf Of Carlos
Sanchez
Sent: Tuesday, 16 October 2007 8:22 AM
To: Maven Developers List
Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has
different SMTP TO: and MIME TO: fields in the email addresses

i don't agree, the point of not having a pom there is to be able to add
one later with the right info. If you work against something without
pom, hey, it's your decision, but you are aware that it's a problem, as
all the warnings tell you

On 10/15/07, William Ferguson <Wi...@yarris.com> wrote:
> Isn't the goal here to stop incessant warnings during a build about 
> trying to downalod a missing POM?
>
> The way to do that is to that is to upload a POM for that artifact to 
> the repository.
>
> But Nico is right is that the uploaded POM should not break existing 
> builds. Which means that the POM just needs to be bare bones and list 
> no dependencies as the missing POM introduces no deps.
>
> So Nico, I'd suggest you create a simple POM with just groupId, 
> artifactId and version and get it uploaded to the repository.
>
> Can I also suggest that it is a worthy task to auto generate and 
> upload such POMs for all artifacts in central with a missing POM.
>
> William

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

i don't agree, the point of not having a pom there is to be able to
add one later with the right info. If you work against something
without pom, hey, it's your decision, but you are aware that it's a
problem, as all the warnings tell you

On 10/15/07, William Ferguson <Wi...@yarris.com> wrote:
> Isn't the goal here to stop incessant warnings during a build about
> trying to downalod a missing POM?
>
> The way to do that is to that is to upload a POM for that artifact to
> the repository.
>
> But Nico is right is that the uploaded POM should not break existing
> builds. Which means that the POM just needs to be bare bones and list no
> dependencies as the missing POM introduces no deps.
>
> So Nico, I'd suggest you create a simple POM with just groupId,
> artifactId and version and get it uploaded to the repository.
>
> Can I also suggest that it is a worthy task to auto generate and upload
> such POMs for all artifacts in central with a missing POM.
>
> William
>
>
> -----Original Message-----
> From: carlossg@gmail.com [mailto:carlossg@gmail.com] On Behalf Of Carlos
> Sanchez
> Sent: Tuesday, 16 October 2007 2:01 AM
> To: Maven Developers List
> Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has
> different SMTP TO: and MIME TO: fields in the email addresses
>
> sorry, but that's not the case currently. If it has no metadata it can
> be added, that's why you get warnings when the metadata is missing.
>
> On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
> > I fully agree about collaborating and submitting more artifacts to the
>
> > repo with good meta-datas. The only issue I can see is about
> > reproductible builds if those meta-datas change.
> >
> > The established rule NOT to change meta-datas after publication
> > applies IMHO also to artifacts without meta-datas. Anyone providing
> > metadatas for an artifact that is allready in repo, so that can be
> > used by many people, will potentialy break there builds, with no way
> > in maven2 to quickly fix this issue by stopping the transitive
> dependencies.
> >
> > Nico.
> >
> > 2007/10/15, Carlos Sanchez <ca...@apache.org>:
> > >
> > > On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
> > > > I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm
>
> > > > also
> > > not
> > > > the guy who used it in the project. I came later and have to
> > > > maintain
> > > the
> > > > project now.
> > >
> > > that's collaboration ;) if you want to use something that uses
> > > castor and want to do it the right way, yes you should contribute a
> > > pom
> > >
> > > >
> > > > Do you think I should contribute an empty POM just to ensure
> > > > no-one can latter contribute one with some (maybe) unexpected
> dependencies ?
> > >
> > > not an empty pom, but it shouldn't take more than 10 min to figure
> > > out what the dependencies are
> > >
> > > >
> > > > A better solution IMHO should be to have an option for a
> > > > dependency in
> > > my
> > > > POM to excludes all transitive dependencies. The current
> > > > <exclusion> elements require to list dependencies. With such a
> > > > feature, a project
> > > that
> > > > has legacy reference on a dependency with no POM can simply set
> > > > no-transitivity to be reproductible in any case.
> > >
> > > that's already filled in jira
> > >
> > > >
> > > > Many artifacts in the repo don't have POMs (from m1 -> m2
> > > > migration ?)
> > >
> > > not lately but old ones, yes
> > >
> > > >
> > > > Nico.
> > > >
> > > > 2007/10/15, Carlos Sanchez <ca...@apache.org>:
> > > > >
> > > > > On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
> > > > > > Warning : This could break existing projects !
> > > > > >
> > > > > > My project has a dependency on castor-1.0. This one has no
> POM.
> > > > > > If you povide one, rebuilding my app will introduce new
> > > > > > transitive dependencies that were not expected, and my build
> > > > > > will become non-reproductible.
> > > > > >
> > > > > > Only new release of an artifact can come with a POM.
> > > > >
> > > > >
> > > > > mmm, that's not the case, you shouldn't made releases of things
> > > > > without poms, you should have contributed one already
> > > > >
> > > > >
> > > > > >
> > > > > > Nico.
> > > > > >
> > > > > > 2007/10/11, Jochen Wiedmann <jo...@gmail.com>:
> > > > > > >
> > > > > > > On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:
> > > > > > >
> > > > > > > > http://maven.apache.org/guides/mini/guide-maven-evangelism
> > > > > > > > .html
> > > > > > >
> > > > > > > Quoting from that text:
> > > > > > >
> > > > > > > ... unless you provide a pom for it ...
> > > > > > >
> > > > > > > I am ready to do that, at least in the cases that harm me.
> > > > > > > But
> > > how?
> > > > > > > Through the standard upload procedure?
> > > > >
> > > > >
> > > > > <quote>open an issue at JIRA MEV  with the relevant information
> > > </quote>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by William Ferguson <Wi...@yarris.com>.

Isn't the goal here to stop incessant warnings during a build about
trying to downalod a missing POM?

The way to do that is to that is to upload a POM for that artifact to
the repository.

But Nico is right is that the uploaded POM should not break existing
builds. Which means that the POM just needs to be bare bones and list no
dependencies as the missing POM introduces no deps.

So Nico, I'd suggest you create a simple POM with just groupId,
artifactId and version and get it uploaded to the repository.

Can I also suggest that it is a worthy task to auto generate and upload
such POMs for all artifacts in central with a missing POM.

William


-----Original Message-----
From: carlossg@gmail.com [mailto:carlossg@gmail.com] On Behalf Of Carlos
Sanchez
Sent: Tuesday, 16 October 2007 2:01 AM
To: Maven Developers List
Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has
different SMTP TO: and MIME TO: fields in the email addresses

sorry, but that's not the case currently. If it has no metadata it can
be added, that's why you get warnings when the metadata is missing.

On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
> I fully agree about collaborating and submitting more artifacts to the

> repo with good meta-datas. The only issue I can see is about 
> reproductible builds if those meta-datas change.
>
> The established rule NOT to change meta-datas after publication 
> applies IMHO also to artifacts without meta-datas. Anyone providing 
> metadatas for an artifact that is allready in repo, so that can be 
> used by many people, will potentialy break there builds, with no way 
> in maven2 to quickly fix this issue by stopping the transitive
dependencies.
>
> Nico.
>
> 2007/10/15, Carlos Sanchez <ca...@apache.org>:
> >
> > On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
> > > I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm

> > > also
> > not
> > > the guy who used it in the project. I came later and have to 
> > > maintain
> > the
> > > project now.
> >
> > that's collaboration ;) if you want to use something that uses 
> > castor and want to do it the right way, yes you should contribute a 
> > pom
> >
> > >
> > > Do you think I should contribute an empty POM just to ensure 
> > > no-one can latter contribute one with some (maybe) unexpected
dependencies ?
> >
> > not an empty pom, but it shouldn't take more than 10 min to figure 
> > out what the dependencies are
> >
> > >
> > > A better solution IMHO should be to have an option for a 
> > > dependency in
> > my
> > > POM to excludes all transitive dependencies. The current 
> > > <exclusion> elements require to list dependencies. With such a 
> > > feature, a project
> > that
> > > has legacy reference on a dependency with no POM can simply set 
> > > no-transitivity to be reproductible in any case.
> >
> > that's already filled in jira
> >
> > >
> > > Many artifacts in the repo don't have POMs (from m1 -> m2 
> > > migration ?)
> >
> > not lately but old ones, yes
> >
> > >
> > > Nico.
> > >
> > > 2007/10/15, Carlos Sanchez <ca...@apache.org>:
> > > >
> > > > On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
> > > > > Warning : This could break existing projects !
> > > > >
> > > > > My project has a dependency on castor-1.0. This one has no
POM.
> > > > > If you povide one, rebuilding my app will introduce new 
> > > > > transitive dependencies that were not expected, and my build 
> > > > > will become non-reproductible.
> > > > >
> > > > > Only new release of an artifact can come with a POM.
> > > >
> > > >
> > > > mmm, that's not the case, you shouldn't made releases of things 
> > > > without poms, you should have contributed one already
> > > >
> > > >
> > > > >
> > > > > Nico.
> > > > >
> > > > > 2007/10/11, Jochen Wiedmann <jo...@gmail.com>:
> > > > > >
> > > > > > On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:
> > > > > >
> > > > > > > http://maven.apache.org/guides/mini/guide-maven-evangelism
> > > > > > > .html
> > > > > >
> > > > > > Quoting from that text:
> > > > > >
> > > > > > ... unless you provide a pom for it ...
> > > > > >
> > > > > > I am ready to do that, at least in the cases that harm me. 
> > > > > > But
> > how?
> > > > > > Through the standard upload procedure?
> > > >
> > > >
> > > > <quote>open an issue at JIRA MEV  with the relevant information
> > </quote>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

sorry, but that's not the case currently. If it has no metadata it can
be added, that's why you get warnings when the metadata is missing.

On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
> I fully agree about collaborating and submitting more artifacts to the repo
> with good meta-datas. The only issue I can see is about reproductible builds
> if those meta-datas change.
>
> The established rule NOT to change meta-datas after publication applies IMHO
> also to artifacts without meta-datas. Anyone providing metadatas for an
> artifact that is allready in repo, so that can be used by many people, will
> potentialy break there builds, with no way in maven2 to quickly fix this
> issue by stopping the transitive dependencies.
>
> Nico.
>
> 2007/10/15, Carlos Sanchez <ca...@apache.org>:
> >
> > On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
> > > I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm also
> > not
> > > the guy who used it in the project. I came later and have to maintain
> > the
> > > project now.
> >
> > that's collaboration ;) if you want to use something that uses castor
> > and want to do it the right way, yes you should contribute a pom
> >
> > >
> > > Do you think I should contribute an empty POM just to ensure no-one can
> > > latter contribute one with some (maybe) unexpected dependencies ?
> >
> > not an empty pom, but it shouldn't take more than 10 min to figure out
> > what the dependencies are
> >
> > >
> > > A better solution IMHO should be to have an option for a dependency in
> > my
> > > POM to excludes all transitive dependencies. The current <exclusion>
> > > elements require to list dependencies. With such a feature, a project
> > that
> > > has legacy reference on a dependency with no POM can simply set
> > > no-transitivity to be reproductible in any case.
> >
> > that's already filled in jira
> >
> > >
> > > Many artifacts in the repo don't have POMs (from m1 -> m2 migration ?)
> >
> > not lately but old ones, yes
> >
> > >
> > > Nico.
> > >
> > > 2007/10/15, Carlos Sanchez <ca...@apache.org>:
> > > >
> > > > On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
> > > > > Warning : This could break existing projects !
> > > > >
> > > > > My project has a dependency on castor-1.0. This one has no POM.
> > > > > If you povide one, rebuilding my app will introduce new transitive
> > > > > dependencies that were not expected, and my build will become
> > > > > non-reproductible.
> > > > >
> > > > > Only new release of an artifact can come with a POM.
> > > >
> > > >
> > > > mmm, that's not the case, you shouldn't made releases of things
> > > > without poms, you should have contributed one already
> > > >
> > > >
> > > > >
> > > > > Nico.
> > > > >
> > > > > 2007/10/11, Jochen Wiedmann <jo...@gmail.com>:
> > > > > >
> > > > > > On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:
> > > > > >
> > > > > > > http://maven.apache.org/guides/mini/guide-maven-evangelism.html
> > > > > >
> > > > > > Quoting from that text:
> > > > > >
> > > > > > ... unless you provide a pom for it ...
> > > > > >
> > > > > > I am ready to do that, at least in the cases that harm me. But
> > how?
> > > > > > Through the standard upload procedure?
> > > >
> > > >
> > > > <quote>open an issue at JIRA MEV  with the relevant information
> > </quote>
> > > >
> > > >
> > > >
> > > > > >
> > > > > > Jochen
> > > > > >
> > > > > > --
> > > > > > Look, that's why there's rules, understand? So that you think
> > before
> > > > > > you break 'em.
> > > > > >
> > > > > >     -- (Terry Pratchett, Thief of Time)
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > I could give you my word as a Spaniard.
> > > > No good. I've known too many Spaniards.
> > > >                              -- The Princess Bride
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                              -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by nicolas de loof <ni...@gmail.com>.

I fully agree about collaborating and submitting more artifacts to the repo
with good meta-datas. The only issue I can see is about reproductible builds
if those meta-datas change.

The established rule NOT to change meta-datas after publication applies IMHO
also to artifacts without meta-datas. Anyone providing metadatas for an
artifact that is allready in repo, so that can be used by many people, will
potentialy break there builds, with no way in maven2 to quickly fix this
issue by stopping the transitive dependencies.

Nico.

2007/10/15, Carlos Sanchez <ca...@apache.org>:
>
> On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
> > I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm also
> not
> > the guy who used it in the project. I came later and have to maintain
> the
> > project now.
>
> that's collaboration ;) if you want to use something that uses castor
> and want to do it the right way, yes you should contribute a pom
>
> >
> > Do you think I should contribute an empty POM just to ensure no-one can
> > latter contribute one with some (maybe) unexpected dependencies ?
>
> not an empty pom, but it shouldn't take more than 10 min to figure out
> what the dependencies are
>
> >
> > A better solution IMHO should be to have an option for a dependency in
> my
> > POM to excludes all transitive dependencies. The current <exclusion>
> > elements require to list dependencies. With such a feature, a project
> that
> > has legacy reference on a dependency with no POM can simply set
> > no-transitivity to be reproductible in any case.
>
> that's already filled in jira
>
> >
> > Many artifacts in the repo don't have POMs (from m1 -> m2 migration ?)
>
> not lately but old ones, yes
>
> >
> > Nico.
> >
> > 2007/10/15, Carlos Sanchez <ca...@apache.org>:
> > >
> > > On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
> > > > Warning : This could break existing projects !
> > > >
> > > > My project has a dependency on castor-1.0. This one has no POM.
> > > > If you povide one, rebuilding my app will introduce new transitive
> > > > dependencies that were not expected, and my build will become
> > > > non-reproductible.
> > > >
> > > > Only new release of an artifact can come with a POM.
> > >
> > >
> > > mmm, that's not the case, you shouldn't made releases of things
> > > without poms, you should have contributed one already
> > >
> > >
> > > >
> > > > Nico.
> > > >
> > > > 2007/10/11, Jochen Wiedmann <jo...@gmail.com>:
> > > > >
> > > > > On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:
> > > > >
> > > > > > http://maven.apache.org/guides/mini/guide-maven-evangelism.html
> > > > >
> > > > > Quoting from that text:
> > > > >
> > > > > ... unless you provide a pom for it ...
> > > > >
> > > > > I am ready to do that, at least in the cases that harm me. But
> how?
> > > > > Through the standard upload procedure?
> > >
> > >
> > > <quote>open an issue at JIRA MEV  with the relevant information
> </quote>
> > >
> > >
> > >
> > > > >
> > > > > Jochen
> > > > >
> > > > > --
> > > > > Look, that's why there's rules, understand? So that you think
> before
> > > > > you break 'em.
> > > > >
> > > > >     -- (Terry Pratchett, Thief of Time)
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > I could give you my word as a Spaniard.
> > > No good. I've known too many Spaniards.
> > >                              -- The Princess Bride
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                              -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

On 10/15/07, nicolas de loof <ni...@gmail.com> wrote:
> I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm also not
> the guy who used it in the project. I came later and have to maintain the
> project now.

that's collaboration ;) if you want to use something that uses castor
and want to do it the right way, yes you should contribute a pom

>
> Do you think I should contribute an empty POM just to ensure no-one can
> latter contribute one with some (maybe) unexpected dependencies ?

not an empty pom, but it shouldn't take more than 10 min to figure out
what the dependencies are

>
> A better solution IMHO should be to have an option for a dependency in my
> POM to excludes all transitive dependencies. The current <exclusion>
> elements require to list dependencies. With such a feature, a project that
> has legacy reference on a dependency with no POM can simply set
> no-transitivity to be reproductible in any case.

that's already filled in jira

>
> Many artifacts in the repo don't have POMs (from m1 -> m2 migration ?)

not lately but old ones, yes

>
> Nico.
>
> 2007/10/15, Carlos Sanchez <ca...@apache.org>:
> >
> > On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
> > > Warning : This could break existing projects !
> > >
> > > My project has a dependency on castor-1.0. This one has no POM.
> > > If you povide one, rebuilding my app will introduce new transitive
> > > dependencies that were not expected, and my build will become
> > > non-reproductible.
> > >
> > > Only new release of an artifact can come with a POM.
> >
> >
> > mmm, that's not the case, you shouldn't made releases of things
> > without poms, you should have contributed one already
> >
> >
> > >
> > > Nico.
> > >
> > > 2007/10/11, Jochen Wiedmann <jo...@gmail.com>:
> > > >
> > > > On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:
> > > >
> > > > > http://maven.apache.org/guides/mini/guide-maven-evangelism.html
> > > >
> > > > Quoting from that text:
> > > >
> > > > ... unless you provide a pom for it ...
> > > >
> > > > I am ready to do that, at least in the cases that harm me. But how?
> > > > Through the standard upload procedure?
> >
> >
> > <quote>open an issue at JIRA MEV  with the relevant information </quote>
> >
> >
> >
> > > >
> > > > Jochen
> > > >
> > > > --
> > > > Look, that's why there's rules, understand? So that you think before
> > > > you break 'em.
> > > >
> > > >     -- (Terry Pratchett, Thief of Time)
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                              -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by nicolas de loof <ni...@gmail.com>.

I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm also not
the guy who used it in the project. I came later and have to maintain the
project now.

Do you think I should contribute an empty POM just to ensure no-one can
latter contribute one with some (maybe) unexpected dependencies ?

A better solution IMHO should be to have an option for a dependency in my
POM to excludes all transitive dependencies. The current <exclusion>
elements require to list dependencies. With such a feature, a project that
has legacy reference on a dependency with no POM can simply set
no-transitivity to be reproductible in any case.

Many artifacts in the repo don't have POMs (from m1 -> m2 migration ?)

Nico.

2007/10/15, Carlos Sanchez <ca...@apache.org>:
>
> On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
> > Warning : This could break existing projects !
> >
> > My project has a dependency on castor-1.0. This one has no POM.
> > If you povide one, rebuilding my app will introduce new transitive
> > dependencies that were not expected, and my build will become
> > non-reproductible.
> >
> > Only new release of an artifact can come with a POM.
>
>
> mmm, that's not the case, you shouldn't made releases of things
> without poms, you should have contributed one already
>
>
> >
> > Nico.
> >
> > 2007/10/11, Jochen Wiedmann <jo...@gmail.com>:
> > >
> > > On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:
> > >
> > > > http://maven.apache.org/guides/mini/guide-maven-evangelism.html
> > >
> > > Quoting from that text:
> > >
> > > ... unless you provide a pom for it ...
> > >
> > > I am ready to do that, at least in the cases that harm me. But how?
> > > Through the standard upload procedure?
>
>
> <quote>open an issue at JIRA MEV  with the relevant information </quote>
>
>
>
> > >
> > > Jochen
> > >
> > > --
> > > Look, that's why there's rules, understand? So that you think before
> > > you break 'em.
> > >
> > >     -- (Terry Pratchett, Thief of Time)
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                              -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
> Warning : This could break existing projects !
>
> My project has a dependency on castor-1.0. This one has no POM.
> If you povide one, rebuilding my app will introduce new transitive
> dependencies that were not expected, and my build will become
> non-reproductible.
>
> Only new release of an artifact can come with a POM.


mmm, that's not the case, you shouldn't made releases of things
without poms, you should have contributed one already


>
> Nico.
>
> 2007/10/11, Jochen Wiedmann <jo...@gmail.com>:
> >
> > On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:
> >
> > > http://maven.apache.org/guides/mini/guide-maven-evangelism.html
> >
> > Quoting from that text:
> >
> > ... unless you provide a pom for it ...
> >
> > I am ready to do that, at least in the cases that harm me. But how?
> > Through the standard upload procedure?


<quote>open an issue at JIRA MEV  with the relevant information </quote>



> >
> > Jochen
> >
> > --
> > Look, that's why there's rules, understand? So that you think before
> > you break 'em.
> >
> >     -- (Terry Pratchett, Thief of Time)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Jochen Wiedmann <jo...@gmail.com>.

On 10/11/07, Jochen Wiedmann <jo...@gmail.com> wrote:
> On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
> > Warning : This could break existing projects !
> >
> > My project has a dependency on castor-1.0. This one has no POM.
> > If you povide one, rebuilding my app will introduce new transitive
> > dependencies that were not expected, and my build will become
> > non-reproductible.
> >
> > Only new release of an artifact can come with a POM.
>
> There is no reason to omit dependencies in these cases, for the sake
> of compatibility.

Sorry for my bad english. What I meant to say: There is no reason
*not* to omit dependencies. The intention is not to fix the lack of
transitive dependencies but to avoid unnecessary slow down of the
build scripts.

-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Jochen Wiedmann <jo...@gmail.com>.

On 10/11/07, nicolas de loof <ni...@gmail.com> wrote:
> Warning : This could break existing projects !
>
> My project has a dependency on castor-1.0. This one has no POM.
> If you povide one, rebuilding my app will introduce new transitive
> dependencies that were not expected, and my build will become
> non-reproductible.
>
> Only new release of an artifact can come with a POM.

There is no reason to omit dependencies in these cases, for the sake
of compatibility.

-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by nicolas de loof <ni...@gmail.com>.

Warning : This could break existing projects !

My project has a dependency on castor-1.0. This one has no POM.
If you povide one, rebuilding my app will introduce new transitive
dependencies that were not expected, and my build will become
non-reproductible.

Only new release of an artifact can come with a POM.

Nico.

2007/10/11, Jochen Wiedmann <jo...@gmail.com>:
>
> On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:
>
> > http://maven.apache.org/guides/mini/guide-maven-evangelism.html
>
> Quoting from that text:
>
> ... unless you provide a pom for it ...
>
> I am ready to do that, at least in the cases that harm me. But how?
> Through the standard upload procedure?
>
> Jochen
>
> --
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
>
>     -- (Terry Pratchett, Thief of Time)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Fix missing POM files

Posted by Jochen Wiedmann <jo...@gmail.com>.

On 10/11/07, Carlos Sanchez <ca...@apache.org> wrote:

> http://maven.apache.org/guides/mini/guide-maven-evangelism.html

Quoting from that text:

... unless you provide a pom for it ...

I am ready to do that, at least in the cases that harm me. But how?
Through the standard upload procedure?

Jochen

-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

http://maven.apache.org/guides/mini/guide-maven-evangelism.html

On 10/4/07, Jochen Wiedmann <jo...@gmail.com> wrote:
> Hi,
>
> repo1.maven.org contains a number of jar files without POM. Examples
> include woodstox/wstx-asl/3.0.2/, or castor/castor/1.0/. As these are
> quite a pain in the development by causing unnecessary and failed
> download requests every time, I'd like to fix this, at least for those
> where I note it.
>
> Question is how. Suggestion: Create new upload bundles under com.ctc
> (woodstox), or org.exolab (Castor)? Other ideas?
>
> Thanks,
>
> Jochen
>
> --
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
>
>     -- (Terry Pratchett, Thief of Time)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Fix missing POM files

Posted by Carlos Sanchez <ca...@apache.org>.

http://maven.apache.org/guides/mini/guide-maven-evangelism.html

On 10/10/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
> This is probably a repository question...
>
> -----Original Message-----
> From: Jochen Wiedmann [mailto:jochen.wiedmann@gmail.com]
> Sent: Wednesday, October 10, 2007 4:12 PM
> To: dev@maven.apache.org
> Subject: Nag: Fix missing POM files
>
>
>
> Ping!
>
>
> Jochen Wiedmann wrote:
> >
> > Hi,
> >
> > repo1.maven.org contains a number of jar files without POM. Examples
> > include woodstox/wstx-asl/3.0.2/, or castor/castor/1.0/. As these are
> > quite a pain in the development by causing unnecessary and failed
> > download requests every time, I'd like to fix this, at least for those
> > where I note it.
> >
> > Question is how. Suggestion: Create new upload bundles under com.ctc
> > (woodstox), or org.exolab (Castor)? Other ideas?
> >
> > Thanks,
> >
> > Jochen
> >
> > --
> > Look, that's why there's rules, understand? So that you think before
> > you break 'em.
> >
> >     -- (Terry Pratchett, Thief of Time)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Fix-missing-POM-files-tf4569446s177.html#a13143712
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

RE: Fix missing POM files

Posted by "Brian E. Fox" <br...@reply.infinity.nu>.

This is probably a repository question...

-----Original Message-----
From: Jochen Wiedmann [mailto:jochen.wiedmann@gmail.com] 
Sent: Wednesday, October 10, 2007 4:12 PM
To: dev@maven.apache.org
Subject: Nag: Fix missing POM files



Ping!


Jochen Wiedmann wrote:
> 
> Hi,
> 
> repo1.maven.org contains a number of jar files without POM. Examples
> include woodstox/wstx-asl/3.0.2/, or castor/castor/1.0/. As these are
> quite a pain in the development by causing unnecessary and failed
> download requests every time, I'd like to fix this, at least for those
> where I note it.
> 
> Question is how. Suggestion: Create new upload bundles under com.ctc
> (woodstox), or org.exolab (Castor)? Other ideas?
> 
> Thanks,
> 
> Jochen
> 
> -- 
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
> 
>     -- (Terry Pratchett, Thief of Time)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> 

-- 
View this message in context:
http://www.nabble.com/Fix-missing-POM-files-tf4569446s177.html#a13143712
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Nag: Fix missing POM files

Posted by Jochen Wiedmann <jo...@gmail.com>.


Ping!


Jochen Wiedmann wrote:
> 
> Hi,
> 
> repo1.maven.org contains a number of jar files without POM. Examples
> include woodstox/wstx-asl/3.0.2/, or castor/castor/1.0/. As these are
> quite a pain in the development by causing unnecessary and failed
> download requests every time, I'd like to fix this, at least for those
> where I note it.
> 
> Question is how. Suggestion: Create new upload bundles under com.ctc
> (woodstox), or org.exolab (Castor)? Other ideas?
> 
> Thanks,
> 
> Jochen
> 
> -- 
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
> 
>     -- (Terry Pratchett, Thief of Time)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Fix-missing-POM-files-tf4569446s177.html#a13143712
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org