[DISCUSS] Handling of repositories in POMs of dependencies

[Benjamin Bentmann]

Hi,

following a comment by Wendy on JIRA, I wanted to re-check what our
plans are for repositories in dependency POMs. In more detail, how is
dependency resolution in Maven 3.x expected to work here:

    project ---depends-on---> A ---depends-on---> B

where the POM of A declares the repository R hosting B.

Now, when it comes to resolve B's POM/JAR (and its transitive
dependencies) in the context of building the project, should Maven 3
also consider R (like currently done in Maven 2) or only those
repositories that are available for the root of the dependency graph,
i.e. the repositories declared in the POM of the project and the settings?

Besides the question of the degree of backward-compat we want to keep,
the issue with ignoring the repositories declared in dependency POMs I
see is the effect on open source projects and their consumers. If one
project consumes the artifacts of another, do we want the first project
to redeclare all repositories required to resolve the transitive
dependencies of the second project? Some arguments for the other side
can be found in [1].

So, where do we want to go with this?


Benjamin


[0]
http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
[1] http://jira.codehaus.org/browse/MNG-3056

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

[brettporter]

I would advocate not allowing them, but using them to provide useful  
information in the case of a resolution exception that can easily  
guide the user on what to do.

If folks strongly want to continue to allow it, I would go with a  
prominent warning (which is the case for several other things now).

As to what the user is guided to do - I assume that is to declare them  
as repositories in the current project, or to refer to their  
repository manager's documentation to add it there (with this being  
recommended). In the long run I'd hope Maven can better handle  
multiple repositories OOTB (in a way that still complements the use of  
a repository manager) - actually I remember briefly talking to Brian  
about that at last year's ApacheCon Maven BOF :) Time flies...

- Brett

On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:

> Hi,
>
> following a comment by Wendy on JIRA, I wanted to re-check what our  
> plans are for repositories in dependency POMs. In more detail, how  
> is dependency resolution in Maven 3.x expected to work here:
>
>   project ---depends-on---> A ---depends-on---> B
>
> where the POM of A declares the repository R hosting B.
>
> Now, when it comes to resolve B's POM/JAR (and its transitive  
> dependencies) in the context of building the project, should Maven 3  
> also consider R (like currently done in Maven 2) or only those  
> repositories that are available for the root of the dependency  
> graph, i.e. the repositories declared in the POM of the project and  
> the settings?
>
> Besides the question of the degree of backward-compat we want to  
> keep, the issue with ignoring the repositories declared in  
> dependency POMs I see is the effect on open source projects and  
> their consumers. If one project consumes the artifacts of another,  
> do we want the first project to redeclare all repositories required  
> to resolve the transitive dependencies of the second project? Some  
> arguments for the other side can be found in [1].
>
> So, where do we want to go with this?
>
>
> Benjamin
>
>
> [0] http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
> [1] http://jira.codehaus.org/browse/MNG-3056
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

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

[jmcconnell]

judging from the response I have gotten from people both wanting and
not wanting repositories declared for various integrations with jetty,
the problem folks seem to be ones where their corporate policy dictate
they can not use any repo other then central but they do not have a
repo manager setup.

since we can't rightly force people to install and maintain repository
managers, at first blush I would probably error on the side of a
option in the settings.xml a la offline

<transitiveRepositories>true/false</transtiveRepositories>

jesse

--
jesse mcconnell
jesse.mcconnell@...



On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@...> wrote:

> I would advocate not allowing them, but using them to provide useful
> information in the case of a resolution exception that can easily guide the
> user on what to do.
>
> If folks strongly want to continue to allow it, I would go with a prominent
> warning (which is the case for several other things now).
>
> As to what the user is guided to do - I assume that is to declare them as
> repositories in the current project, or to refer to their repository
> manager's documentation to add it there (with this being recommended). In
> the long run I'd hope Maven can better handle multiple repositories OOTB (in
> a way that still complements the use of a repository manager) - actually I
> remember briefly talking to Brian about that at last year's ApacheCon Maven
> BOF :) Time flies...
>
> - Brett
>
> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
>
>> Hi,
>>
>> following a comment by Wendy on JIRA, I wanted to re-check what our plans
>> are for repositories in dependency POMs. In more detail, how is dependency
>> resolution in Maven 3.x expected to work here:
>>
>>  project ---depends-on---> A ---depends-on---> B
>>
>> where the POM of A declares the repository R hosting B.
>>
>> Now, when it comes to resolve B's POM/JAR (and its transitive
>> dependencies) in the context of building the project, should Maven 3 also
>> consider R (like currently done in Maven 2) or only those repositories that
>> are available for the root of the dependency graph, i.e. the repositories
>> declared in the POM of the project and the settings?
>>
>> Besides the question of the degree of backward-compat we want to keep, the
>> issue with ignoring the repositories declared in dependency POMs I see is
>> the effect on open source projects and their consumers. If one project
>> consumes the artifacts of another, do we want the first project to redeclare
>> all repositories required to resolve the transitive dependencies of the
>> second project? Some arguments for the other side can be found in [1].
>>
>> So, where do we want to go with this?
>>
>>
>> Benjamin
>>
>>
>> [0]
>> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
>> [1] http://jira.codehaus.org/browse/MNG-3056
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

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

[Paul Gier]

I really think it should not be allowed, since it makes the builds less
predictable/reproduceable/secure.  Most people I've talked to think it's a bug
when they first see it happening because they are trying to figure out why Maven
is downloading files from a random location on the Internet.

The people who have a corporate policy to only download from central are already
breaking their policy whether they list the alternate repo in settings.xml or it
is added from a dependency.

With that said, I'm ok with having it configurable as Jesse suggests as long as
the default behaviour is to not add the repositories to the build.

Jesse McConnell wrote:

> judging from the response I have gotten from people both wanting and
> not wanting repositories declared for various integrations with jetty,
> the problem folks seem to be ones where their corporate policy dictate
> they can not use any repo other then central but they do not have a
> repo manager setup.
>
> since we can't rightly force people to install and maintain repository
> managers, at first blush I would probably error on the side of a
> option in the settings.xml a la offline
>
> <transitiveRepositories>true/false</transtiveRepositories>
>
> jesse
>
> --
> jesse mcconnell
> jesse.mcconnell@...
>
>
>
> On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@...> wrote:
>> I would advocate not allowing them, but using them to provide useful
>> information in the case of a resolution exception that can easily guide the
>> user on what to do.
>>
>> If folks strongly want to continue to allow it, I would go with a prominent
>> warning (which is the case for several other things now).
>>
>> As to what the user is guided to do - I assume that is to declare them as
>> repositories in the current project, or to refer to their repository
>> manager's documentation to add it there (with this being recommended). In
>> the long run I'd hope Maven can better handle multiple repositories OOTB (in
>> a way that still complements the use of a repository manager) - actually I
>> remember briefly talking to Brian about that at last year's ApacheCon Maven
>> BOF :) Time flies...
>>
>> - Brett
>>
>> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
>>
>>> Hi,
>>>
>>> following a comment by Wendy on JIRA, I wanted to re-check what our plans
>>> are for repositories in dependency POMs. In more detail, how is dependency
>>> resolution in Maven 3.x expected to work here:
>>>
>>>  project ---depends-on---> A ---depends-on---> B
>>>
>>> where the POM of A declares the repository R hosting B.
>>>
>>> Now, when it comes to resolve B's POM/JAR (and its transitive
>>> dependencies) in the context of building the project, should Maven 3 also
>>> consider R (like currently done in Maven 2) or only those repositories that
>>> are available for the root of the dependency graph, i.e. the repositories
>>> declared in the POM of the project and the settings?
>>>
>>> Besides the question of the degree of backward-compat we want to keep, the
>>> issue with ignoring the repositories declared in dependency POMs I see is
>>> the effect on open source projects and their consumers. If one project
>>> consumes the artifacts of another, do we want the first project to redeclare
>>> all repositories required to resolve the transitive dependencies of the
>>> second project? Some arguments for the other side can be found in [1].
>>>
>>> So, where do we want to go with this?
>>>
>>>
>>> Benjamin
>>>
>>>
>>> [0]
>>> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
>>> [1] http://jira.codehaus.org/browse/MNG-3056
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

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

[John Casey-5]

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.

This would help users request new repositories be added to the repo
manager in cases where there is one, and otherwise get permission to add
the repo to their settings.xml. In short, Maven would tell the user the
most likely reason the build cannot proceed, but not assume it's okey to
pursue the artifact to the ends of the earth.

-john

Paul Gier wrote:

> I really think it should not be allowed, since it makes the builds less
> predictable/reproduceable/secure.  Most people I've talked to think it's
> a bug when they first see it happening because they are trying to figure
> out why Maven is downloading files from a random location on the Internet.
>
> The people who have a corporate policy to only download from central are
> already breaking their policy whether they list the alternate repo in
> settings.xml or it is added from a dependency.
>
> With that said, I'm ok with having it configurable as Jesse suggests as
> long as the default behaviour is to not add the repositories to the build.
>
> Jesse McConnell wrote:
>> judging from the response I have gotten from people both wanting and
>> not wanting repositories declared for various integrations with jetty,
>> the problem folks seem to be ones where their corporate policy dictate
>> they can not use any repo other then central but they do not have a
>> repo manager setup.
>>
>> since we can't rightly force people to install and maintain repository
>> managers, at first blush I would probably error on the side of a
>> option in the settings.xml a la offline
>>
>> <transitiveRepositories>true/false</transtiveRepositories>
>>
>> jesse
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@...
>>
>>
>>
>> On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@...> wrote:
>>> I would advocate not allowing them, but using them to provide useful
>>> information in the case of a resolution exception that can easily
>>> guide the
>>> user on what to do.
>>>
>>> If folks strongly want to continue to allow it, I would go with a
>>> prominent
>>> warning (which is the case for several other things now).
>>>
>>> As to what the user is guided to do - I assume that is to declare
>>> them as
>>> repositories in the current project, or to refer to their repository
>>> manager's documentation to add it there (with this being
>>> recommended). In
>>> the long run I'd hope Maven can better handle multiple repositories
>>> OOTB (in
>>> a way that still complements the use of a repository manager) -
>>> actually I
>>> remember briefly talking to Brian about that at last year's ApacheCon
>>> Maven
>>> BOF :) Time flies...
>>>
>>> - Brett
>>>
>>> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
>>>
>>>> Hi,
>>>>
>>>> following a comment by Wendy on JIRA, I wanted to re-check what our
>>>> plans
>>>> are for repositories in dependency POMs. In more detail, how is
>>>> dependency
>>>> resolution in Maven 3.x expected to work here:
>>>>
>>>>  project ---depends-on---> A ---depends-on---> B
>>>>
>>>> where the POM of A declares the repository R hosting B.
>>>>
>>>> Now, when it comes to resolve B's POM/JAR (and its transitive
>>>> dependencies) in the context of building the project, should Maven 3
>>>> also
>>>> consider R (like currently done in Maven 2) or only those
>>>> repositories that
>>>> are available for the root of the dependency graph, i.e. the
>>>> repositories
>>>> declared in the POM of the project and the settings?
>>>>
>>>> Besides the question of the degree of backward-compat we want to
>>>> keep, the
>>>> issue with ignoring the repositories declared in dependency POMs I
>>>> see is
>>>> the effect on open source projects and their consumers. If one project
>>>> consumes the artifacts of another, do we want the first project to
>>>> redeclare
>>>> all repositories required to resolve the transitive dependencies of the
>>>> second project? Some arguments for the other side can be found in [1].
>>>>
>>>> So, where do we want to go with this?
>>>>
>>>>
>>>> Benjamin
>>>>
>>>>
>>>> [0]
>>>> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344 
>>>>
>>>> [1] http://jira.codehaus.org/browse/MNG-3056
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

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

[jmcconnell]

The problem I see is that without being able to push up repositories
with third party artifacts that are not in central yet you still
depend on for integrations or things like that...you are out of luck
and need some mechanism of pushing that knowledge/information to the
user of the artifact...and a wiki page or a webpage detailing that is
not acceptable imo as it makes it difficult for the user as they need
to _find_ that page.

Now I would be pro notification as well, along the lines that brett
was mentioning I think

I can declare a repo in a third party integration, perhaps against a
corporate repo that has some open source component they are not
syncing to central....and that is _ignored_ in the build, ie never
consulted, but when that is detected and if the build is not able to
complete it should pump out that information to the user declaring
that other repositories have been detected and that perhaps missing
dependencies are located in there...

jesse

--
jesse mcconnell
jesse.mcconnell@...



On Wed, Oct 28, 2009 at 09:17, Paul Gier <pgier@...> wrote:

> I really think it should not be allowed, since it makes the builds less
> predictable/reproduceable/secure.  Most people I've talked to think it's a
> bug when they first see it happening because they are trying to figure out
> why Maven is downloading files from a random location on the Internet.
>
> The people who have a corporate policy to only download from central are
> already breaking their policy whether they list the alternate repo in
> settings.xml or it is added from a dependency.
>
> With that said, I'm ok with having it configurable as Jesse suggests as long
> as the default behaviour is to not add the repositories to the build.
>
> Jesse McConnell wrote:
>>
>> judging from the response I have gotten from people both wanting and
>> not wanting repositories declared for various integrations with jetty,
>> the problem folks seem to be ones where their corporate policy dictate
>> they can not use any repo other then central but they do not have a
>> repo manager setup.
>>
>> since we can't rightly force people to install and maintain repository
>> managers, at first blush I would probably error on the side of a
>> option in the settings.xml a la offline
>>
>> <transitiveRepositories>true/false</transtiveRepositories>
>>
>> jesse
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@...
>>
>>
>>
>> On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@...> wrote:
>>>
>>> I would advocate not allowing them, but using them to provide useful
>>> information in the case of a resolution exception that can easily guide
>>> the
>>> user on what to do.
>>>
>>> If folks strongly want to continue to allow it, I would go with a
>>> prominent
>>> warning (which is the case for several other things now).
>>>
>>> As to what the user is guided to do - I assume that is to declare them as
>>> repositories in the current project, or to refer to their repository
>>> manager's documentation to add it there (with this being recommended). In
>>> the long run I'd hope Maven can better handle multiple repositories OOTB
>>> (in
>>> a way that still complements the use of a repository manager) - actually
>>> I
>>> remember briefly talking to Brian about that at last year's ApacheCon
>>> Maven
>>> BOF :) Time flies...
>>>
>>> - Brett
>>>
>>> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
>>>
>>>> Hi,
>>>>
>>>> following a comment by Wendy on JIRA, I wanted to re-check what our
>>>> plans
>>>> are for repositories in dependency POMs. In more detail, how is
>>>> dependency
>>>> resolution in Maven 3.x expected to work here:
>>>>
>>>>  project ---depends-on---> A ---depends-on---> B
>>>>
>>>> where the POM of A declares the repository R hosting B.
>>>>
>>>> Now, when it comes to resolve B's POM/JAR (and its transitive
>>>> dependencies) in the context of building the project, should Maven 3
>>>> also
>>>> consider R (like currently done in Maven 2) or only those repositories
>>>> that
>>>> are available for the root of the dependency graph, i.e. the
>>>> repositories
>>>> declared in the POM of the project and the settings?
>>>>
>>>> Besides the question of the degree of backward-compat we want to keep,
>>>> the
>>>> issue with ignoring the repositories declared in dependency POMs I see
>>>> is
>>>> the effect on open source projects and their consumers. If one project
>>>> consumes the artifacts of another, do we want the first project to
>>>> redeclare
>>>> all repositories required to resolve the transitive dependencies of the
>>>> second project? Some arguments for the other side can be found in [1].
>>>>
>>>> So, where do we want to go with this?
>>>>
>>>>
>>>> Benjamin
>>>>
>>>>
>>>> [0]
>>>>
>>>> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
>>>> [1] http://jira.codehaus.org/browse/MNG-3056
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

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

[Stephen Connolly-2]

2009/10/28 John Casey <jdcasey@...>

> 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.
>
> This would help users request new repositories be added to the repo manager
> in cases where there is one, and otherwise get permission to add the repo to
> their settings.xml. In short, Maven would tell the user the most likely
> reason the build cannot proceed, but not assume it's okey to pursue the
> artifact to the ends of the earth.
>
>

+1

> -john
>
>
> Paul Gier wrote:
>
>> I really think it should not be allowed, since it makes the builds less
>> predictable/reproduceable/secure.  Most people I've talked to think it's a
>> bug when they first see it happening because they are trying to figure out
>> why Maven is downloading files from a random location on the Internet.
>>
>> The people who have a corporate policy to only download from central are
>> already breaking their policy whether they list the alternate repo in
>> settings.xml or it is added from a dependency.
>>
>> With that said, I'm ok with having it configurable as Jesse suggests as
>> long as the default behaviour is to not add the repositories to the build.
>>
>> Jesse McConnell wrote:
>>
>>> judging from the response I have gotten from people both wanting and
>>> not wanting repositories declared for various integrations with jetty,
>>> the problem folks seem to be ones where their corporate policy dictate
>>> they can not use any repo other then central but they do not have a
>>> repo manager setup.
>>>
>>> since we can't rightly force people to install and maintain repository
>>> managers, at first blush I would probably error on the side of a
>>> option in the settings.xml a la offline
>>>
>>> <transitiveRepositories>true/false</transtiveRepositories>
>>>
>>> jesse
>>>
>>> --
>>> jesse mcconnell
>>> jesse.mcconnell@...
>>>
>>>
>>>
>>> On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@...> wrote:
>>>
>>>> I would advocate not allowing them, but using them to provide useful
>>>> information in the case of a resolution exception that can easily guide
>>>> the
>>>> user on what to do.
>>>>
>>>> If folks strongly want to continue to allow it, I would go with a
>>>> prominent
>>>> warning (which is the case for several other things now).
>>>>
>>>> As to what the user is guided to do - I assume that is to declare them
>>>> as
>>>> repositories in the current project, or to refer to their repository
>>>> manager's documentation to add it there (with this being recommended).
>>>> In
>>>> the long run I'd hope Maven can better handle multiple repositories OOTB
>>>> (in
>>>> a way that still complements the use of a repository manager) - actually
>>>> I
>>>> remember briefly talking to Brian about that at last year's ApacheCon
>>>> Maven
>>>> BOF :) Time flies...
>>>>
>>>> - Brett
>>>>
>>>> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
>>>>
>>>>  Hi,
>>>>>
>>>>> following a comment by Wendy on JIRA, I wanted to re-check what our
>>>>> plans
>>>>> are for repositories in dependency POMs. In more detail, how is
>>>>> dependency
>>>>> resolution in Maven 3.x expected to work here:
>>>>>
>>>>>  project ---depends-on---> A ---depends-on---> B
>>>>>
>>>>> where the POM of A declares the repository R hosting B.
>>>>>
>>>>> Now, when it comes to resolve B's POM/JAR (and its transitive
>>>>> dependencies) in the context of building the project, should Maven 3
>>>>> also
>>>>> consider R (like currently done in Maven 2) or only those repositories
>>>>> that
>>>>> are available for the root of the dependency graph, i.e. the
>>>>> repositories
>>>>> declared in the POM of the project and the settings?
>>>>>
>>>>> Besides the question of the degree of backward-compat we want to keep,
>>>>> the
>>>>> issue with ignoring the repositories declared in dependency POMs I see
>>>>> is
>>>>> the effect on open source projects and their consumers. If one project
>>>>> consumes the artifacts of another, do we want the first project to
>>>>> redeclare
>>>>> all repositories required to resolve the transitive dependencies of the
>>>>> second project? Some arguments for the other side can be found in [1].
>>>>>
>>>>> So, where do we want to go with this?
>>>>>
>>>>>
>>>>> Benjamin
>>>>>
>>>>>
>>>>> [0]
>>>>>
>>>>> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
>>>>> [1] http://jira.codehaus.org/browse/MNG-3056
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>> For additional commands, e-mail: dev-help@...
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[dkulp]

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.

Dan

>
> This would help users request new repositories be added to the repo
> manager in cases where there is one, and otherwise get permission to add
> the repo to their settings.xml. In short, Maven would tell the user the
> most likely reason the build cannot proceed, but not assume it's okey to
> pursue the artifact to the ends of the earth.
>
> -john
>
> Paul Gier wrote:
> > I really think it should not be allowed, since it makes the builds less
> > predictable/reproduceable/secure.  Most people I've talked to think it's
> > a bug when they first see it happening because they are trying to figure
> > out why Maven is downloading files from a random location on the
> > Internet.
> >
> > The people who have a corporate policy to only download from central are
> > already breaking their policy whether they list the alternate repo in
> > settings.xml or it is added from a dependency.
> >
> > With that said, I'm ok with having it configurable as Jesse suggests as
> > long as the default behaviour is to not add the repositories to the
> > build.
> >
> > Jesse McConnell wrote:
> >> judging from the response I have gotten from people both wanting and
> >> not wanting repositories declared for various integrations with jetty,
> >> the problem folks seem to be ones where their corporate policy dictate
> >> they can not use any repo other then central but they do not have a
> >> repo manager setup.
> >>
> >> since we can't rightly force people to install and maintain repository
> >> managers, at first blush I would probably error on the side of a
> >> option in the settings.xml a la offline
> >>
> >> <transitiveRepositories>true/false</transtiveRepositories>
> >>
> >> jesse
> >>
> >> On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@...> wrote:
> >>> I would advocate not allowing them, but using them to provide useful
> >>> information in the case of a resolution exception that can easily
> >>> guide the
> >>> user on what to do.
> >>>
> >>> If folks strongly want to continue to allow it, I would go with a
> >>> prominent
> >>> warning (which is the case for several other things now).
> >>>
> >>> As to what the user is guided to do - I assume that is to declare
> >>> them as
> >>> repositories in the current project, or to refer to their repository
> >>> manager's documentation to add it there (with this being
> >>> recommended). In
> >>> the long run I'd hope Maven can better handle multiple repositories
> >>> OOTB (in
> >>> a way that still complements the use of a repository manager) -
> >>> actually I
> >>> remember briefly talking to Brian about that at last year's ApacheCon
> >>> Maven
> >>> BOF :) Time flies...
> >>>
> >>> - Brett
> >>>
> >>> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
> >>>> Hi,
> >>>>
> >>>> following a comment by Wendy on JIRA, I wanted to re-check what our
> >>>> plans
> >>>> are for repositories in dependency POMs. In more detail, how is
> >>>> dependency
> >>>> resolution in Maven 3.x expected to work here:
> >>>>
> >>>>  project ---depends-on---> A ---depends-on---> B
> >>>>
> >>>> where the POM of A declares the repository R hosting B.
> >>>>
> >>>> Now, when it comes to resolve B's POM/JAR (and its transitive
> >>>> dependencies) in the context of building the project, should Maven 3
> >>>> also
> >>>> consider R (like currently done in Maven 2) or only those
> >>>> repositories that
> >>>> are available for the root of the dependency graph, i.e. the
> >>>> repositories
> >>>> declared in the POM of the project and the settings?
> >>>>
> >>>> Besides the question of the degree of backward-compat we want to
> >>>> keep, the
> >>>> issue with ignoring the repositories declared in dependency POMs I
> >>>> see is
> >>>> the effect on open source projects and their consumers. If one project
> >>>> consumes the artifacts of another, do we want the first project to
> >>>> redeclare
> >>>> all repositories required to resolve the transitive dependencies of
> >>>> the second project? Some arguments for the other side can be found in
> >>>> [1].
> >>>>
> >>>> So, where do we want to go with this?
> >>>>
> >>>>
> >>>> Benjamin
> >>>>
> >>>>
> >>>> [0]
> >>>> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=
> >>>>com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#acti
> >>>>on_196344
> >>>>
> >>>> [1] http://jira.codehaus.org/browse/MNG-3056
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@...
> >>>> For additional commands, e-mail: dev-help@...
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@...
> >>> For additional commands, e-mail: dev-help@...
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

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

[John Casey-5]

Most debian packagers that don't have their apps in the default APT
sources provide a standard page somewhere on their website for adding a
new source. This would be pretty easy for third-party repository
providers to do, and would have the added benefit of making them really
think about it and support that repository as public
infrastructure...along with providing ticket/bug tracking for that
repository's reachability along with the build files or the source code
for the app itself.

Of course, there's not much reason I can think of that an OSS project
wouldn't just configure synchronization with central if they're going to
go to all this trouble...but for non-OSS I can see them using the above.
In that case, there's a chance they would want to authenticate/control
access to that repository anyway, in which case the user would need to
modify his settings.xml anyway...

-john

Jesse McConnell wrote:

> The problem I see is that without being able to push up repositories
> with third party artifacts that are not in central yet you still
> depend on for integrations or things like that...you are out of luck
> and need some mechanism of pushing that knowledge/information to the
> user of the artifact...and a wiki page or a webpage detailing that is
> not acceptable imo as it makes it difficult for the user as they need
> to _find_ that page.
>
> Now I would be pro notification as well, along the lines that brett
> was mentioning I think
>
> I can declare a repo in a third party integration, perhaps against a
> corporate repo that has some open source component they are not
> syncing to central....and that is _ignored_ in the build, ie never
> consulted, but when that is detected and if the build is not able to
> complete it should pump out that information to the user declaring
> that other repositories have been detected and that perhaps missing
> dependencies are located in there...
>
> jesse
>
> --
> jesse mcconnell
> jesse.mcconnell@...
>
>
>
> On Wed, Oct 28, 2009 at 09:17, Paul Gier <pgier@...> wrote:
>> I really think it should not be allowed, since it makes the builds less
>> predictable/reproduceable/secure.  Most people I've talked to think it's a
>> bug when they first see it happening because they are trying to figure out
>> why Maven is downloading files from a random location on the Internet.
>>
>> The people who have a corporate policy to only download from central are
>> already breaking their policy whether they list the alternate repo in
>> settings.xml or it is added from a dependency.
>>
>> With that said, I'm ok with having it configurable as Jesse suggests as long
>> as the default behaviour is to not add the repositories to the build.
>>
>> Jesse McConnell wrote:
>>> judging from the response I have gotten from people both wanting and
>>> not wanting repositories declared for various integrations with jetty,
>>> the problem folks seem to be ones where their corporate policy dictate
>>> they can not use any repo other then central but they do not have a
>>> repo manager setup.
>>>
>>> since we can't rightly force people to install and maintain repository
>>> managers, at first blush I would probably error on the side of a
>>> option in the settings.xml a la offline
>>>
>>> <transitiveRepositories>true/false</transtiveRepositories>
>>>
>>> jesse
>>>
>>> --
>>> jesse mcconnell
>>> jesse.mcconnell@...
>>>
>>>
>>>
>>> On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@...> wrote:
>>>> I would advocate not allowing them, but using them to provide useful
>>>> information in the case of a resolution exception that can easily guide
>>>> the
>>>> user on what to do.
>>>>
>>>> If folks strongly want to continue to allow it, I would go with a
>>>> prominent
>>>> warning (which is the case for several other things now).
>>>>
>>>> As to what the user is guided to do - I assume that is to declare them as
>>>> repositories in the current project, or to refer to their repository
>>>> manager's documentation to add it there (with this being recommended). In
>>>> the long run I'd hope Maven can better handle multiple repositories OOTB
>>>> (in
>>>> a way that still complements the use of a repository manager) - actually
>>>> I
>>>> remember briefly talking to Brian about that at last year's ApacheCon
>>>> Maven
>>>> BOF :) Time flies...
>>>>
>>>> - Brett
>>>>
>>>> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> following a comment by Wendy on JIRA, I wanted to re-check what our
>>>>> plans
>>>>> are for repositories in dependency POMs. In more detail, how is
>>>>> dependency
>>>>> resolution in Maven 3.x expected to work here:
>>>>>
>>>>>  project ---depends-on---> A ---depends-on---> B
>>>>>
>>>>> where the POM of A declares the repository R hosting B.
>>>>>
>>>>> Now, when it comes to resolve B's POM/JAR (and its transitive
>>>>> dependencies) in the context of building the project, should Maven 3
>>>>> also
>>>>> consider R (like currently done in Maven 2) or only those repositories
>>>>> that
>>>>> are available for the root of the dependency graph, i.e. the
>>>>> repositories
>>>>> declared in the POM of the project and the settings?
>>>>>
>>>>> Besides the question of the degree of backward-compat we want to keep,
>>>>> the
>>>>> issue with ignoring the repositories declared in dependency POMs I see
>>>>> is
>>>>> the effect on open source projects and their consumers. If one project
>>>>> consumes the artifacts of another, do we want the first project to
>>>>> redeclare
>>>>> all repositories required to resolve the transitive dependencies of the
>>>>> second project? Some arguments for the other side can be found in [1].
>>>>>
>>>>> So, where do we want to go with this?
>>>>>
>>>>>
>>>>> Benjamin
>>>>>
>>>>>
>>>>> [0]
>>>>>
>>>>> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
>>>>> [1] http://jira.codehaus.org/browse/MNG-3056
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>> For additional commands, e-mail: dev-help@...
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

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

[Arnaud HERITIER]

I would like also that we don't use repositories defined in poms for all
reasons explained above.
It's right that changing this behavior will have an important impact because
it could be difficult in certain cases to have an OOTB Build (svn co + mvn
install). Having to update user's settings isn't fun but at least they have
to understand what they are doing and they don't rely on some Maven magic.
For corporate environment they are already doing it to define the global
proxy and it is now easier with plugins like the one in nexus.
If we continue to define repositories in POM not to resolve artifacts but
just to document the build with a nice warning from maven with repo lists
when an artifact isn't found, I think we could have a good compromise.

Arnaud

On Wed, Oct 28, 2009 at 4:16 PM, John Casey <jdcasey@...> wrote:

> Most debian packagers that don't have their apps in the default APT sources
> provide a standard page somewhere on their website for adding a new source.
> This would be pretty easy for third-party repository providers to do, and
> would have the added benefit of making them really think about it and
> support that repository as public infrastructure...along with providing
> ticket/bug tracking for that repository's reachability along with the build
> files or the source code for the app itself.
>
> Of course, there's not much reason I can think of that an OSS project
> wouldn't just configure synchronization with central if they're going to go
> to all this trouble...but for non-OSS I can see them using the above. In
> that case, there's a chance they would want to authenticate/control access
> to that repository anyway, in which case the user would need to modify his
> settings.xml anyway...
>
> -john
>
>
> Jesse McConnell wrote:
>
>> The problem I see is that without being able to push up repositories
>> with third party artifacts that are not in central yet you still
>> depend on for integrations or things like that...you are out of luck
>> and need some mechanism of pushing that knowledge/information to the
>> user of the artifact...and a wiki page or a webpage detailing that is
>> not acceptable imo as it makes it difficult for the user as they need
>> to _find_ that page.
>>
>> Now I would be pro notification as well, along the lines that brett
>> was mentioning I think
>>
>> I can declare a repo in a third party integration, perhaps against a
>> corporate repo that has some open source component they are not
>> syncing to central....and that is _ignored_ in the build, ie never
>> consulted, but when that is detected and if the build is not able to
>> complete it should pump out that information to the user declaring
>> that other repositories have been detected and that perhaps missing
>> dependencies are located in there...
>>
>> jesse
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@...
>>
>>
>>
>> On Wed, Oct 28, 2009 at 09:17, Paul Gier <pgier@...> wrote:
>>
>>> I really think it should not be allowed, since it makes the builds less
>>> predictable/reproduceable/secure.  Most people I've talked to think it's
>>> a
>>> bug when they first see it happening because they are trying to figure
>>> out
>>> why Maven is downloading files from a random location on the Internet.
>>>
>>> The people who have a corporate policy to only download from central are
>>> already breaking their policy whether they list the alternate repo in
>>> settings.xml or it is added from a dependency.
>>>
>>> With that said, I'm ok with having it configurable as Jesse suggests as
>>> long
>>> as the default behaviour is to not add the repositories to the build.
>>>
>>> Jesse McConnell wrote:
>>>
>>>> judging from the response I have gotten from people both wanting and
>>>> not wanting repositories declared for various integrations with jetty,
>>>> the problem folks seem to be ones where their corporate policy dictate
>>>> they can not use any repo other then central but they do not have a
>>>> repo manager setup.
>>>>
>>>> since we can't rightly force people to install and maintain repository
>>>> managers, at first blush I would probably error on the side of a
>>>> option in the settings.xml a la offline
>>>>
>>>> <transitiveRepositories>true/false</transtiveRepositories>
>>>>
>>>> jesse
>>>>
>>>> --
>>>> jesse mcconnell
>>>> jesse.mcconnell@...
>>>>
>>>>
>>>>
>>>> On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@...> wrote:
>>>>
>>>>> I would advocate not allowing them, but using them to provide useful
>>>>> information in the case of a resolution exception that can easily guide
>>>>> the
>>>>> user on what to do.
>>>>>
>>>>> If folks strongly want to continue to allow it, I would go with a
>>>>> prominent
>>>>> warning (which is the case for several other things now).
>>>>>
>>>>> As to what the user is guided to do - I assume that is to declare them
>>>>> as
>>>>> repositories in the current project, or to refer to their repository
>>>>> manager's documentation to add it there (with this being recommended).
>>>>> In
>>>>> the long run I'd hope Maven can better handle multiple repositories
>>>>> OOTB
>>>>> (in
>>>>> a way that still complements the use of a repository manager) -
>>>>> actually
>>>>> I
>>>>> remember briefly talking to Brian about that at last year's ApacheCon
>>>>> Maven
>>>>> BOF :) Time flies...
>>>>>
>>>>> - Brett
>>>>>
>>>>> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
>>>>>
>>>>>  Hi,
>>>>>>
>>>>>> following a comment by Wendy on JIRA, I wanted to re-check what our
>>>>>> plans
>>>>>> are for repositories in dependency POMs. In more detail, how is
>>>>>> dependency
>>>>>> resolution in Maven 3.x expected to work here:
>>>>>>
>>>>>>  project ---depends-on---> A ---depends-on---> B
>>>>>>
>>>>>> where the POM of A declares the repository R hosting B.
>>>>>>
>>>>>> Now, when it comes to resolve B's POM/JAR (and its transitive
>>>>>> dependencies) in the context of building the project, should Maven 3
>>>>>> also
>>>>>> consider R (like currently done in Maven 2) or only those repositories
>>>>>> that
>>>>>> are available for the root of the dependency graph, i.e. the
>>>>>> repositories
>>>>>> declared in the POM of the project and the settings?
>>>>>>
>>>>>> Besides the question of the degree of backward-compat we want to keep,
>>>>>> the
>>>>>> issue with ignoring the repositories declared in dependency POMs I see
>>>>>> is
>>>>>> the effect on open source projects and their consumers. If one project
>>>>>> consumes the artifacts of another, do we want the first project to
>>>>>> redeclare
>>>>>> all repositories required to resolve the transitive dependencies of
>>>>>> the
>>>>>> second project? Some arguments for the other side can be found in [1].
>>>>>>
>>>>>> So, where do we want to go with this?
>>>>>>
>>>>>>
>>>>>> Benjamin
>>>>>>
>>>>>>
>>>>>> [0]
>>>>>>
>>>>>>
>>>>>> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
>>>>>> [1] http://jira.codehaus.org/browse/MNG-3056
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>>> For additional commands, e-mail: dev-help@...
>>>>>>
>>>>>>  ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>> For additional commands, e-mail: dev-help@...
>>>>>
>>>>>
>>>>>  ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Stephen Connolly-2]

2009/10/28 Arnaud HERITIER <aheritier@...>

> I would like also that we don't use repositories defined in poms for all
> reasons explained above.
> It's right that changing this behavior will have an important impact
> because
> it could be difficult in certain cases to have an OOTB Build (svn co + mvn
> install). Having to update user's settings isn't fun but at least they have
> to understand what they are doing and they don't rely on some Maven magic.
>

Also there is nothing stopping us from writting a plugin that imports the
repositories into your settings.xml

In which case for an out of the box build, you would do something like

svn co
mvn bootstrap:settings
mvn install

> For corporate environment they are already doing it to define the global
> proxy and it is now easier with plugins like the one in nexus.
> If we continue to define repositories in POM not to resolve artifacts but
> just to document the build with a nice warning from maven with repo lists
> when an artifact isn't found, I think we could have a good compromise.
>
> Arnaud
>
> On Wed, Oct 28, 2009 at 4:16 PM, John Casey <jdcasey@...>
> wrote:
>
> > Most debian packagers that don't have their apps in the default APT
> sources
> > provide a standard page somewhere on their website for adding a new
> source.
> > This would be pretty easy for third-party repository providers to do, and
> > would have the added benefit of making them really think about it and
> > support that repository as public infrastructure...along with providing
> > ticket/bug tracking for that repository's reachability along with the
> build
> > files or the source code for the app itself.
> >
> > Of course, there's not much reason I can think of that an OSS project
> > wouldn't just configure synchronization with central if they're going to
> go
> > to all this trouble...but for non-OSS I can see them using the above. In
> > that case, there's a chance they would want to authenticate/control
> access
> > to that repository anyway, in which case the user would need to modify
> his
> > settings.xml anyway...
> >
> > -john
> >
> >
> > Jesse McConnell wrote:
> >
> >> The problem I see is that without being able to push up repositories
> >> with third party artifacts that are not in central yet you still
> >> depend on for integrations or things like that...you are out of luck
> >> and need some mechanism of pushing that knowledge/information to the
> >> user of the artifact...and a wiki page or a webpage detailing that is
> >> not acceptable imo as it makes it difficult for the user as they need
> >> to _find_ that page.
> >>
> >> Now I would be pro notification as well, along the lines that brett
> >> was mentioning I think
> >>
> >> I can declare a repo in a third party integration, perhaps against a
> >> corporate repo that has some open source component they are not
> >> syncing to central....and that is _ignored_ in the build, ie never
> >> consulted, but when that is detected and if the build is not able to
> >> complete it should pump out that information to the user declaring
> >> that other repositories have been detected and that perhaps missing
> >> dependencies are located in there...
> >>
> >> jesse
> >>
> >> --
> >> jesse mcconnell
> >> jesse.mcconnell@...
> >>
> >>
> >>
> >> On Wed, Oct 28, 2009 at 09:17, Paul Gier <pgier@...> wrote:
> >>
> >>> I really think it should not be allowed, since it makes the builds less
> >>> predictable/reproduceable/secure.  Most people I've talked to think
> it's
> >>> a
> >>> bug when they first see it happening because they are trying to figure
> >>> out
> >>> why Maven is downloading files from a random location on the Internet.
> >>>
> >>> The people who have a corporate policy to only download from central
> are
> >>> already breaking their policy whether they list the alternate repo in
> >>> settings.xml or it is added from a dependency.
> >>>
> >>> With that said, I'm ok with having it configurable as Jesse suggests as
> >>> long
> >>> as the default behaviour is to not add the repositories to the build.
> >>>
> >>> Jesse McConnell wrote:
> >>>
> >>>> judging from the response I have gotten from people both wanting and
> >>>> not wanting repositories declared for various integrations with jetty,
> >>>> the problem folks seem to be ones where their corporate policy dictate
> >>>> they can not use any repo other then central but they do not have a
> >>>> repo manager setup.
> >>>>
> >>>> since we can't rightly force people to install and maintain repository
> >>>> managers, at first blush I would probably error on the side of a
> >>>> option in the settings.xml a la offline
> >>>>
> >>>> <transitiveRepositories>true/false</transtiveRepositories>
> >>>>
> >>>> jesse
> >>>>
> >>>> --
> >>>> jesse mcconnell
> >>>> jesse.mcconnell@...
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@...> wrote:
> >>>>
> >>>>> I would advocate not allowing them, but using them to provide useful
> >>>>> information in the case of a resolution exception that can easily
> guide
> >>>>> the
> >>>>> user on what to do.
> >>>>>
> >>>>> If folks strongly want to continue to allow it, I would go with a
> >>>>> prominent
> >>>>> warning (which is the case for several other things now).
> >>>>>
> >>>>> As to what the user is guided to do - I assume that is to declare
> them
> >>>>> as
> >>>>> repositories in the current project, or to refer to their repository
> >>>>> manager's documentation to add it there (with this being
> recommended).
> >>>>> In
> >>>>> the long run I'd hope Maven can better handle multiple repositories
> >>>>> OOTB
> >>>>> (in
> >>>>> a way that still complements the use of a repository manager) -
> >>>>> actually
> >>>>> I
> >>>>> remember briefly talking to Brian about that at last year's ApacheCon
> >>>>> Maven
> >>>>> BOF :) Time flies...
> >>>>>
> >>>>> - Brett
> >>>>>
> >>>>> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
> >>>>>
> >>>>>  Hi,
> >>>>>>
> >>>>>> following a comment by Wendy on JIRA, I wanted to re-check what our
> >>>>>> plans
> >>>>>> are for repositories in dependency POMs. In more detail, how is
> >>>>>> dependency
> >>>>>> resolution in Maven 3.x expected to work here:
> >>>>>>
> >>>>>>  project ---depends-on---> A ---depends-on---> B
> >>>>>>
> >>>>>> where the POM of A declares the repository R hosting B.
> >>>>>>
> >>>>>> Now, when it comes to resolve B's POM/JAR (and its transitive
> >>>>>> dependencies) in the context of building the project, should Maven 3
> >>>>>> also
> >>>>>> consider R (like currently done in Maven 2) or only those
> repositories
> >>>>>> that
> >>>>>> are available for the root of the dependency graph, i.e. the
> >>>>>> repositories
> >>>>>> declared in the POM of the project and the settings?
> >>>>>>
> >>>>>> Besides the question of the degree of backward-compat we want to
> keep,
> >>>>>> the
> >>>>>> issue with ignoring the repositories declared in dependency POMs I
> see
> >>>>>> is
> >>>>>> the effect on open source projects and their consumers. If one
> project
> >>>>>> consumes the artifacts of another, do we want the first project to
> >>>>>> redeclare
> >>>>>> all repositories required to resolve the transitive dependencies of
> >>>>>> the
> >>>>>> second project? Some arguments for the other side can be found in
> [1].
> >>>>>>
> >>>>>> So, where do we want to go with this?
> >>>>>>
> >>>>>>
> >>>>>> Benjamin
> >>>>>>
> >>>>>>
> >>>>>> [0]
> >>>>>>
> >>>>>>
> >>>>>>
> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
> >>>>>> [1] http://jira.codehaus.org/browse/MNG-3056
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
> >>>>>> For additional commands, e-mail: dev-help@...
> >>>>>>
> >>>>>>
>  ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@...
> >>>>> For additional commands, e-mail: dev-help@...
> >>>>>
> >>>>>
> >>>>>
>  ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@...
> >>>> For additional commands, e-mail: dev-help@...
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@...
> >>> For additional commands, e-mail: dev-help@...
> >>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >>
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>

[Stephen Connolly-2]

2009/10/28 Stephen Connolly <stephen.alan.connolly@...>

> 2009/10/28 Arnaud HERITIER <aheritier@...>
>
> I would like also that we don't use repositories defined in poms for all
>> reasons explained above.
>> It's right that changing this behavior will have an important impact
>> because
>> it could be difficult in certain cases to have an OOTB Build (svn co + mvn
>> install). Having to update user's settings isn't fun but at least they
>> have
>> to understand what they are doing and they don't rely on some Maven magic.
>>
>
> Also there is nothing stopping us from writting a plugin that imports the
> repositories into your settings.xml
>
> In which case for an out of the box build, you would do something like
>
> svn co
> mvn bootstrap:settings
>

Note that this would print out big ugly warning messages and prompt for each
repository... but at least people don't have to figure out how to edit their
settings.xml ;-)

> mvn install
>
>
>> For corporate environment they are already doing it to define the global
>> proxy and it is now easier with plugins like the one in nexus.
>> If we continue to define repositories in POM not to resolve artifacts but
>> just to document the build with a nice warning from maven with repo lists
>> when an artifact isn't found, I think we could have a good compromise.
>>
>> Arnaud
>>
>> On Wed, Oct 28, 2009 at 4:16 PM, John Casey <jdcasey@...>
>> wrote:
>>
>> > Most debian packagers that don't have their apps in the default APT
>> sources
>> > provide a standard page somewhere on their website for adding a new
>> source.
>> > This would be pretty easy for third-party repository providers to do,
>> and
>> > would have the added benefit of making them really think about it and
>> > support that repository as public infrastructure...along with providing
>> > ticket/bug tracking for that repository's reachability along with the
>> build
>> > files or the source code for the app itself.
>> >
>> > Of course, there's not much reason I can think of that an OSS project
>> > wouldn't just configure synchronization with central if they're going to
>> go
>> > to all this trouble...but for non-OSS I can see them using the above. In
>> > that case, there's a chance they would want to authenticate/control
>> access
>> > to that repository anyway, in which case the user would need to modify
>> his
>> > settings.xml anyway...
>> >
>> > -john
>> >
>> >
>> > Jesse McConnell wrote:
>> >
>> >> The problem I see is that without being able to push up repositories
>> >> with third party artifacts that are not in central yet you still
>> >> depend on for integrations or things like that...you are out of luck
>> >> and need some mechanism of pushing that knowledge/information to the
>> >> user of the artifact...and a wiki page or a webpage detailing that is
>> >> not acceptable imo as it makes it difficult for the user as they need
>> >> to _find_ that page.
>> >>
>> >> Now I would be pro notification as well, along the lines that brett
>> >> was mentioning I think
>> >>
>> >> I can declare a repo in a third party integration, perhaps against a
>> >> corporate repo that has some open source component they are not
>> >> syncing to central....and that is _ignored_ in the build, ie never
>> >> consulted, but when that is detected and if the build is not able to
>> >> complete it should pump out that information to the user declaring
>> >> that other repositories have been detected and that perhaps missing
>> >> dependencies are located in there...
>> >>
>> >> jesse
>> >>
>> >> --
>> >> jesse mcconnell
>> >> jesse.mcconnell@...
>> >>
>> >>
>> >>
>> >> On Wed, Oct 28, 2009 at 09:17, Paul Gier <pgier@...> wrote:
>> >>
>> >>> I really think it should not be allowed, since it makes the builds
>> less
>> >>> predictable/reproduceable/secure.  Most people I've talked to think
>> it's
>> >>> a
>> >>> bug when they first see it happening because they are trying to figure
>> >>> out
>> >>> why Maven is downloading files from a random location on the Internet.
>> >>>
>> >>> The people who have a corporate policy to only download from central
>> are
>> >>> already breaking their policy whether they list the alternate repo in
>> >>> settings.xml or it is added from a dependency.
>> >>>
>> >>> With that said, I'm ok with having it configurable as Jesse suggests
>> as
>> >>> long
>> >>> as the default behaviour is to not add the repositories to the build.
>> >>>
>> >>> Jesse McConnell wrote:
>> >>>
>> >>>> judging from the response I have gotten from people both wanting and
>> >>>> not wanting repositories declared for various integrations with
>> jetty,
>> >>>> the problem folks seem to be ones where their corporate policy
>> dictate
>> >>>> they can not use any repo other then central but they do not have a
>> >>>> repo manager setup.
>> >>>>
>> >>>> since we can't rightly force people to install and maintain
>> repository
>> >>>> managers, at first blush I would probably error on the side of a
>> >>>> option in the settings.xml a la offline
>> >>>>
>> >>>> <transitiveRepositories>true/false</transtiveRepositories>
>> >>>>
>> >>>> jesse
>> >>>>
>> >>>> --
>> >>>> jesse mcconnell
>> >>>> jesse.mcconnell@...
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@...>
>> wrote:
>> >>>>
>> >>>>> I would advocate not allowing them, but using them to provide useful
>> >>>>> information in the case of a resolution exception that can easily
>> guide
>> >>>>> the
>> >>>>> user on what to do.
>> >>>>>
>> >>>>> If folks strongly want to continue to allow it, I would go with a
>> >>>>> prominent
>> >>>>> warning (which is the case for several other things now).
>> >>>>>
>> >>>>> As to what the user is guided to do - I assume that is to declare
>> them
>> >>>>> as
>> >>>>> repositories in the current project, or to refer to their repository
>> >>>>> manager's documentation to add it there (with this being
>> recommended).
>> >>>>> In
>> >>>>> the long run I'd hope Maven can better handle multiple repositories
>> >>>>> OOTB
>> >>>>> (in
>> >>>>> a way that still complements the use of a repository manager) -
>> >>>>> actually
>> >>>>> I
>> >>>>> remember briefly talking to Brian about that at last year's
>> ApacheCon
>> >>>>> Maven
>> >>>>> BOF :) Time flies...
>> >>>>>
>> >>>>> - Brett
>> >>>>>
>> >>>>> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
>> >>>>>
>> >>>>>  Hi,
>> >>>>>>
>> >>>>>> following a comment by Wendy on JIRA, I wanted to re-check what our
>> >>>>>> plans
>> >>>>>> are for repositories in dependency POMs. In more detail, how is
>> >>>>>> dependency
>> >>>>>> resolution in Maven 3.x expected to work here:
>> >>>>>>
>> >>>>>>  project ---depends-on---> A ---depends-on---> B
>> >>>>>>
>> >>>>>> where the POM of A declares the repository R hosting B.
>> >>>>>>
>> >>>>>> Now, when it comes to resolve B's POM/JAR (and its transitive
>> >>>>>> dependencies) in the context of building the project, should Maven
>> 3
>> >>>>>> also
>> >>>>>> consider R (like currently done in Maven 2) or only those
>> repositories
>> >>>>>> that
>> >>>>>> are available for the root of the dependency graph, i.e. the
>> >>>>>> repositories
>> >>>>>> declared in the POM of the project and the settings?
>> >>>>>>
>> >>>>>> Besides the question of the degree of backward-compat we want to
>> keep,
>> >>>>>> the
>> >>>>>> issue with ignoring the repositories declared in dependency POMs I
>> see
>> >>>>>> is
>> >>>>>> the effect on open source projects and their consumers. If one
>> project
>> >>>>>> consumes the artifacts of another, do we want the first project to
>> >>>>>> redeclare
>> >>>>>> all repositories required to resolve the transitive dependencies of
>> >>>>>> the
>> >>>>>> second project? Some arguments for the other side can be found in
>> [1].
>> >>>>>>
>> >>>>>> So, where do we want to go with this?
>> >>>>>>
>> >>>>>>
>> >>>>>> Benjamin
>> >>>>>>
>> >>>>>>
>> >>>>>> [0]
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
>> >>>>>> [1] http://jira.codehaus.org/browse/MNG-3056
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>> >>>>>> For additional commands, e-mail: dev-help@...
>> >>>>>>
>> >>>>>>
>>  ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>> >>>>> For additional commands, e-mail: dev-help@...
>> >>>>>
>> >>>>>
>> >>>>>
>>  ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@...
>> >>>> For additional commands, e-mail: dev-help@...
>> >>>>
>> >>>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@...
>> >>> For additional commands, e-mail: dev-help@...
>> >>>
>> >>>
>> >>>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@...
>> >> For additional commands, e-mail: dev-help@...
>> >>
>> >>
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@...
>> > For additional commands, e-mail: dev-help@...
>> >
>> >
>>
>
>

[Arnaud HERITIER]

I agree we can have tooling for that.
We can imagine we add in user's settings a dedicated profile for the project
with all repositories (but for that we have to reactivate the repositories
chain to discover them ;-) )


On Wed, Oct 28, 2009 at 4:56 PM, Stephen Connolly <
stephen.alan.connolly@...> wrote:

> 2009/10/28 Stephen Connolly <stephen.alan.connolly@...>
>
> > 2009/10/28 Arnaud HERITIER <aheritier@...>
> >
> > I would like also that we don't use repositories defined in poms for all
> >> reasons explained above.
> >> It's right that changing this behavior will have an important impact
> >> because
> >> it could be difficult in certain cases to have an OOTB Build (svn co +
> mvn
> >> install). Having to update user's settings isn't fun but at least they
> >> have
> >> to understand what they are doing and they don't rely on some Maven
> magic.
> >>
> >
> > Also there is nothing stopping us from writting a plugin that imports the
> > repositories into your settings.xml
> >
> > In which case for an out of the box build, you would do something like
> >
> > svn co
> > mvn bootstrap:settings
> >
>
> Note that this would print out big ugly warning messages and prompt for
> each
> repository... but at least people don't have to figure out how to edit
> their
> settings.xml ;-)
>
>
> > mvn install
> >
> >
> >> For corporate environment they are already doing it to define the global
> >> proxy and it is now easier with plugins like the one in nexus.
> >> If we continue to define repositories in POM not to resolve artifacts
> but
> >> just to document the build with a nice warning from maven with repo
> lists
> >> when an artifact isn't found, I think we could have a good compromise.
> >>
> >> Arnaud
> >>
> >> On Wed, Oct 28, 2009 at 4:16 PM, John Casey <jdcasey@...>
> >> wrote:
> >>
> >> > Most debian packagers that don't have their apps in the default APT
> >> sources
> >> > provide a standard page somewhere on their website for adding a new
> >> source.
> >> > This would be pretty easy for third-party repository providers to do,
> >> and
> >> > would have the added benefit of making them really think about it and
> >> > support that repository as public infrastructure...along with
> providing
> >> > ticket/bug tracking for that repository's reachability along with the
> >> build
> >> > files or the source code for the app itself.
> >> >
> >> > Of course, there's not much reason I can think of that an OSS project
> >> > wouldn't just configure synchronization with central if they're going
> to
> >> go
> >> > to all this trouble...but for non-OSS I can see them using the above.
> In
> >> > that case, there's a chance they would want to authenticate/control
> >> access
> >> > to that repository anyway, in which case the user would need to modify
> >> his
> >> > settings.xml anyway...
> >> >
> >> > -john
> >> >
> >> >
> >> > Jesse McConnell wrote:
> >> >
> >> >> The problem I see is that without being able to push up repositories
> >> >> with third party artifacts that are not in central yet you still
> >> >> depend on for integrations or things like that...you are out of luck
> >> >> and need some mechanism of pushing that knowledge/information to the
> >> >> user of the artifact...and a wiki page or a webpage detailing that is
> >> >> not acceptable imo as it makes it difficult for the user as they need
> >> >> to _find_ that page.
> >> >>
> >> >> Now I would be pro notification as well, along the lines that brett
> >> >> was mentioning I think
> >> >>
> >> >> I can declare a repo in a third party integration, perhaps against a
> >> >> corporate repo that has some open source component they are not
> >> >> syncing to central....and that is _ignored_ in the build, ie never
> >> >> consulted, but when that is detected and if the build is not able to
> >> >> complete it should pump out that information to the user declaring
> >> >> that other repositories have been detected and that perhaps missing
> >> >> dependencies are located in there...
> >> >>
> >> >> jesse
> >> >>
> >> >> --
> >> >> jesse mcconnell
> >> >> jesse.mcconnell@...
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Oct 28, 2009 at 09:17, Paul Gier <pgier@...> wrote:
> >> >>
> >> >>> I really think it should not be allowed, since it makes the builds
> >> less
> >> >>> predictable/reproduceable/secure.  Most people I've talked to think
> >> it's
> >> >>> a
> >> >>> bug when they first see it happening because they are trying to
> figure
> >> >>> out
> >> >>> why Maven is downloading files from a random location on the
> Internet.
> >> >>>
> >> >>> The people who have a corporate policy to only download from central
> >> are
> >> >>> already breaking their policy whether they list the alternate repo
> in
> >> >>> settings.xml or it is added from a dependency.
> >> >>>
> >> >>> With that said, I'm ok with having it configurable as Jesse suggests
> >> as
> >> >>> long
> >> >>> as the default behaviour is to not add the repositories to the
> build.
> >> >>>
> >> >>> Jesse McConnell wrote:
> >> >>>
> >> >>>> judging from the response I have gotten from people both wanting
> and
> >> >>>> not wanting repositories declared for various integrations with
> >> jetty,
> >> >>>> the problem folks seem to be ones where their corporate policy
> >> dictate
> >> >>>> they can not use any repo other then central but they do not have a
> >> >>>> repo manager setup.
> >> >>>>
> >> >>>> since we can't rightly force people to install and maintain
> >> repository
> >> >>>> managers, at first blush I would probably error on the side of a
> >> >>>> option in the settings.xml a la offline
> >> >>>>
> >> >>>> <transitiveRepositories>true/false</transtiveRepositories>
> >> >>>>
> >> >>>> jesse
> >> >>>>
> >> >>>> --
> >> >>>> jesse mcconnell
> >> >>>> jesse.mcconnell@...
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@...>
> >> wrote:
> >> >>>>
> >> >>>>> I would advocate not allowing them, but using them to provide
> useful
> >> >>>>> information in the case of a resolution exception that can easily
> >> guide
> >> >>>>> the
> >> >>>>> user on what to do.
> >> >>>>>
> >> >>>>> If folks strongly want to continue to allow it, I would go with a
> >> >>>>> prominent
> >> >>>>> warning (which is the case for several other things now).
> >> >>>>>
> >> >>>>> As to what the user is guided to do - I assume that is to declare
> >> them
> >> >>>>> as
> >> >>>>> repositories in the current project, or to refer to their
> repository
> >> >>>>> manager's documentation to add it there (with this being
> >> recommended).
> >> >>>>> In
> >> >>>>> the long run I'd hope Maven can better handle multiple
> repositories
> >> >>>>> OOTB
> >> >>>>> (in
> >> >>>>> a way that still complements the use of a repository manager) -
> >> >>>>> actually
> >> >>>>> I
> >> >>>>> remember briefly talking to Brian about that at last year's
> >> ApacheCon
> >> >>>>> Maven
> >> >>>>> BOF :) Time flies...
> >> >>>>>
> >> >>>>> - Brett
> >> >>>>>
> >> >>>>> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
> >> >>>>>
> >> >>>>>  Hi,
> >> >>>>>>
> >> >>>>>> following a comment by Wendy on JIRA, I wanted to re-check what
> our
> >> >>>>>> plans
> >> >>>>>> are for repositories in dependency POMs. In more detail, how is
> >> >>>>>> dependency
> >> >>>>>> resolution in Maven 3.x expected to work here:
> >> >>>>>>
> >> >>>>>>  project ---depends-on---> A ---depends-on---> B
> >> >>>>>>
> >> >>>>>> where the POM of A declares the repository R hosting B.
> >> >>>>>>
> >> >>>>>> Now, when it comes to resolve B's POM/JAR (and its transitive
> >> >>>>>> dependencies) in the context of building the project, should
> Maven
> >> 3
> >> >>>>>> also
> >> >>>>>> consider R (like currently done in Maven 2) or only those
> >> repositories
> >> >>>>>> that
> >> >>>>>> are available for the root of the dependency graph, i.e. the
> >> >>>>>> repositories
> >> >>>>>> declared in the POM of the project and the settings?
> >> >>>>>>
> >> >>>>>> Besides the question of the degree of backward-compat we want to
> >> keep,
> >> >>>>>> the
> >> >>>>>> issue with ignoring the repositories declared in dependency POMs
> I
> >> see
> >> >>>>>> is
> >> >>>>>> the effect on open source projects and their consumers. If one
> >> project
> >> >>>>>> consumes the artifacts of another, do we want the first project
> to
> >> >>>>>> redeclare
> >> >>>>>> all repositories required to resolve the transitive dependencies
> of
> >> >>>>>> the
> >> >>>>>> second project? Some arguments for the other side can be found in
> >> [1].
> >> >>>>>>
> >> >>>>>> So, where do we want to go with this?
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Benjamin
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> [0]
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >>
> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
> >> >>>>>> [1] http://jira.codehaus.org/browse/MNG-3056
> >> >>>>>>
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
> >> >>>>>> For additional commands, e-mail: dev-help@...
> >> >>>>>>
> >> >>>>>>
> >>  ---------------------------------------------------------------------
> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@...
> >> >>>>> For additional commands, e-mail: dev-help@...
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >>  ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@...
> >> >>>> For additional commands, e-mail: dev-help@...
> >> >>>>
> >> >>>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@...
> >> >>> For additional commands, e-mail: dev-help@...
> >> >>>
> >> >>>
> >> >>>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> >> For additional commands, e-mail: dev-help@...
> >> >>
> >> >>
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@...
> >> > For additional commands, e-mail: dev-help@...
> >> >
> >> >
> >>
> >
> >
>

[Dan Rollo-2]

(Lurker post) ;)

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.

What about some sort of local "override" of settings.xml?
eg: If the directory containing the pom.xml ALSO contains a file named
settings.xml (or local.setting.xml, or .settings.xml, not sure what name
is best), then the "project local" settings will take precedence.
This way, the simple "get latest from the bank and build" use case is
still maintainable.

I recognize the security issues previously mentioned, but every time I
have to touch a file outside the project directory in order to ensure
anyone can build a project, I feel it is a step backwards...

Dan Rollo

Arnaud HERITIER wrote:

> I agree we can have tooling for that.
> We can imagine we add in user's settings a dedicated profile for the project
> with all repositories (but for that we have to reactivate the repositories
> chain to discover them ;-) )
>
>
> On Wed, Oct 28, 2009 at 4:56 PM, Stephen Connolly <
> stephen.alan.connolly@...> wrote:
>
>> 2009/10/28 Stephen Connolly <stephen.alan.connolly@...>
>>
>>> 2009/10/28 Arnaud HERITIER <aheritier@...>
>>>
>>> I would like also that we don't use repositories defined in poms for all
>>>> reasons explained above.
>>>> It's right that changing this behavior will have an important impact
>>>> because
>>>> it could be difficult in certain cases to have an OOTB Build (svn co +
>> mvn
>>>> install). Having to update user's settings isn't fun but at least they
>>>> have
>>>> to understand what they are doing and they don't rely on some Maven
>> magic.
>>> Also there is nothing stopping us from writting a plugin that imports the
>>> repositories into your settings.xml
>>>
>>> In which case for an out of the box build, you would do something like
>>>
>>> svn co
>>> mvn bootstrap:settings
>>>
>> Note that this would print out big ugly warning messages and prompt for
>> each
>> repository... but at least people don't have to figure out how to edit
>> their
>> settings.xml ;-)
>>
>>
>>> mvn install
>>>
>>>
>>>> For corporate environment they are already doing it to define the global
>>>> proxy and it is now easier with plugins like the one in nexus.
>>>> If we continue to define repositories in POM not to resolve artifacts
>> but
>>>> just to document the build with a nice warning from maven with repo
>> lists
>>>> when an artifact isn't found, I think we could have a good compromise.
>>>>
>>>> Arnaud
>>>>
>>>> On Wed, Oct 28, 2009 at 4:16 PM, John Casey <jdcasey@...>
>>>> wrote:
>>>>
>>>>> Most debian packagers that don't have their apps in the default APT
>>>> sources
>>>>> provide a standard page somewhere on their website for adding a new
>>>> source.
>>>>> This would be pretty easy for third-party repository providers to do,
>>>> and
>>>>> would have the added benefit of making them really think about it and
>>>>> support that repository as public infrastructure...along with
>> providing
>>>>> ticket/bug tracking for that repository's reachability along with the
>>>> build
>>>>> files or the source code for the app itself.
>>>>>
>>>>> Of course, there's not much reason I can think of that an OSS project
>>>>> wouldn't just configure synchronization with central if they're going
>> to
>>>> go
>>>>> to all this trouble...but for non-OSS I can see them using the above.
>> In
>>>>> that case, there's a chance they would want to authenticate/control
>>>> access
>>>>> to that repository anyway, in which case the user would need to modify
>>>> his
>>>>> settings.xml anyway...
>>>>>
>>>>> -john
>>>>>
>>>>>
>>>>> Jesse McConnell wrote:
>>>>>
>>>>>> The problem I see is that without being able to push up repositories
>>>>>> with third party artifacts that are not in central yet you still
>>>>>> depend on for integrations or things like that...you are out of luck
>>>>>> and need some mechanism of pushing that knowledge/information to the
>>>>>> user of the artifact...and a wiki page or a webpage detailing that is
>>>>>> not acceptable imo as it makes it difficult for the user as they need
>>>>>> to _find_ that page.
>>>>>>
>>>>>> Now I would be pro notification as well, along the lines that brett
>>>>>> was mentioning I think
>>>>>>
>>>>>> I can declare a repo in a third party integration, perhaps against a
>>>>>> corporate repo that has some open source component they are not
>>>>>> syncing to central....and that is _ignored_ in the build, ie never
>>>>>> consulted, but when that is detected and if the build is not able to
>>>>>> complete it should pump out that information to the user declaring
>>>>>> that other repositories have been detected and that perhaps missing
>>>>>> dependencies are located in there...
>>>>>>
>>>>>> jesse
>>>>>>
>>>>>> --
>>>>>> jesse mcconnell
>>>>>> jesse.mcconnell@...
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 28, 2009 at 09:17, Paul Gier <pgier@...> wrote:
>>>>>>
>>>>>>> I really think it should not be allowed, since it makes the builds
>>>> less
>>>>>>> predictable/reproduceable/secure.  Most people I've talked to think
>>>> it's
>>>>>>> a
>>>>>>> bug when they first see it happening because they are trying to
>> figure
>>>>>>> out
>>>>>>> why Maven is downloading files from a random location on the
>> Internet.
>>>>>>> The people who have a corporate policy to only download from central
>>>> are
>>>>>>> already breaking their policy whether they list the alternate repo
>> in
>>>>>>> settings.xml or it is added from a dependency.
>>>>>>>
>>>>>>> With that said, I'm ok with having it configurable as Jesse suggests
>>>> as
>>>>>>> long
>>>>>>> as the default behaviour is to not add the repositories to the
>> build.
>>>>>>> Jesse McConnell wrote:
>>>>>>>
>>>>>>>> judging from the response I have gotten from people both wanting
>> and
>>>>>>>> not wanting repositories declared for various integrations with
>>>> jetty,
>>>>>>>> the problem folks seem to be ones where their corporate policy
>>>> dictate
>>>>>>>> they can not use any repo other then central but they do not have a
>>>>>>>> repo manager setup.
>>>>>>>>
>>>>>>>> since we can't rightly force people to install and maintain
>>>> repository
>>>>>>>> managers, at first blush I would probably error on the side of a
>>>>>>>> option in the settings.xml a la offline
>>>>>>>>
>>>>>>>> <transitiveRepositories>true/false</transtiveRepositories>
>>>>>>>>
>>>>>>>> jesse
>>>>>>>>
>>>>>>>> --
>>>>>>>> jesse mcconnell
>>>>>>>> jesse.mcconnell@...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@...>
>>>> wrote:
>>>>>>>>> I would advocate not allowing them, but using them to provide
>> useful
>>>>>>>>> information in the case of a resolution exception that can easily
>>>> guide
>>>>>>>>> the
>>>>>>>>> user on what to do.
>>>>>>>>>
>>>>>>>>> If folks strongly want to continue to allow it, I would go with a
>>>>>>>>> prominent
>>>>>>>>> warning (which is the case for several other things now).
>>>>>>>>>
>>>>>>>>> As to what the user is guided to do - I assume that is to declare
>>>> them
>>>>>>>>> as
>>>>>>>>> repositories in the current project, or to refer to their
>> repository
>>>>>>>>> manager's documentation to add it there (with this being
>>>> recommended).
>>>>>>>>> In
>>>>>>>>> the long run I'd hope Maven can better handle multiple
>> repositories
>>>>>>>>> OOTB
>>>>>>>>> (in
>>>>>>>>> a way that still complements the use of a repository manager) -
>>>>>>>>> actually
>>>>>>>>> I
>>>>>>>>> remember briefly talking to Brian about that at last year's
>>>> ApacheCon
>>>>>>>>> Maven
>>>>>>>>> BOF :) Time flies...
>>>>>>>>>
>>>>>>>>> - Brett
>>>>>>>>>
>>>>>>>>> On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote:
>>>>>>>>>
>>>>>>>>>  Hi,
>>>>>>>>>> following a comment by Wendy on JIRA, I wanted to re-check what
>> our
>>>>>>>>>> plans
>>>>>>>>>> are for repositories in dependency POMs. In more detail, how is
>>>>>>>>>> dependency
>>>>>>>>>> resolution in Maven 3.x expected to work here:
>>>>>>>>>>
>>>>>>>>>>  project ---depends-on---> A ---depends-on---> B
>>>>>>>>>>
>>>>>>>>>> where the POM of A declares the repository R hosting B.
>>>>>>>>>>
>>>>>>>>>> Now, when it comes to resolve B's POM/JAR (and its transitive
>>>>>>>>>> dependencies) in the context of building the project, should
>> Maven
>>>> 3
>>>>>>>>>> also
>>>>>>>>>> consider R (like currently done in Maven 2) or only those
>>>> repositories
>>>>>>>>>> that
>>>>>>>>>> are available for the root of the dependency graph, i.e. the
>>>>>>>>>> repositories
>>>>>>>>>> declared in the POM of the project and the settings?
>>>>>>>>>>
>>>>>>>>>> Besides the question of the degree of backward-compat we want to
>>>> keep,
>>>>>>>>>> the
>>>>>>>>>> issue with ignoring the repositories declared in dependency POMs
>> I
>>>> see
>>>>>>>>>> is
>>>>>>>>>> the effect on open source projects and their consumers. If one
>>>> project
>>>>>>>>>> consumes the artifacts of another, do we want the first project
>> to
>>>>>>>>>> redeclare
>>>>>>>>>> all repositories required to resolve the transitive dependencies
>> of
>>>>>>>>>> the
>>>>>>>>>> second project? Some arguments for the other side can be found in
>>>> [1].
>>>>>>>>>> So, where do we want to go with this?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Benjamin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [0]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>> http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344
>>>>>>>>>> [1] http://jira.codehaus.org/browse/MNG-3056
>>>>>>>>>>
>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>>>>>>> For additional commands, e-mail: dev-help@...
>>>>>>>>>>
>>>>>>>>>>
>>>>  ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>>>>>> For additional commands, e-mail: dev-help@...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>  ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>>>>> For additional commands, e-mail: dev-help@...
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>>>> For additional commands, e-mail: dev-help@...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>>> For additional commands, e-mail: dev-help@...
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>> For additional commands, e-mail: dev-help@...
>>>>>
>>>>>
>>>
>

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

[Wendy Smoak-3]

On Wed, Oct 28, 2009 at 4:52 AM, Benjamin Bentmann
<benjamin.bentmann@...> wrote:
> following a comment by Wendy on JIRA, I wanted to re-check what our plans
> are for repositories in dependency POMs. In more detail, how is dependency
> resolution in Maven 3.x expected to work

Thanks for bringing this up, Benjamin.  I knew it sounded familiar,
but June 2007 was a long time ago!

I don't think that my dependencies should be able to contribute
repositories to my build.  When Maven starts downloading things from
seemingly random places, it gives a bad first impression, especially
to security conscious corporate users.

So yes, if I'm building A, and B's dependencies are not available in
Central (or my internal repo) I expect to have to take some action,
either adding it to my settings or to my repo manager's proxy config
(or manually deploying each of the dependencies to my internal repo
after they are vetted.)

I like Brett's idea about using the pom repo information in the error message.

--
Wendy

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

[brettporter]

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

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

[Stephen Connolly-2]

2009/10/28 Brett Porter <brett@...>

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

[BRIAN FOX-5]

It's amazing how google's thread compression of a discussion can cause
me to overlook a huge thread so near and dear to my heart.

To start, Benjamin has hit the nail on the head of a discussion point
Jason and I have had going for quite some time. In fact, we even wrote
up a proposal for it months ago that got little feedback. I've also
blogged on this subject before.

Written and suggested reading in this order:
http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery

I won't rehash all of what I've already written, and leave it to the
reader to follow the above urls for the majority of the points however
I think there is one key argument that is worth reiterating:

The ability of a user to checkout an open source project with no prior
knowledge of it and simply be able to build it, run the tests and
patch it the first try is the most powerful way to demonstrate the
Maven to new users. Simply removing or ignoring repositories in the
poms will break this functionality that I feel pretty strongly about.

All of the arguments so far in this thread mostly revolve around
issues in corporate / enterprise use, and for these issues repository
managers are the best solution. I don't think its in the best interest
of the community to break OSS use to support Enterprise use,
particularly when that problem is already covered.

Specifically, I'm pretty strongly in favor of continuing to support
repositories declared in poms, however they should be scoped for only
the subtree of dependencies introduced by the pom declaring the repo.
Further, I recognize that having urls burned into immutable poms is
not the best way to accomplish this, and I think we need to find a
better one pretty quickly.

--Brian

On Wed, Oct 28, 2009 at 7:57 PM, Stephen Connolly
<stephen.alan.connolly@...> wrote:

> 2009/10/28 Brett Porter <brett@...>
>
>>
>> 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-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>

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

[struberg]

Hi!

Just make a step back and look at the repository problematic from a bit different perspective.

I'm working for a few companies and even different projects in those companies use different <repositories> sections in their poms.
But in my local repo, all the artifacts from those repositories gets merged to a single big landfill.

When I switch to a different project, with no repositories configured, I may pick up a wrong dependency this way. Or I may be able to compile and even release, but my colleagues are not, because this very <repository> is missing in the projects pom.

What about remembering where an artifact came from in the local repo?
E.g. something like

~/.m2/repository   // this contains the locally installed artifacts and stuff, and also acts for backward compatibility. It is always 'active']
~/.m2/repositories/[http_repo1.maven.org.maven2]/com/apache...
~/.m2/repositories/[http_dev.java.net/maven2]/javax/enterprise...
~/.m2/repositories/[http_dist.codehaus.org_mule_dependencies_maven2]/org/jruby...

If a <repository> is not activated for a specific project then the local artifacts will not be picked up. from .m2/repositories. If a transitive dependency defines a new <repositories> those will be added at the end of the chain. We should think about collision detection, but this should be detectable at least.

There are most probably also things to consider for repository managers.

I'm not sure if it is worth the effort though.

LieGrue,
strub





----- Ursprüngliche Mail ----

> Von: Brian Fox <brianf@...>
> An: Maven Developers List <dev@...>
> Gesendet: Donnerstag, den 29. Oktober 2009, 20:27:00 Uhr
> Betreff: Re: [DISCUSS] Handling of repositories in POMs of dependencies
>
> It's amazing how google's thread compression of a discussion can cause
> me to overlook a huge thread so near and dear to my heart.
>
> To start, Benjamin has hit the nail on the head of a discussion point
> Jason and I have had going for quite some time. In fact, we even wrote
> up a proposal for it months ago that got little feedback. I've also
> blogged on this subject before.
>
> Written and suggested reading in this order:
> http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
> http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery
>
> I won't rehash all of what I've already written, and leave it to the
> reader to follow the above urls for the majority of the points however
> I think there is one key argument that is worth reiterating:
>
> The ability of a user to checkout an open source project with no prior
> knowledge of it and simply be able to build it, run the tests and
> patch it the first try is the most powerful way to demonstrate the
> Maven to new users. Simply removing or ignoring repositories in the
> poms will break this functionality that I feel pretty strongly about.
>
> All of the arguments so far in this thread mostly revolve around
> issues in corporate / enterprise use, and for these issues repository
> managers are the best solution. I don't think its in the best interest
> of the community to break OSS use to support Enterprise use,
> particularly when that problem is already covered.
>
> Specifically, I'm pretty strongly in favor of continuing to support
> repositories declared in poms, however they should be scoped for only
> the subtree of dependencies introduced by the pom declaring the repo.
> Further, I recognize that having urls burned into immutable poms is
> not the best way to accomplish this, and I think we need to find a
> better one pretty quickly.
>
> --Brian
>
> On Wed, Oct 28, 2009 at 7:57 PM, Stephen Connolly
> wrote:
> > 2009/10/28 Brett Porter
> >
> >>
> >> 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 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-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

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

[Stephen Connolly-2]

This was a proposal about a year or two back.... IIRC there were other
more pressing issues and nothing much happened since.

The proposal was part of the "make repository access thread-safe" for
people using maven on CI systems, or running builds in parallel from
the CLI

-Stephen

2009/10/30 Mark Struberg <struberg@...>:

> Hi!
>
> Just make a step back and look at the repository problematic from a bit different perspective.
>
> I'm working for a few companies and even different projects in those companies use different <repositories> sections in their poms.
> But in my local repo, all the artifacts from those repositories gets merged to a single big landfill.
>
> When I switch to a different project, with no repositories configured, I may pick up a wrong dependency this way. Or I may be able to compile and even release, but my colleagues are not, because this very <repository> is missing in the projects pom.
>
> What about remembering where an artifact came from in the local repo?
> E.g. something like
>
> ~/.m2/repository   // this contains the locally installed artifacts and stuff, and also acts for backward compatibility. It is always 'active']
> ~/.m2/repositories/[http_repo1.maven.org.maven2]/com/apache...
> ~/.m2/repositories/[http_dev.java.net/maven2]/javax/enterprise...
> ~/.m2/repositories/[http_dist.codehaus.org_mule_dependencies_maven2]/org/jruby...
>
> If a <repository> is not activated for a specific project then the local artifacts will not be picked up. from .m2/repositories. If a transitive dependency defines a new <repositories> those will be added at the end of the chain. We should think about collision detection, but this should be detectable at least.
>
> There are most probably also things to consider for repository managers.
>
> I'm not sure if it is worth the effort though.
>
> LieGrue,
> strub
>
>
>
>
>
> ----- Ursprüngliche Mail ----
>> Von: Brian Fox <brianf@...>
>> An: Maven Developers List <dev@...>
>> Gesendet: Donnerstag, den 29. Oktober 2009, 20:27:00 Uhr
>> Betreff: Re: [DISCUSS] Handling of repositories in POMs of dependencies
>>
>> It's amazing how google's thread compression of a discussion can cause
>> me to overlook a huge thread so near and dear to my heart.
>>
>> To start, Benjamin has hit the nail on the head of a discussion point
>> Jason and I have had going for quite some time. In fact, we even wrote
>> up a proposal for it months ago that got little feedback. I've also
>> blogged on this subject before.
>>
>> Written and suggested reading in this order:
>> http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
>> http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery
>>
>> I won't rehash all of what I've already written, and leave it to the
>> reader to follow the above urls for the majority of the points however
>> I think there is one key argument that is worth reiterating:
>>
>> The ability of a user to checkout an open source project with no prior
>> knowledge of it and simply be able to build it, run the tests and
>> patch it the first try is the most powerful way to demonstrate the
>> Maven to new users. Simply removing or ignoring repositories in the
>> poms will break this functionality that I feel pretty strongly about.
>>
>> All of the arguments so far in this thread mostly revolve around
>> issues in corporate / enterprise use, and for these issues repository
>> managers are the best solution. I don't think its in the best interest
>> of the community to break OSS use to support Enterprise use,
>> particularly when that problem is already covered.
>>
>> Specifically, I'm pretty strongly in favor of continuing to support
>> repositories declared in poms, however they should be scoped for only
>> the subtree of dependencies introduced by the pom declaring the repo.
>> Further, I recognize that having urls burned into immutable poms is
>> not the best way to accomplish this, and I think we need to find a
>> better one pretty quickly.
>>
>> --Brian
>>
>> On Wed, Oct 28, 2009 at 7:57 PM, Stephen Connolly
>> wrote:
>> > 2009/10/28 Brett Porter
>> >
>> >>
>> >> 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 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-unsubscribe@...
>> >> For additional commands, e-mail: dev-help@...
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

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