That is really just a different flavour of internal maven repository, i.e.
just one that does not give the proxying or performance benefits that a MRM
can give... perhaps you would feel more comfortable if I called it the
"file:///${basedir}" hack which is really really bad for the reasons I
cited.
With an absolute URI that does not include project mutable properties (i.e.
anything that is ${project.*} or ${basedir}) then that is just really an
internal maven repository... which is 2b in my post.
And saying that, if you define the URI as
file:///${shared-fs-root}/maven-repo/ and then people just define the
shared-fs-root as a property in their settings.xml that works too... what
makes it a hack is when one is relying on ${basedir} being the directory
where the pom.xml is located and then relying on the repo being at a fixed
*relative* path to the pom.xml... which stops being true the minute that
the pom is resolved from the ~/.m2/repository/... cache and which can get
completely messed up when the effective list of repositories in play is
computed for downstream projects.
On 21 March 2013 14:24, Jörg Schaible <[email protected]> wrote:
> Hi Stephen,
>
> Stephen Connolly wrote:
>
> > I think mailing lists are not the best way to explain why different
> > solutions are to be preferred when ranking against what is best for the
> > Maven ecosystem as a whole.
> >
> > So I wrote a blog post to explain my views on what are good ways and what
> > are bad ways.
> >
> > http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-
> maven.html
> >
> > Hopefully people find this useful.
>
> There's an additional option using a NAS/network share. Drawback: Everyone
> must set a URL to the repo in his own settings.xml, but there's nothing
> wrong to use file:/ in this case. No POMs got polluted and if you decide
> later to install a real MRM, all that has to be adjusted are the local
> settings.xml - but that applies to any case.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
