Ah, I think the tone of my email was incorrect. "What's the problem with the stuff in the repo?", was meant to be rhetorical.
I should have said, "My problem with using the public repo is that certain pom's are incorrect such as: " But, I do agree with everything you said. Ruel Loehr JBoss QA -----Original Message----- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Thursday, March 16, 2006 10:15 AM To: Maven Users List Subject: Re: updating of dependency pom's "What's wrong" with items in the public repo is it was decided at some point a little while ago by the Maven dev team that getting various artifacts (like xercesImpl) into the Maven2 repo was a high importance item, and so a little program was written to generate essentially "empty" poms for these items, just to facilitate the rapid construction of the M2 repo. This practice has been abandoned and so any new projects etc going into the repo will have proper poms. So now there are a bunch of older poms in the M2 repo that are not in the best of shape. You can help identify and fix these poms by posting bugs in the Jira MEV project. I'm sure the Maven dev group would be very appreciative of your assistance in fixing up some of these "empty" poms. Wayne On 3/16/06, Ruel Loehr <[EMAIL PROTECTED]> wrote: > Unfortunately, yes, it is a common occurance. Here is why: > > For every thirdparty used in my project I require the pom to have: > > 1) a description > 2) a project url > 3) a license description > 4) a url to the license > > I then wrote a plugin which validates this information and also retrieves the license for each dependency. > > Getting this information for thirdparty items is very important to us, the strong dependnecy support is one of our main reasons for a maven migration. > > What is the problem with items in the public repo? > > http://www.ibiblio.org/maven2/xerces/xercesImpl/2.7.1/xercesImpl-2.7.1.p om > http://www.ibiblio.org/maven2/wutka/dtdparser/1.21/dtdparser-1.21.pom > > I guess the fix is as you suggest, to make sure each dependency in my internal repo is a unique groupID/artifactId pairing. > > > > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Wed 3/15/2006 8:26 PM > To: Maven Users List > Subject: Re: updating of dependency pom's > > As you've pointed out, updating POMs is a bad idea for > reproducibility. We'd like to make it possible to track the revisions > in a pom to allow "fixing them" while retaining compatibility, but at > this point it is assumed that they don't change once deployed. > > My suggestion, if you need to customise something, is to deploy the > POM and the original or modified artifact under your own group ID in > the repository. So maybe something like: > > org.jboss.ports.commons-foo : commons-foo : 1.0 > > This would be much clearer and more reliable, I believe. Is this > something that is a common occurrence? > > - Brett > > On 3/16/06, Ruel Loehr <[EMAIL PROTECTED]> wrote: > > Once a pom for a dependency has been copied to the local repo, it is > > never updated. > > > > For those of you who maintain a company internal repo, do you ever have > > the situation where a dependency pom in your internal repo differs from > > the corresponding pom in the public repo? (e.g. you want to record > > additional info such as license information, or the public pom is not > > correctly defined). > > > > The problem I see is that it is difficult to ensure that a user is using > > the correct pom. > > > > For example, if a user downloads maven, builds something with it, his > > local repo gets populated. > > > > Then, if the user tries to build my app, and I have defined a thirdparty > > pom in my own internal repo that differs from the public one, the > > original public version will be used (even if my app includes a maven > > distro and a settings.xml specifying my own repo). > > > > Any ideas on how to work around this? I feel like I need control over > > the repo, but cannot ensure that the user hits my repo first. > > > > Appropriate jira issue is here: > > http://jira.codehaus.org/browse/MNG-1954 > > > > Ruel Loehr > > JBoss QA > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
