maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <>
Subject Re: [DISCUSS] Handling of repositories in POMs of dependencies
Date Wed, 28 Oct 2009 15:16:06 GMT
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...


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 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
> On Wed, Oct 28, 2009 at 09:17, 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
>>> On Wed, Oct 28, 2009 at 07:03, Brett Porter <> 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]
>>>>> [1]
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message