maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <jdca...@commonjava.org>
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...

-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@gmail.com
> 
> 
> 
> On Wed, Oct 28, 2009 at 09:17, Paul Gier <pgier@redhat.com> 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@gmail.com
>>>
>>>
>>>
>>> On Wed, Oct 28, 2009 at 07:03, Brett Porter <brett@apache.org> 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@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

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


Mime
View raw message