Hi, +1 for Daniel Kulp's idea.
Furthermore, I have the feeling that adding the option of <repository/> per artifact is bound to lead to headaches. On the other hand, if you could specify groupId includes/excludes for repositories, things could be much better in terms of resolution times. I frankly think that this should all be the remote repository's job in the first place (and that people should have one). Otherwise we'll have have to have two different places where this is handled, making things more complicated to track later on. This is why artifact routing rules exist in repository managers. Martin On Mon, Jul 7, 2014 at 2:45 PM, Daniel Kulp <[email protected]> wrote: > > Personally, I’ve always wondered if the <repository> entries should have > an <includes> and <excludes> tags to say this repository should only be > searched for these artifacts (like org.apache.*:*). Should help speed the > builds by not looking at every repository for every artifact when we know > they are in central. > > Dan > > > > On Jul 4, 2014, at 12:56 PM, Robert Scholte <[email protected]> wrote: > > > In addition to our hangout session: isn't it weird that for a dependency > Maven can go over all the repositories, even though when an extra > repository is added to the pom.xml, the developer knows exactly which > dependencies should make use of that repository. > > > > To me it would make sense if you could add a reference to the repository > per dependency, like > > > > <dependency> > > <groupId>com.acme</groupId> > > <artifactId>specialtool</artifactId> > > <version>1.0-alpha-1</version> > > <repositoryId>acme-store</repositoryId> <!-- only look in this repo, I > know it's not in Central --> > > </dependency> > > > > Robert > > > > Op Thu, 03 Jul 2014 00:37:17 +0200 schreef Mark Derricutt < > [email protected]>: > > > >> On 3 Jul 2014, at 6:25, Robert Scholte wrote: > >> > >>> This is probably more than enough for tomorrow. > >> > >> A discussion on a merits and flaws of <repositories> (when combined > with mirrors) is also warranted after some previous discussion on the list. > >> > >> Mark > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
