2009/10/28 Brett Porter <br...@apache.org>

>
> On 29/10/2009, at 2:08 AM, Daniel Kulp wrote:
>
>  On Wed October 28 2009 10:53:10 am John Casey wrote:
>>
>>> I tend to agree, they should not really be used. It seems like these
>>> third-party repositories have a strong potential for causing network
>>> errors (in cases where the repo is down or on a private network), and
>>> they definitely push the user in the direction of trusting anything that
>>> comes from anywhere on the internet without thinking twice...not a great
>>> idea, and an understandably unpopular one with companies.
>>>
>>> I think the role of the <repository> declaration in the POM should be
>>> shifted in Maven 3. I think this along the same lines that Brett was
>>> talking, but I'd really like to see them take on an advisory role rather
>>> than actively participate in resolution. In other words, if an artifact
>>> cannot be found, then display the list of third-party repositories which
>>> MIGHT contain the artifact, along with the POM that lists that
>>> repository.
>>>
>>
>> I'm OK with that EXCEPT for repositories defined in the current
>> pom+parents.
>> For transitive dependencies, yes, but not for building the current
>> project.
>>
>>
> +1
>
> This avoids fudging with settings.xml, which has other problems that others
> have mentioned, and also because you start building a long list of
> repositories then used on *every* project (unless Maven adds some other gid
> restriction on repositories).


+1... though this has the side-effect that if you checkout a project who's
parent is only in a repository specified in the parent... well hey, it's not
our fault! ;-)


>
>
> On 29/10/2009, at 4:22 AM, Dan Rollo wrote:
>
>  To advocate the other side: I like the ability to define repositories in
>> the pom.xml because team members (oss or corporate) can simply "get latest"
>> from the source bank and things work OOTB.
>>
>> I don't like the idea that the only way for things to work OOTB is if all
>> artifacts MUST come from 'central'. There are other open source repo's in
>> wide use. Same with private/corporate repos.
>>
>> Forcing an edit to settings.xml (usually located in the user home dir) is
>> also a maintenance issue for automated builds.
>>
>
> Agreed - I think the proposal above gives a balance between the two
> concerns.
>
> - Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Reply via email to