Re: Maven Developer Hangout

Sat, 05 Jul 2014 04:30:41 -0700

Op Sat, 05 Jul 2014 10:38:29 +0200 schreef Tamás Cservenák <ta...@cservenak.net>: 


Yes. But repo IDs are meaningless imo, urls are a bit better (as Igor
mentioned, could be used as uris, sorta).



Exactly. *If* this is solved in the pom, you have to pass the original  
repositoryUrl as an extra argument to the repository manager. If there are  
multiple repositories, then you could help the searchpath for an artifact  
by directly referring to the expected repository, either by adding the  
repositoryUrl to the <dependency> or referring to the <repository> by id,  
which already exists in the definition of the pom.


Removing the repository elements from the pom would mean that users:
1. are required to use a repository manager.
2. have to know the target repository and configure it.

I don't think users want to do this kind of additional actions to have  
their project up and running.


thanks,
Robert


Nx even today stores all the urls a cached artifact was downloaded in its

own attributes (you can check it with ?describe request). The only  
problem

currently is that if you access repo over a group - the mrm side of nasty
mirrorOf - the overlaid paths are "shaded", this is why group member

ordering matters. Also, currently nx does not receive any extra hint  
beside

the path, so it cannot tinker a lot about maven expectations, this should
be part of richer mrm protocol.

thanks (phone),
~t~
On Jul 5, 2014 2:17 AM, "Martin Gainty" <mgai...@hotmail.com> wrote:




> Date: Fri, 4 Jul 2014 18:31:35 -0500
> Subject: Re: Maven Developer Hangout
> From: pbened...@apache.org
> To: dev@maven.apache.org
>
> The use of <repositories> even with a symbolic id assumes there's only
one

> canonical location for the artifact. I don't think that's true and  
would

> never want to be the end-user who has to manage those symbolic ids. I
still
> advocate removing this tag. I think it's the job of the intermediary
(like
> Nexus) to write some metadata on where it last found the artifact and
then
> only searching others upon failure retrieving a different version /
update.

MG>Paul..Where would the discovered repository metadata be
written?..distributionManagement?

MG>Tamas ...is this possible?
>
>
> Cheers,
> Paul
>
>
> On Fri, Jul 4, 2014 at 2:52 PM, Robert Scholte <rfscho...@apache.org>
wrote:
>

> > I fully agree on the SHA1 check and the repo manager protocol, but  
as

long
> > as we need the <repositories/> in the pom.xml, the repositoryId can
help to
> > optimize the searchpath for the artifacts.
> >
> > That would make the pom responsible for mapping dependency to the
original
> > repositoryUrl and the repository manager for mapping the original
> > repositoryUrl to the ultimate repositoryUrl.
> >

> > Or don't do it to encourage projects to push their artifacts to  
Maven

> > Central.
> >
> > thanks,
> > Robert
> >
> > Op Fri, 04 Jul 2014 19:08:16 +0200 schreef Jason van Zyl <
ja...@takari.io
> > >:
> >
> >  If you consider the identity of the artifact to be its SHA1,
> >> theoretically it doesn't matter where it comes from. This is not to
say

> >> that's optimal to go looking everywhere for an artifact. How this  
is
> >> constrained in Nexus is through routing rules where Nexus knows  
only

to
> >> look for given groupIds in a particular repository and this great
optimizes
> >> lookup times. One might argue this type of logic can be moved back
into
> >> Maven itself.
> >>
> >> As we discussed in the hangout, and I agree with Igor, that mirrors
were

> >> an error and likely something we should eliminate in Maven 4.0.0  
and

work
> >> on a repository manager protocol like we discussed.
> >>
> >> On Jul 4, 2014, at 12:56 PM, Robert Scholte <rfscho...@apache.org>
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 <
> >>> m...@talios.com>:
> >>>
> >>>  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: dev-unsubscr...@maven.apache.org
> >>>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>>
> >>>

> >>>  
---------------------------------------------------------------------

> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> http://twitter.com/takari_io
> >> ---------------------------------------------------------
> >>
> >> Our achievements speak for themselves. What we have to keep track
> >> of are our failures, discouragements and doubts. We tend to forget
> >> the past difficulties, the many false starts, and the painful
> >> groping. We see our past achievements as the end result of a
> >> clean forward thrust, and our present difficulties as
> >> signs of decline and decay.
> >>
> >>  -- Eric Hoffer, Reflections on the Human Condition
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>

> >  
---------------------------------------------------------------------

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


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
























					Reply via email to