maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: [DISCUSS] Handling of repositories in POMs of dependencies
Date Wed, 28 Oct 2009 15:56:39 GMT
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
>> >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message