Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of aheritier@gmail.com designates
 74.125.92.147 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=k0EjWmUJ0WuoWendOUjaPtWJJAN7Vonlb1HfH1sNzeeDOMXuwgzRLWvrVvdFn3M8e/
         b+tIgijfdYLzgZAKItWqG/9470NO7TK1/GpHLEz3k0tDI0bNWERJK1T1zGNdd95Q7Xmm
         wIC3e9uqC0TnuOECpP3apWu49ochpwd3zlBF8=
MIME-Version: 1.0
In-Reply-To: <88c1b40910280856g1ac46e6cv232f9b70371b0ebd@mail.gmail.com>
References: <4AE83075.4010909@udo.edu>
 <78910B30-F0AB-4793-8C7C-436851A6C2E6@apache.org>
	<a43524d00910280640v72d3c82cs71e4b6a5dd459a60@mail.gmail.com>
	<4AE85279.8000900@redhat.com>
 <a43524d00910280757k1f23eb49t7eb4fed6df4ea053@mail.gmail.com>
	<4AE86036.3080205@commonjava.org>
 <262c6c680910280852l53a14f89m63005c246d7c9fe4@mail.gmail.com>
	<88c1b40910280855j1ddc527am1bd03003bdb06b90@mail.gmail.com>
	<88c1b40910280856g1ac46e6cv232f9b70371b0ebd@mail.gmail.com>
From: Arnaud HERITIER <aheritier@gmail.com>
Date: Wed, 28 Oct 2009 17:00:55 +0100
Message-ID: <262c6c680910280900r5332becer85048eb38164fea0@mail.gmail.com>
Subject: Re: [DISCUSS] Handling of repositories in POMs of dependencies
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=0016364d2f1f98bc99047700e7a0

--0016364d2f1f98bc99047700e7a0
Content-Type: text/plain; charset=ISO-8859-1

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@gmail.com> wrote:

> 2009/10/28 Stephen Connolly <stephen.alan.connolly@gmail.com>
>
> > 2009/10/28 Arnaud HERITIER <aheritier@gmail.com>
> >
> > 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@commonjava.org>
> >> 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@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
> >> >
> >> >
> >>
> >
> >
>

--0016364d2f1f98bc99047700e7a0--